我正在考慮使用 websockets 設定發布/訂閱服務。據我所知，可擴展性瓶頸主要在於內存，這會影響一次可以打開的套接字數量，因此我認為明智的做法是將其與運行 API 等服務的其他伺服器分開。它是否正確？我認為在託管方面內存比計算能力更昂貴，因此在優化此類伺服器的可擴展性和成本方面是否有任何最佳實踐？
目標是在現場系統簽入新資料時為該 Web 應用程式的使用者提供即時更新，而無需定期輪詢後端。但我們不想使伺服器成本增加一倍，否則可能不值得。我們正在使用 AWS EC2 為我們目前的 API 伺服器提供負載平衡和自動擴充功能。
答案1
單一socket的實際記憶體使用量並沒有那麼多。
消耗記憶體的是與哪個客戶端對哪些更新感興趣以及哪個客戶端已經接收到特定更新相關的狀態。
在原始實作中（即使用作業系統網路堆疊），後一狀態以傳出緩衝區的形式保存——因此，如果將更新傳送到10,000 個客戶端，則資料將複製10,000 次，每個副本都附加到一個傳出佇列，其中添加了必需的標頭（包含每個連接狀態），然後為硬體建立描述符，指示其發送由標頭和有效負載串聯而成的資料包。
每個客戶端的有效負載副本將保留在記憶體中，直到客戶端確認為止，這就是記憶體需求的來源。該記憶體無法調出，因此會給其他應用程式帶來記憶體和快取壓力。
有一些實作可以在伺服器程式本身內部實現部分網路堆疊，這些實作可以透過引用計數或按需重新建立有效負載來避免複製，這使您可以減少大量記憶體使用，但涉及大量真正可擴展的棘手編碼，尤其是多插槽伺服器，會帶來一些有趣的問題，作業系統網路堆疊已經知道如何解決這些問題。
您擁有的選擇
- 在與應用程式相同的伺服器上執行 pub/sub 服務
- 在具有作業系統網路的專用伺服器上執行發布/訂閱服務
- 在具有自訂網路的專用伺服器上執行發布/訂閱服務
- 在多個專用伺服器上執行發布/訂閱服務
隨著服務的發展，您的升級策略是什麼？從共享轉向專用不需要太多規劃，可以根據需要進行；一旦發生這種情況，就該為進一步的階段做準備了。
擴展到多個伺服器將會在您的系統中引入不確定性，因為客戶端可能會以不同的順序接收更新，因此為了使此擴展步驟成功，您的客戶端需要意識到這一點並能夠呈現一致的視圖 -這是微不足道還是困難取決於您的實際應用。
長話短說：無需過早優化。拆分服務，因此第一個擴展步驟是簡單的配置更改，並在發生後立即開始優化。