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