其它類型的客戶端, 例如桌面應用.
回落機制
SignalR使用的三種底層傳輸技術分別是Web Socket, Server Sent Events 和 Long Polling.
其中Web Socket僅支持比較現代的瀏覽器, Web服務器也不能太老.
而Server Sent Events 情況可能好一點, 但是也存在同樣的問題.
所以SignalR採用了回落機制, SignalR有能力去協商支持的傳輸類型.
Web Socket是最好的最有效的傳輸方式, 如果瀏覽器或Web服務器不支持它的話, 就會降級使用SSE, 實在不行就用Long Polling.
一旦建立連接, SignalR就會開始發送keep alive消息, 來檢查連接是否還正常. 如果有問題, 就會拋出異常.
因為SignalR是抽象於三種傳輸方式的上層, 所以無論底層採用的哪種方式, SignalR的用法都是一樣的.
SignalR默認採用這種回落機制來進行傳輸和連接.
但是也可以禁用回落機制, 只採用其中一種傳輸方式.
RPC
RPC (Remote Procedure Call). 它的優點就是可以像調用本地方法一樣調用遠程服務.
SignalR採用RPC範式來進行客戶端與服務器端之間的通信.
SignalR利用底層傳輸來讓服務器可以調用客戶端的方法, 反之亦然, 這些方法可以帶參數, 參數也可以是複雜對象, SignalR負責序列化和反序列化.
Hub
Hub是SignalR的一個組件, 它運行在ASP.NET Core應用裡. 所以它是服務器端的一個類.
Hub使用RPC接受從客戶端發來的消息, 也能把消息發送給客戶端. 所以它就是一個通信用的Hub.
在ASP.NET Core裡, 自己創建的Hub類需要繼承於基類Hub.
在Hub類裡面, 我們就可以調用所有客戶端上的方法了. 同樣客戶端也可以調用Hub類裡的方法.
這種Hub+RPC的方式還是非常適合實時場景的.
之前說過方法調用的時候可以傳遞複雜參數, SignalR可以將參數序列化和反序列化. 這些參數被序列化的格式叫做Hub 協議, 所以Hub協議就是一種用來序列化和反序列化的格式.
Hub協議的默認協議是JSON, 還支持另外一個協議是MessagePack. MessagePack是二進制格式的, 它比JSON更緊湊, 而且處理起來更簡單快速, 因為它是二進制的.
此外, SignalR也可以擴展使用其它協議..
橫向擴展
隨著系統的運行, 有時您可能需要進行橫向擴展. 就是應用運行在多個服務器上.
這時負載均衡器會保證每個進來的請求按照一定的邏輯分配到可能是不同的服務器上.
在使用Web Socket的時候, 沒什麼問題, 因為一旦Web Socket的連接建立, 就像在瀏覽器和那個服務器之間打開了隧道一樣, 服務器是不會切換的.
但是如果使用Long Polling, 就可能有問題了, 因為使用Long Polling的情況下, 每次發送消息都是不同的請求, 而每次請求可能會到達不同的服務器. 不同的服務器可能不知道前一個服務器通信的內容, 這就會造成問題.
針對這個問題, 我們需要使用Sticky Sessions (粘性會話).
Sticky Sessions 貌似有很多中實現方式, 但是主要是下面要介紹的這種方式.
作為第一次請求的響應的一部分, 負載均衡器會在瀏覽器裡面設置一個Cookie, 來表示使用過這個服務器. 在後續的請求裡, 負載均衡器讀取Cookie, 然後把請求分配給同一個服務器.
在ASP.NET Core 中使用SignalR
建立項目
使用空模板建立ASP.NET Core項目.
建立一個CountService:
建立一個CountHub, 繼承於Hub:
配置SignalR
在Startup裡註冊SignalR:
如果需要的話可以在AddSignalR()這個方法裡使用lambda表達式進行一些配置.
然後在管道里使用SignalR, 使用app.UseSignalR():
這裡我已經建立了一個Hub, 叫做CountHub.
該方法的參數類型是Action
使用Hub
首先建立一個Controller, 並注入IHubContext
接下來我們就可以使用IHubContext
下面建立一個POST Action, 客戶端點擊按鈕之後來到這個Action, 在這裡我們使用hub為所有的客戶端發送一個消息:
這裡, 我調用了所有客戶端上的someFunc這個方法, 參數是一個對象.
但是使用這種IHubContext
Context
從Hub的Context屬性, 我們可以獲得用戶的信息.
我們在CountHub裡override父類的一個方法OnConnectedAsync():
如果有新的連接建立了, 這個方法就會被執行.
在Hub類裡, 我們可以訪問到Context屬性. 從Context屬性那, 我們可以獲得一個常用的屬性叫做ConnectionId. 這個ConnectionId就是連接到Hub的這個客戶端的唯一標識.
使用ConnectionId, 我們就可以取得這個客戶端, 並調用其方法, 如圖中的Clients.Client(connectionId).xxx.
Hub的Clients屬性表示客戶端, 它有若干個方法可以選擇客戶端, 剛才的Client(connectionId)就是使用connectionId找到這一個客戶端. 而AllExcept(connectionId)就是除了這個connectionId的客戶端之外的所有客戶端. 更多方法請查看文檔.
SignalR還有Group分組的概念, 而且操作簡單, 這裡用到的是Hub的Groups屬性. 向一個Group名添加第一個connectionId的時候, 分組就被建立. 移除分組內最後一個客戶端的時候, 分組就被刪除了. 使用Clients.Group("組名")可以調用組內客戶端的方法.
SignalR會採用ASP.NET Core配置好的授權和驗證體系.
用法和Controller差不多:
想要取得User對象, 需要使用Context.User, 它的類型是ClaimsPrinciple:
客戶端
客戶端需要安裝signalr這個庫. 可以使用npm安裝 @aspnet/signalr
但是實際上只需要signalr.js一個文件即可.
客戶端代碼如下:
點擊按鈕後先執行Controller的POST方法, POST返回的是Accepted(1), 所以id是1.
使用singalR對象的HubConnectionBuilder來構建connection. 使用返回的connection對象, 我們可以用它的on方法來處理服務器端方法調用的響應. 響應方法的參數可以是簡單類型也可以是複雜的對象.
使用connection.start()來打開連接, 使用catch()來捕獲異常, 使用connection.stop() 關閉連接.
先運行一下看看效果:
可以看到使用Clients.All, 所有的客戶端的方法都會被調用.
剛打開頁面的時候, 我們就嘗試建立連接, 從F12可以看到一個叫做negotiate的請求被髮送了:
這個請求的body如下:
可以看到客戶端選擇了一個connectionId, 裡面還有瀏覽器支持的傳輸方式.
服務器的響應:
響應也包含著connectionId, 以及服務器支持的傳輸方式. 這裡三種都支持. 由於我沒有指定傳輸方式, 所以SignalR選擇了最好的方式: websocket.
而在我點擊按鈕後, Web Socket連接才被初始化:
如果需要手動指定傳輸方式, 請在withUrl()方法的第二個參數指定傳輸方式:
其它類型的客戶端
.NET 客戶端可以安裝 Microsoft.AspNetCore.SignalR.Client 這個包來支持SignalR.
具體用法請查看官方文檔, 語法和js的差不多.
MessagePack協議
需要安裝 Microsoft.AspNetCore.SignalR.Protocols.MessagePack.
然後在Startup裡面使用AddMessagePackProtocol()這個方法即可:
這樣的話, 服務器端既支持JSON, 也支持MessagePack了.
另外.NET客戶端也需要安裝這個MessagePack包.
而js客戶端需要安裝 @aspnet/signalr-protocol-msgpack.
橫向擴展 Scale-out
可以採用Redis, 需要安裝 Microsoft.AspNetCore.SignalR.Redis. 這個包.
然後在Startup裡面配置:
這個沒試過, 請看官方文檔.
SignalR就介紹這些....
出處：https://www.cnblogs.com/cgzl/p/9515516.html
閱讀更多 會技術的葛大爺 的文章
