Azure SignalR Service 中的服務模式
服務模式是 Azure SignalR Service 中的重要概念。 SignalR Service 目前支援三種服務模式：預設、無伺服器和傳統。 您的 SignalR Service 資源在每個模式中的行為都不同。 在本文中，您將了解如何根據您的案例選擇正確的服務模式。
設定服務模式
當您在 Azure 入口網站中建立新的 SignalR 資源時，系統會要求您指定服務模式。
您也可以稍後在 [設定] 功能表中變更服務模式。
使用 Azure SignalR CLI，利用 az signalr create 和 az signalr update，來設定或變更服務模式。
預設模式
如名稱所示，「預設」模式是 SignalR Service 的預設服務模式。 在「預設」模式中，您的應用程式會作為一般 ASP.NET Core SignalR 或 ASP.NET SignalR (已被取代) 應用程式。 您有裝載中樞的 Web 服務器應用程式 (稱為中樞伺服器)，而且用戶端與中樞伺服器間有完整的雙工通訊。 ASP.NET Core SignalR 與 Azure SignalR Service 之間的差異在於：使用 ASP.NET Core SignalR 時，用戶端會直接連線到中樞伺服器。 透過 Azure SignalR Service，用戶端和中樞伺服器都會連線到 SignalR Service，並使用服務做為 Proxy。 下圖顯示「預設」模式中的一般應用程式結構。
當您有想要搭配 SignalR Service 使用的 SignalR 應用程式時，預設模式通常是正確的選擇。
「預設」模式中的連線路由
在「預設」模式中，中樞伺服器與 SignalR Service之間的 WebSocket 連線稱為「伺服器連線」。 這些連線是用來在伺服器與用戶端之間傳輸訊息。 當新的用戶端連線時，SignalR Service 會透過現有的伺服器連線，將用戶端路由傳送至一個中樞伺服器 (假設您有一部以上的伺服器)。 用戶端連線會在其存留期間持續使用相同的中樞伺服器。 這個屬性稱為「連線綁定」。 當用戶端傳送訊息時，一律會送往相同的中樞伺服器。 有了綁定行為，您可以安全地維護中樞伺服器上的個別連線狀態。 例如，如果您想在伺服器和用戶端之間串流處理某個項目，不需要考慮資料封包送至不同伺服器的情況。
重要
在「預設」模式中，如果中樞伺服器未先連線到服務，用戶端便無法連線。 如果您所有的中樞伺服器因為網路中斷或伺服器重啟而中斷連線，您的用戶端連線會收到錯誤，告知您伺服器未連線。 您必須負責確保永遠有至少一部中樞伺服器連線到 SignalR 服務的。 例如，您可以使用多個中樞伺服器來設計應用程式，然後確寶這些伺服器不會同時離線。
預設路由模型也表示當中樞伺服器離線時，將會卸除路由至該伺服器的連線。 當中樞伺服器離線進行維護時，您應預期連線會中斷，並重新連線以降低對應用程式造成的影響。
注意
在「預設」模式中，如果您不想透過中樞伺服器，也可以使用 REST API、管理 SDK 和函式繫結，直接將訊息傳送至用戶端。 在「預設」模式中，用戶端連線仍會由中樞伺服器處理，上游端點將無法在該模式中運作。
無伺服器模式
不同於「預設」模式，「無伺服器」模式不需要執行中樞伺服器，這就是此模式命名為「無伺服器」的原因。SignalR Service 負責維護用戶端連線。 無法保證連線綁定，且 HTTP 要求的效率可能會低於 WebSocket 連線。
「無伺服器」模式可與 Azure Functions 搭配運作，以提供即時傳訊功能。 用戶端會使用 Azure Functions 的 SignalR Service 繫結 (稱為函式繫結)，以輸出繫結的形式傳送訊息。
由於沒有伺服器連線，所以如果您嘗試使用伺服器 SDK 來建立伺服器連線，您會收到錯誤。 SignalR Service 將會拒絕「無伺服器」模式中的伺服器連線嘗試。
「無伺服器」模式沒有連線綁定，但您仍然可以讓伺服器端應用程式推送訊息至用戶端。 有兩種方式可在「無伺服器」模式中推送訊息至用戶端：
- 針對一次性傳送事件使用 REST API，或
- 使用 WebSocket 連線，讓您可以更有效率地傳送多個訊息。 此 WebSocket 連線與伺服器連線不同。
您也可以讓伺服器應用程式接收來自用戶端的訊息和連線事件。 SignalR Service 會使用 Webhook 將訊息和連線活動傳遞至預先設定的端點 (稱為上游端點)。 上游端點只能在「無伺服器」模式中設定。 如需詳細資訊，請參閱上游端點。
下圖說明範例「無伺服器」的運作方式。
傳統模式
注意
「傳統」模式主要適用於在推出預設和無伺服器模式之前所建立之應用程式的回溯相容性。 除非沒有其他的解決方案可用，否則請勿使用「傳統」模式。 根據您的案例，針對新的應用程式使用「預設」或「無伺服器」模式。 您應該考慮重新設計現有的應用程式，以避免使用「傳統」模式。
「傳統」是「預設」和「無伺服器」模式的混合模式。 在「傳統」模式中，連線類型取決於建立用戶端連線時是否有連線中樞伺服器。 若有中樞伺服器，則用戶端連線會路由至中樞伺服器。 如果中樞伺服器無法使用，用戶端連線將會以有限的無伺服器模式進行，用戶端對伺服器的訊息則無法傳遞至中樞伺服器。 「傳統」模式的無伺服器連線不支援某些功能，例如上游端點。
如果所有中樞伺服器因為任何原因而離線，則會以「無伺服器」模式進行連線。 您必須負責確保永遠至少有一部中樞伺服器可供使用。
選擇正確的服務模式
現在，您應該了解服務模式之間的差異，並知道如何在其間做出選擇。 如先前所述，不建議針對新的或現有的應用程式使用「傳統」模式。 以下是一些可協助您為服務模式做出正確選擇的更多秘訣，並協助您淘汰現有應用程式的「傳統」模式。
如果您已經熟悉 SignalR 程式庫的運作方式，並想從自我裝載 SignalR 移至使用Azure SignalR Service，請選擇「預設」模式。 「預設」模式的運作方式與自我裝載 SignalR 完全相同，而且您可以在 SignalR 程式庫中使用相同的程式設計模型。 SignalR Service 做為用戶端與中樞伺服器之間的 Proxy。
如果您要建立新的應用程式，且不想維護中樞伺服器和伺服器連線，請選擇「無伺服器」模式。 「無伺服器」模式可與 Azure Functions 搭配運作，因此您完全不需要維護任何伺服器。 您仍然可以與 REST API、管理 SDK 或函式繫結 + 上游端點進行完整的雙工通訊，但程式設計模型會與 SignalR 程式庫不同。
如果您「同時」有為用戶端提供連線中樞伺服器和直接將訊息推送至用戶端的後端應用程式，請選擇「預設」模式。 「預設」與「無伺服器」模式之間的主要差異在於您是否有中樞伺服器，以及用戶端連線的路由方式。 REST API/管理 SDK/函式繫結可用於這兩種模式中。
如果您真的有混合案例，請考慮將使用案例分成多個 SignalR Service 執行個體，並根據使用方式設定服務模式。 舉例來說，如果在同個 SignalR 資源上有兩個不同的中樞，便是需要使用「傳統」模式的混合案例。 一個中樞用來作為傳統的 SignalR 中樞，另一個中樞則與 Azure Functions 搭配使用。 此案例應該分割為兩個資源，一個執行個體採用「預設」模式，另一個則採用無伺服器模式。
下一步
請參閱下列文章以深入了解如何使用「預設」和「無伺服器」模式。