ASP.NET SignalR高可用設計是什么

這篇文章主要介紹“ASP.NET SignalR高可用設計是什么”，在日常操作中，相信很多人在ASP.NET SignalR高可用設計是什么問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”ASP.NET SignalR高可用設計是什么”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

在 One ASP.NET 的架構圖中，微軟將 WebAPI 和 SignalR 歸類到 Services 類型與 MVC、Web Forms 同列為一等公民，未來的 ASP.NET 5 盡管還在beta階段，由它的架構圖中可以發現原來就非常相似的 MVC 與 WebAPI 統一合并到 MVC 的大框架中了，而 SignalR 在未來依然在 Services 扮演著重要的角色。

SignalR 是一個集成了多種 HTTP 通訊方式并且優先使用 HTML5 Web Sockets 作為實時通訊管道的技術，而且其設計架構相當清晰易懂，在 ASP.NET 中作為提供即時消息通訊服務層的重要地位由此可見。

環境

開發 SignalR 應用程序前，應該認識 SignalR 技術對運行環境有一些基本要求，運行現行的SignalR 2.0 需要有 .NET Framework 4.5，服務器端需要 Windows Server 2008 R2 以上的操作系統以及 IIS7，如果使用 Web Sockets 來使 SignalR 技術得到最好的發揮，則應該運行于 Windows Server 2012 和 IIS 8 (開發環境需要 Windows 8 和 IIS 8 Express)，因為 IIS 8 以上才可選擇安裝 Web Sockets 擴展組件。

聯機管理

在 SignalR 中有一項十分重要的能力，就是「自動化的聯機管理」，自動化的聯機管理是在運行期間當客戶端意外脫機時，SignalR Client Library 會在固定時間內自動地嘗試重新建立聯機以恢復與 Server 的對話狀態，這個特性在現在的環境下顯得十分重要，以下就舉兩個十分容易理解的場景：

移動聯機

手機的網絡聯機狀態向來沒有桌面環境穩定，可能隨時因為手機移動到不同的地方而發生時間不一的斷線情況（地鐵經常會發生這種情況），自動化的聯機管理能夠在這樣的場景下得到不錯的使用體驗。

更新部署

另外一方面來看，造成斷線的情況也不一定只有客戶端會發生，當應用程序重啟或者服務器端軟件更新、停機維護狀態，也會造成斷線，后者更有可能產生長時間的網站脫機狀態。經常發生的情況是在 IP （提供服務的VIP）位置不改變的情況下更換了服務器來提供服務，不知道您意識到了嗎？SignalR Client Library 在這樣的情況下會經歷斷線重連的階段而且依舊運行得非常良好。

不過值得注意的是雖然 SignalR Client Library自動地處理了斷線重連，但由于 Web服務器實例已經被完全置換，在架構上如果沒有做相對應的設計，可能會造成原來運行中SignalR 部分消息的丟失，在下一段將說明 SignalR 中的 Backplane 機制來避免這種情況下消息可能丟失的情況。

SignalR Backplane

Backplane 是 SignalR 基于 publish/subscribe (以下簡稱 pub/sub) pattern 設計下的系統可擴展性架構設計，Backplane 將「信息」自「實例內部」移出到「外部存儲服務器」中，讓狀態不再局限于 instance 個體上，以提供 SignalR Server scaleout 的能力，達到支持 Web Farm 架構。

上圖說明了SignalR 是如何的使用 Backplane 架構實現 pub/sub pattern。首先由接受到信息請求的SignalR Server 將信息儲存到 Backplane 上，再由多臺 SignalR Server 處理信息的接收與發送，最后送抵 SignalR Client 端?。

由于Backplane 架構的第一項特征便是將消息外移（動作），對于 Web Farm架構是必須有的設計，然而在單一instance 時也能從其中得到好處，可以不必擔心應用程序部署 VIP SWAP 時可能發生的信息丟失問題，對于處理信息敏感的應用程序來說，這點來說相當地重要。

有多種支持 Backplane 信息向外儲存的方式，包含了 SQL Server、Azure Service Bus 以及 Redis Cache，也可以自行實現其他的外存儲方式，以下針對這三種擴充方式進一步的說明。

SQL Server

通過簡單的設置，開發人員所熟悉的 SQL Database (或 SQL Server) 就能夠用來存儲 SignalR 信息到表中，接著由 Service Broker 來有效的轉發信息到系統中所有的 SignalR Server 處理（注：Server Broker 是為了增加效率，沒有 Service Broker 也能夠正常運行）。

開發人員獲得以 SQL Server 擴展 SignalR 服務的方式是通過 nuget 在項目中獲取 Microsoft.AspNet.SignalR.SqlServer 組件，給予可提供儲存數據的 SQL Database 儲存個體的聯機字符串即可，SQL Database 實例上不需預先建立表格，所需要的 table schema 會由 SQL Server 組件自動建立完成。

詳細的實現信息，可由 ASP.NET 官網所提供的 SignalR Scaleout with SQL Server文章中獲得。值得注意的是當使用 SQL Server 作為信息存儲器，目前在信息轉發的效率上較其他方案低上一些。

Service Bus

service Bus 是一項在 Azure 中重要的基礎結構，提供了 Queue、Topic、Relay 以及 Notification Hub 等功能。其中 Topics 正是一個與 SignalR Backplane pub/sub pattern相同設計的典型服務。

詳細的實現信息，可由 ASP.NET 官網所提供的 SignalR Scaleout with Azure Service Bus 文章中獲得。

Redis Cache

Redis 是在內存內以鍵值 (key-value) 對方式儲存的數據的服務，Redis 也支持 pub/sub pattern 來提供信息服務。詳細的實現信息，可由 ASP.NET 官網所提供的 SignalR Scaleout with Redis 文章中獲得。

Redis 利用內存的運行方式使得它是一個低延遲、高傳輸量的 Backplane 架構。

到此，關于“ASP.NET SignalR高可用設計是什么”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！