1
我目前正在研究開發一個使用Microsoft Azure作爲後端的移動應用程序。到目前爲止，我所需要的所有內容幾乎都是內置的。Azure移動聊天室
無論如何，我製作的應用程序是一個具有多用戶聊天室的消息應用程序。我從來沒有做過任何後端編程，現在我必須馬上學習所有東西。
我查看了Azure文檔，發現Azure Service Bus功能可能是我正在尋找的功能，但我不確定這是否是執行此類服務的最佳方式。
顯然我想要一種方式讓用戶同步和異步接收消息。它們同時在手機上主動使用應用程序，並在後臺處於異步狀態（當應用程序再次變爲活動狀態時從隊列中加載新消息）。
服務總線有主題我明白允許發佈者 - 訂閱者類型消息架構，但我相信客戶端仍然需要查詢主題隊列（發送請求）以接收數據。這並不理想，因爲我不想僅僅每秒鐘都要硬編碼一個查詢雲服務總線的循環來實現真正的實時聊天......這可能會隨着用戶基數的增長而增加服務器成本。
服務總線也具有繼電器據我所知，以允許服務總線與客戶端之間的雙向通信，以及使得能夠建立在主題的發佈商訂戶架構同步消息（繼電器相結合，與主題， 對？）。
此外，每個聊天室可以有自己的主題，並且加入聊天室的用戶訂閱主題。
我想我可以做的是：我可以讓應用通過中繼連接到服務總線，而用戶正在使用該應用（它位於最前面），用戶將接收實時聊天。當用戶鎖定手機或以其他方式將應用程序置於後臺時，我可以終止中繼連接，並在用戶重新加載應用程序時，我可以從隊列中下載尚未收到的消息。
我想知道服務總線是否被推薦用於這種消息傳遞，或者如果我有背後的想法是錯誤的。你會推薦什麼樣的服務？我接受其他想法，但我寧願保持服務器端的東西相當輕。我有很多前端可以學習！
謝謝！
Don
這是一個真正的意見的問題，因爲沒有正確的答案。在服務總線，網絡套接字，輪詢，推送通知等之間有很多選擇。您應該研究主題和訂閱者的侷限性，以瞭解服務總線是否會與您的應用程序一起擴展（然後還有可進一步擴展的Azure事件中心）。所以...很多選擇，沒有單一的正確答案... – 2015-06-29 13:54:08