Azure SignalR Service 是否已可用於生產用途？
是，已正式推出 ASP.NET Core SignalR 和 ASP.NET SignalR 的支援。
有多個應用程式伺服器時，用戶端訊息會傳送至所有伺服器還是僅傳送至其中之一？
用戶端與應用程式伺服器之間具有一對一對應。 來自某一用戶端的訊息，一律會傳送至相同的應用程式伺服器。
此對應會保留，直到用戶端或應用程式伺服器中斷連線。
如果我的其中一個應用程式伺服器已關閉，我要如何發現並獲得通知？
Azure SignalR Service 會監視來自應用程式伺服器的活動訊號。 如果在指定的一段時間內未收到活動訊號，即會將應用程式伺服器視為離線。 對應至此應用程式伺服器的所有用戶端連線都將中斷。
當我從 ASP.NET Core SignalR SDK 切換至 Azure SignalR Service SDK 時，為什麼自訂的 `IUserIdProvider` 擲回例外狀況？
在呼叫 IUserIdProvider 時，ASP.NET Core SignalR SDK 與 Azure SignalR Service SDK 的參數 HubConnectionContext context 不相同。
在 ASP.NET Core SignalR 中，HubConnectionContext context 是來自於實體用戶端連線的內容，且所有屬性都具有有效值。
在 Azure SignalR Service SDK 中，HubConnectionContext context 則是來自於邏輯用戶端連線的內容。 實體用戶端會連線到 Azure SignalR Service 執行個體，因此只會提供有限數量的屬性。
目前只有 HubConnectionContext.GetHttpContext() 和 HubConnectionContext.User 可供存取。
您可以檢查原始程式碼。
我是否可在具有 ASP.NET Core SignalR 的伺服器端設定 Azure SignalR Service 中的可用傳輸？ 例如，我是否可停用 WebSocket 傳輸？
是。 關於如何設定，請參閱傳輸設定。
您也可以如 ASP.NET Core SignalR 設定中所述設定用戶端傳輸。
Azure 入口網站中顯示的類似計量 (例如訊息計數或連線計數) 有何意義？ 我應該選擇哪一種彙總類型？
您可以在 Azure SignalR Service中的訊息和連線中，找到有關我們如何計算這些計量的詳細資料。
我們已在 Azure SignalR Service 資源的概觀窗格中，為您選擇適當的彙總類型。 您可以將支援的計量與 Azure 監視器搭配使用作為參考。
`Default`、`Serverless` 和 `Classic` 服務模式的意義為何？ 我該如何選擇？
針對新的應用程式，只應該使用預設和無伺服器模式。 主要差異在於您是否有應用程式伺服器可建立服務的伺服器連線 (例如，使用 AddAzureSignalR() 連線到服務)。 如果是，請使用預設模式，否則使用無伺服器模式。
傳統模式是針對現有應用程式的回溯相容性所設計，因此不應該用於新的應用程式。
如需服務模式的詳細資訊，請參閱 Azure SignalR Service 中的服務模式 \(部分機器翻譯\)。
我可以在無伺服器模式下從用戶端傳送訊息嗎？
如果您在 SignalR 執行個體中設定上游端點，則可以從用戶端傳送訊息。 上游端點是一組可從 SignalR 服務接收訊息和連線事件的端點。 如果未設定上游端點，則會忽略來自用戶端的訊息。
如需詳細資訊，請參閱上游端點。
上游端點功能目前為公開預覽狀態。
使用適用於 ASP.NET SignalR 的 Azure SignalR Service 時會有任何功能差異嗎？
使用 Azure SignalR Service 時，系統已不支援 ASP.NET SignalR 的某些 API 和功能：
- 不支援在用戶端與中樞之間傳遞任意狀態的功能 (通常稱為
HubState)。 - 不支援
PersistentConnection類別。 - 不支援「永久的框架傳輸」。
- 當用戶端離線時，Azure SignalR Service 不再重新執行傳送至用戶端的訊息。
- 使用 Azure SignalR Service 時，一個用戶端連線的流量一律會在連線期間路由 (也稱為「相黏」) 到一個應用程式伺服器執行個體。
對 ASP.NET SignalR 的支援著重於相容性，因此不支援 ASP.NET Core SignalR 的所有新功能。 例如，MessagePack 和串流等，僅適用於 ASP.NET Core SignalR 應用程式。
您可以針對 Classic、Default和 Serverless 等不同的服務模式設定 Azure SignalR Service。 ASP.NET 不支援 Serverless 模式。 資料平面 REST API 也不受支援。
我的資料在哪裡？
Azure SignalR Service 不會儲存任何客戶資料。 如果您將 Azure SignalR Service 與其他 Azure 服務搭配使用，例如用於診斷的 Azure 儲存體，請參閱 Azure 隱私權概觀 (技術白皮書) 以取得如何在 Azure 區域中使用資料落地的指導。
如何在 Azure SignalR 服務與 Azure Web PubSub 服務之間做出選擇？
Azure SignalR Service 和 Azure Web PubSub 服務都可協助客戶輕鬆組建大規模和高可用性的即時 Web 應用程式，並讓客戶專注於商務邏輯，而不是管理傳訊基礎結構。 一般而言，如果您已使用 SignalR 程式庫來組建即時應用程式，則可以選擇 Azure SignalR Service。 相反地，如果您在尋找一般解決方案，以根據 WebSocket 和發佈-訂閱模式來組建即時應用程式，則可以選擇 Azure Web PubSub 服務。 Azure Web PubSub 服務不取代 Azure SignalR Service，反之亦然，各以不同的案例為目標。 下列指導協助您決定哪個服務要用於您的案例。
在下列情況下，Azure SignalR Service 較適合：
- 您已使用 ASP.NET 或 ASP.NET Core SignalR，主要是使用 .NET，或需要與 .NET 生態系統整合 (例如 Blazor)。
- 您的平台有 SignalR 用戶端可用。
- 您需要支援以下各種項目的已建立通訊協定：
- 通話模式 (RPC 與串流)
- 傳輸 (WebSocket、伺服器傳送的事件和長時間輪詢)
- 您需要代表您管理連線存留期的用戶端。
在下列情況下，Azure Web PubSub 服務較適合：
- 您需要根據 WebSocket 技術或透過 WebSocket 發佈-訂閱來組建即時應用程式。
- 您想要建立自己的子通訊協定，或使用透過 WebSocket 的現有進階通訊協定 (例如 MQTT、AMQP over WebSocket)。
- 您在尋找輕量型伺服器，例如，將訊息傳送至用戶端，但不經過已設定的後端。