微軟為持久連接框架SignalR貢獻基于Azure的向外擴展

作者 Richard Seroter 譯者 曹如進

Windows Azure 團隊架構設計師，Clements Vasters，在最近一篇博文中介紹了一個新的 GitHub 項目——SignalR。該項目使用 Windows Azure 服務總線（Service Bus）在服務器和客戶端之間進行雙向分發信息，它的出現讓異步 ASP.NET Web 事件引擎具有向外擴展以及高吞吐消息傳送能力成為可能。

SignalR 類似與 JavaScript 實時框架，如 Socket.IO。SignalR 能夠完成客戶端向服務器的異步通信，并同時支持服務器向瀏覽器客戶端推送事件。雖然沒有直接綁定在 ASP.NET 中，但是 SignalR 項目由微軟 ASP.NET 團隊打造，用作為 ASP.NET Web 應用程序提供持久連接機制。SignalR 的連接通過日益流行的 WebSockets API 完成，而如果 WebSockets 無法使用，它會透明地回落為長輪詢技術（long-polling technique）。如果開發人員想使用 Signal，需要在客戶端層使用像 jQuery 的 JavaScript 框架，并在服務端層使用 .NET 代碼編寫應用和服務。SignalR 具有多種編程模型（PersistentConnections 和 Hubs），它為開發人員提供了連接、消息接收群以及事件處理器的不同層次的訪問。

雖然 SignalR 顯示已經可在單臺機器上擴展至上萬個連接，但是開發人員還沒有辦法跨越多臺 Web 服務器進行服務端組件部署。這會帶來單點故障，而且限制應用程序可支持的并發連接數。Vasters 說他使用 Azure 服務總線解決了這個問題：

上周，我為 SignalR 建立了一個 Windows Azure 服務總線底板（backplane），它能夠部署 SignalR 解決方案到多個結點上，并可以跨越這些結點進行消息分發，確保每一個發送端擁有合理的順序，以及光標 cookie 中結點到結點的正確性和一致性。

只要你的后端主機能夠訪問服務主線命名空間，不管你托管的 SignalR 解決方案中在什么地方，你都可以你使用這個底板。如果你的解決方案是放在 Windows Azure 的數據中心，那顯然是最好不過的；當然，放在其他的地方也行，只是會多幾（毫秒）的延遲。

使用基于 Azure 的 SignalR 項目，用戶可以選擇跨越服務總線 Topics 對消息進行分流，從而達到超過單個 Topic 能夠支持的吞吐量。由于 Vasters 的這個項目利用到了已受支持的 SignlR 擴展點，因此只需對服務器應用程序進行很小的改動即可。你可以通過訪問它在 GitHub 中的站點以下載或查看該項目的源代碼。

查看英文原文：http://www.infoq.com/news/2012/02/azure-signalr