何時使用 ASP.NET Core SignalR

已完成

SignalR 提供即時的 Web 功能。 回想一下,Contoso Pizza 需要即時地圖來追蹤訂單的狀態和遞送。 尖峰時段的銷售損失促使小組調查比用戶端輪詢更好的解決方案。

決策準則

知道何時 [不要] 選擇 SignalR,就如同知道何時選擇一樣重要。 透過即時的 Web 功能,使用者的應用程式體驗仰賴其回應能力。 最好了解應用程式的哪些部分需要即時更新。

何時「不要」使用 SignalR

SignalR 的耐久程度僅與其基礎連線相同。 也就是說,如果攸關用戶端應用程式的「連線能力」,SignalR 不是最佳選擇。

另一個考量是 SignalR 的可擴縮性。 視同時連線的用戶端數目而定,您的網頁伺服器可能會在達到限制時遇到「資源爭用」。 在這種情況下,您可能需要將應用程式部署至伺服器陣列並使用背板。 自行實作此動作可能很麻煩。

或者,您可以使用 Azure SignalR Service 來解決此問題。 或者,您可以利用各種復原和災害復原機制來協助減輕問題。

SignalR 形式範例

您可以使用 SignalR 內部部署、在雲端或透過 Azure SignalR Service。

  • 內部部署:

    Diagram of ASP.NET Core SignalR being used on-premises.

  • 在雲端:

    Diagram of ASP.NET Core SignalR being used in the cloud.

  • 透過 Azure SignalR Service:

    Diagram of using Azure SignalR Service.

有效的使用案例

SignalR 不是傳統 HTTP 要求的替代方式。 應用程式可以使用 SignalR 來得知何時提出特定 HTTP 要求。 如此一來,彼此互補。

SignalR 有許多有效的使用案例。 下列清單代表 SignalR 的良好候選項目:

  • 需要頻繁從伺服器取得更新的應用程式:
    • 遊戲
    • 社交網路
    • 投票
    • 拍賣
    • GPS 應用程式
  • 儀表板和監視應用程式:
    • 公司儀表板
    • 即時地圖
    • 即時銷售更新
    • 旅遊警示
    • 持續整合/持續傳遞 (CI/CD) 管線頁面
  • 共同作業和多使用者的互動式應用程式:
    • 白板應用程式
    • 小組會議應用程式
    • 文件共用應用程式
    • Visual Studio Live Share
  • 需要即時通知的應用程式:
    • 電子郵件應用程式
    • 聊天應用程式
    • 回合制遊戲
    • 時間序列報告
    • GitHub Actions、問題和提取要求系統

Contoso Pizza 案例

如果您考慮 Contoso Pizza 即時訂單地圖中的用戶端輪詢解決方案,SignalR 可以是可行的替代方案。 至於所有程式設計與架構決策,請務必權衡 SignalR 的優點和缺點。