技術設計與評審
提示詳情
我將擔任一家大型科技公司的高級軟件工程師。我需要為我們的 Web 應用程式設計一個實時通知系統。
我的初步方案是在每個客戶端和我們的主後端服務器之間建立直接的 WebSocket 連接。
請評估此方案：
1. 優缺點：分析其在可擴充性、複雜性和可靠性方面的優缺點。
2. 替代架構：提出兩種替代方案（例如，消息隊列或第三方服務）。
3. 對比表：從可擴充性、成本/複雜性和開發速度三個方面比較這三種方案。
提示的作用
在設計實時通知基礎設施等系統時，工程師需要在投入資源之前，將初始方案與可行的替代方案進行比較。此提示會根據您提出的架構（例如直接 WebSocket 連接）生成結構化的評估報告，其中涵蓋了優缺點以及兩種替代方案。
remio 通過參考以往的架構決策記錄、設計文檔以及團隊在 Slack 上就類似系統進行的討論，加速了這一過程。您無需從零開始，即可獲得涵蓋可擴充性、成本、複雜性和開發速度的對比表格，可直接將其添加到 ADR 或 RFC 中。
何時使用
• 您正在為一項新的實時功能起草架構決策記錄，需要説明選擇某種方案而非其他方案的原因。
• 即將進行設計評審，您需要一份結構化的優缺點分析報告，以便向團隊展示。
• 您正在評估是自行構建 WebSocket 層，還是採用 Pusher 或 Ably 等託管服務。
• 您的團隊正在討論消息隊列架構（Kafka、RabbitMQ）與直接連接，需要一個清晰的比較框架。
• 您正在接入一個現有的通知系統，希望瞭解之前可能考慮過的權衡取捨。
提示示例
輸入： 我是一家大型科技公司的軟件工程師，需要為我們的Web應用程式設計一個實時通知系統。我的初步方案是在每個客戶端和我們的主後端服務器之間建立直接的WebSocket連接。請分析此方案的優缺點，並提供兩種替代架構以及對比表格。
remio 回覆：
您提供的直接 WebSocket 方案雖然延遲低且控制全面，但它將通知傳遞與後端緊密耦合，導致每個服務器併發連接數超過約 1 萬個時出現擴充瓶頸。方案一：在後端和專用 WebSocket 網關之間引入消息代理，例如 Redis Pub/Sub 或 Kafka——這樣可以將生產者與消費者解耦，並實現橫向擴充。方案二：使用 Pusher 或 Ably 等託管服務，它們可以完全處理連接管理。以下是比較：直接 WebSocket 方案開發速度快，但可擴充性差；消息隊列方案成本和可擴充性都比較適中；託管服務方案可擴充性和速度最高，但需要支付持續的供應商費用。我還找到了您團隊在三月份的 #platform-architecture Slack 頻道中關於 Redis Pub/Sub 的討論，當時他們評估了 Redis Pub/Sub 在類似用例中的應用。
提示1：
請明確説明您的預期規模——併發用戶數、每秒消息數、地理分佈——以便架構審查能夠解決您的實際限制，而不是通用的權衡取捨。
提示 2：
請提供您當前的技術棧（例如 Kubernetes、AWS、特定語言），以便獲得適合您現有基礎設施的替代方案。
提示 3：
要求 remio 在生成評審之前搜尋您團隊過去的文檔和 RFC，以便比較結果能夠反映您的組織已經探索過的決策。
更多技巧
remio 滿足您對知識的所有需求
瞭解更多功能
從網站、本機資料夾和檔案中獲取資源。
從您的整個知識庫中獲取即時、可靠的答案。
建立可編輯的原生 PPTX 簡報
結合你的個人經驗
不限次數的免費錄音與語音轉文字，毋須機械人加入會議。