Azure SignalR Service 中的服務模式
服務模式是 Azure SignalR Service 中的重要概念。 SignalR Service 目前支援三種服務模式： 預設 、 無 伺服器和 傳統 。 您的 SignalR 服務資源在每個模式中的行為會有所不同。 在本文中，您將瞭解如何根據您的案例選擇正確的服務模式。
設定服務模式
當您在 Azure 入口網站 中建立新的 SignalR 資源時，系統會要求您指定服務模式。
您也可以稍後在 [設定] 功能表中變更服務模式。
使用 az signalr create 和 az signalr update 來設定或變更服務模式，方法是使用 Azure SignalR CLI 。
預設模式
顧名思義， 預設模式是 SignalR Service 的預設 服務模式。 在預設模式中，您的應用程式會以典型的 ASP.NET Core SignalR 或 ASP.NET SignalR（已淘汰）應用程式的形式運作。 您有裝載中樞的 Web 服務器應用程式，稱為 中樞伺服器 ，且用戶端與中樞伺服器具有完整的雙工通訊。 ASP.NET Core SignalR 和 Azure SignalR 服務之間的差異在於，用戶端和中樞伺服器會直接連線到 SignalR 服務，並使用服務作為 Proxy。 下圖顯示預設模式中的一般應用程式結構。
當您有要搭配 SignalR 服務使用的 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 會使用 Web 攔截，將訊息和線上活動傳遞至預先設定的端點（稱為 上游端點 ）。 上游端點只能在無伺服器模式中設定。 如需詳細資訊，請參閱 上游端點 。
下圖顯示無伺服器模式的運作方式。
傳統模式
注意
傳統模式主要是針對在引進預設和無伺服器模式之前所建立的應用程式回溯相容性。 請勿使用傳統模式，但作為最後手段。 根據您的案例，針對新的應用程式使用預設或無伺服器。 您應該考慮重新設計現有的應用程式，以消除傳統模式的需求。
傳統是預設和無伺服器模式的混合模式。 在傳統模式中，連線類型是由建立用戶端連線時是否有中樞伺服器所決定。 如果有中樞伺服器，用戶端連線將會路由傳送至中樞伺服器。 如果中樞伺服器無法使用，用戶端連線將會以有限的無伺服器模式進行，而用戶端對伺服器訊息無法傳遞至中樞伺服器。 傳統模式無伺服器連線不支援某些功能，例如上游端點。
如果您的所有中樞伺服器因為任何原因而離線，則會在無伺服器模式中建立連線。 您必須負責確保至少有一部中樞伺服器一律可供使用。
選擇正確的服務模式
現在您應該瞭解服務模式之間的差異，並知道如何在兩者之間選擇。 如先前所述，不建議針對新的或現有的應用程式使用傳統模式。 以下是一些可協助您為服務模式做出正確選擇的秘訣，並協助您淘汰現有應用程式的傳統模式。
如果您已經熟悉 SignalR 程式庫的運作方式，而且想要從自我裝載 SignalR 移至使用 Azure SignalR 服務，請選擇 [預設模式]。 預設模式的運作方式與自我裝載 SignalR 完全相同，而且您可以在 SignalR 程式庫中使用相同的程式設計模型。 SignalR Service 可作為用戶端與中樞伺服器之間的 Proxy。
如果您要建立新的應用程式，且不想維護中樞伺服器和伺服器連線，請選擇無伺服器模式。 無伺服器模式可與 Azure Functions 搭配運作，因此您完全不需要維護任何伺服器。 您仍然可以與 REST API、管理 SDK 或函式系結 + 上游端點進行完整雙工通訊，但程式設計模型會與 SignalR 程式庫不同。
如果您有 兩 部中樞伺服器來提供用戶端連線和後端應用程式，以直接將訊息推送至用戶端，請選擇 [預設模式]。 預設和無伺服器模式之間的主要差異在於您是否有中樞伺服器，以及用戶端連線的路由方式。 REST API/管理 SDK/函式系結可用於這兩種模式。
如果您真的有混合案例，您應該考慮將使用案例分成多個 SignalR 服務實例，並根據使用設定服務模式。 需要傳統模式的混合案例範例是您在相同 SignalR 資源上有兩個不同的中樞。 一個中樞會作為傳統的 SignalR 中樞使用，另一個中樞則與 Azure Functions 搭配使用。 此範例應該分割成兩個資源，其中一個實例處於預設模式，另一個則為無伺服器模式。
下一步
請參閱下列文章，以深入瞭解如何使用預設和無伺服器模式。