基於客戶端/服務器消息的互聯網架構

Question

問題

一段時間以來，我一直在思考基於消息的架構的復雜性，當消息傳遞的一個渠道包括互聯網時。

我很滿意在客戶端排隊消息的概念，在處理時，會導致通過互聯網進行的Web服務調用，然后在服務器上對這些相同的消息進行排隊，以便根據業務規則進行處理。 我目前不知道的是一種將消息發送回客戶端以告訴它發生了什么的機制。

這個例子

考慮這個示例，桌面倉庫管理應用程序希望從服務器接收消息，而不是輪詢以查看是否有任何消息。

例如

1. 用戶在具有嚴格SLA的網站上創建緊急訂單，以便在幾分鍾內進行揀選，因為有人已經開始收集物品。
2. OrderCreated消息在服務器上發布。
3. Magic恰好將OrderCreated消息發送到倉庫中PC上運行的客戶端軟件。
4. 客戶端軟件在屏幕上顯示新訂單（如果重新啟動等，可能會緩存到磁盤）。
5. 倉庫團隊挑選物品以完成訂單。

這是第3點，我正在尋找填補空白的技術。

可能的解決方案

1. 定期和經常輪詢服務器（小時）以查看是否有消息，並將它們下載到本地隊列進行處理。
2. 在WCF中使用類似雙向通信的東西，雖然這需要在客戶端和服務器之間永久保持通道/套接字/端口等，因此它不會優雅地擴展。
3. 實際上在本地站點中打開端口並配置端口轉發和防火牆等，以啟用MSMQ（或其他一些技術，如WCF，這可能意味着在客戶端硬件上托管IIS或類似的東西）將消息推送到客戶端。 當然，這里的部署和支持成本是天文數字。

有沒有人有任何使用我未在此列出的解決方案實現此目的的經驗？ 我不是一定要尋找細節，我只是在這個空間里四處尋找，看看它是如何完成的。

提前謝謝了。

Answer 1

我在自動化領域有很多經驗，我會說輪詢和雙向通信是最常見的。

在這兩者中，我總是喜歡雙向通信。 它確實可以很好地擴展到某一點 - 只要服務器使用異步API（並且特別是不使用“每個連接的一個線程”設計可憎），就可以實現數萬個套接字/ WCF連接。

輪詢方法確實會產生更多不必要的網絡流量，但如果您通過單個服務器進行擴展可能會更好。 在我看來，您可以使用現有技術相當容易地擴展到Web場，如果您使用輪詢方法，這種擴展（我認為）會更容易。 不過，我從來沒有必須擴大規模。

我沒有使用MSMQ進行此類通信，但使用了IBM的WebSphere（類似的技術）。 消息隊列有自己的一系列自動化問題，例如處理死信隊列等。如果您希望服務器關閉一段時間（或者如果您在客戶端和服務器之間有不可靠的“中間件”），這將非常有用），但一般來說，我更喜歡通過套接字或WCF進行雙向通信。

Answer 2

也許在JMS之后構建一些東西（甚至只是為現有的.net服務器構建一個JMS適配器，然后直接使用JMS）？ 在中，您可以讓客戶端維護與通知服務器的持久套接字連接（如果您正在考慮每分鍾多次輪詢服務器，那么為什么不保持套接字打開？）。 當建立套接字時，連接客戶端可以訂閱/注冊它有興趣接收的任何事件（例如“我只想要與倉庫A中的產品相關聯的事件”）。 然后，當在服務器上發布OrderCreated消息時，服務器可以查看其客戶端列表以查看誰為該消息注冊，並立即通過相應的套接字連接向客戶端發布通知。

Answer 3

這是我之前使用（3或4年前）創建即時消息程序的簡短代碼段。 它創建一個可以接受來自服務器的消息的TcpListener ，以及一個NetworkStream和TcpClient來向服務器發送消息。 它可能不是一個完整的答案，但它可能有助於指導您。

Answer 4

我會使用TCP和回調的WCF服務。

是什么讓你說它不規模？

Answer 5

我目前正致力於一些非常相似的事情，需要通過互聯網及時將消息傳遞到DSL路由器/調制解調器后面的客戶端軟件，並可能綁定到動態IP地址。 頻繁的輪詢是我們選擇的解決方案，在性能和簡單性之間取得平衡。

Answer 6

看看WebSockets - 它還沒有，但它的目的是成為Comet / long-poll技術的繼承者。 它旨在實現Web瀏覽器，但沒有理由不能在其他類型的客戶端中使用。