Asp.net Core3.1+Vue 使用SignalR推送資料
.NET Core 3.1使用SignalR做登入、推送、聊天、 分組 請參考https://www.cnblogs.com/shousiji/p/12737925.html
程式碼https://files.cnblogs.com/files/netlock/SignalRDemo.rar
本文就簡單使用往前端頁面推送訊息
SignalR 是什麼
SignalR是一個.NET Core/.NET Framework的開源實時框架. SignalR的可使用Web Socket, Server Sent Events 和 Long Polling作為底層傳輸方式.
SignalR基於這三種技術構建, 抽象於它們之上, 它讓你更好的關注業務問題而不是底層傳輸技術問題.
SignalR這個框架分伺服器端和客戶端, 伺服器端支援ASP.NET Core 和 ASP.NET; 而客戶端除了支援瀏覽器裡的javascript以外, 也支援其它型別的客戶端, 例如桌面應用.
對於.NET開發者的福音，.NET平臺為我們提供了一種簡潔高效智慧的實時資訊互動技術->SignalR，它集成了上述數種技術，並能根據配置自動或手動選擇其最佳應用
可以用SignalR做什麼？
-
SignalR可用於將任何型別的"實時"web 功能新增到 ASP.NET 應用程式。 比如最常用的即時訊息、聊天。 只要使用者重新整理 web 頁面以檢視新資料或頁面實現長輪詢若要檢索新資料，可以考慮對它使用 SignalR。 包括儀表板和監視應用程式，協作應用程式 （如同時進行編輯的文件），作業的進度更新到並實時窗體。
-
SignalR還可以用於需要高頻率從伺服器中更新的全新型別weB應用程式，例如線上聊天、實時遊戲、天氣、股票資訊更新等實時應用程式。
-
SignalR 提供一個簡單的 API，用於建立從伺服器端.NET 程式碼中呼叫 JavaScript 函式在客戶端瀏覽器 （和其他客戶端平臺） 的伺服器到客戶端的遠端過程呼叫 (RPC)。 SignalR 還包括連線管理的 API （例如，連線和斷開連線事件），並對連線進行分組。
回落機制
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
建立一個ServerHub, 繼承於Hub:
public class ServerHub : Hub {}
在Startup裡註冊SignalR: