Azure SignalR 服务是否随时可用于生产？
是的，对 ASP.NET Core SignalR 和 ASP.NET SignalR 的支持都已正式发布。
如果存在多个应用程序服务器，客户端消息是发送到所有服务器，还是只发送到其中的一个服务器？
客户端与应用程序服务器之间存在一对一映射。 来自一个客户端的消息始终会发送到同一个应用程序服务器。
在客户端或应用程序服务器断开连接之前，将保持映射。
如果我的某个应用程序服务器已关闭，如何发现这种情况并收到通知？
Azure SignalR 服务将监视应用程序服务器的检测信号。 如果在指定的一段时间内未收到检测信号，则可认为应用程序服务器处于脱机状态。 映射到此应用程序服务器的所有客户端连接将会断开。
当我从 ASP.NET Core SignalR SDK 切换到 Azure SignalR 服务 SDK 时，自定义“IUserIdProvider”为何引发异常？
调用 IUserIdProvider 时，ASP.NET Core SignalR SDK 与 Azure SignalR 服务 SDK 的参数 HubConnectionContext context 不相同。
在 ASP.NET Core SignalR 中，HubConnectionContext context 是包含所有属性有效值的物理客户端连接的上下文。
在 Azure SignalR 服务 SDK 中，HubConnectionContext context 是逻辑客户端连接的上下文。 物理客户端将连接到 Azure SignalR 服务实例，因此，只提供有限数量的属性。
目前只能访问 HubConnectionContext.GetHttpContext() 和 HubConnectionContext.User。
你可以查看源代码。
是否可以使用 ASP.NET Core SignalR 配置在服务器端的 Azure SignalR 服务中可用的传输？ 例如，是否可以禁用 WebSocket 传输？
是。 有关如何配置，请参阅传输配置。
也可以按照 ASP.NET Core SignalR 配置中所述配置客户端传输。
Azure 门户中显示的指标（例如消息计数或连接计数）的含义是什么？ 我应该选择哪种聚合类型？
可以在 Azure SignalR 服务中的消息和连接中找到有关计算这些指标的详细信息。
在 Azure SignalR 服务资源的概述窗格上，我们已经为你选择了合适的聚合类型。 可以将支持的指标与 Azure Monitor 一起用作参考。
“默认”、“无服务器”和“经典”服务模式的含义是什么？ 如何选择？
对于新应用程序，应只使用默认和无服务器模式。 主要区别在于你是否拥有与服务建立服务器连接（例如，使用 AddAzureSignalR() 连接到服务）的应用程序服务器。 如果是，则使用默认模式，否则使用无服务器模式。
经典模式旨在实现现有应用程序的后向兼容性，因此不应将其用于新应用程序。
有关服务模式的详细信息，请参阅 Azure SignalR 服务中的服务模式。
能否在无服务器模式下从客户端发送消息？
如果在 SignalR 实例中配置上游终结点，则可从客户端发送消息。 上游终结点是一组终结点，可接收来自 SignalR 服务的消息和连接事件。 如果未配置上游终结点，则会忽略来自客户端的消息。
有关详细信息，请参阅上游终结点。
上游终结点功能目前为公共预览版。
将 Azure SignalR 服务与 ASP.NET SignalR 结合使用时是否有功能差异？
使用 Azure SignalR 服务时，ASP.NET SignalR 的某些 API 和功能不受支持：
- 不支持在客户端和中心（通常称为
HubState）之间传递任意状态的功能。 - 不支持
PersistentConnection类。 - 不支持永久帧传输。
- Azure SignalR 服务不再重播客户端脱机时发送给客户端的消息。
- 使用 Azure SignalR 服务时，在连接期间内，一个客户端连接的流量始终路由（也称为“粘滞”）到一个应用服务器实例。
对 ASP.NET SignalR 的支持侧重于兼容性，因此并非 ASP.NET Core SignalR 的所有新功能都受到支持。 例如，MessagePack 和流式处理仅适用于 ASP.NET Core SignalR 应用程序 。
你可以为不同的服务模式（Classic、Default 和 Serverless）配置 Azure SignalR 服务。 ASP.NET 不支持“Serverless”模式。 也不支持数据平面 REST API。
我的数据存放在什么位置？
Azure SignalR 服务不存储任何客户数据。 如果将 Azure SignalR 服务与其他 Azure 服务（例如 Azure 存储）结合用于诊断，请参阅 Azure 隐私概述（白皮书），以获取有关如何将数据驻留在 Azure 区域中的指南。
如何在 Azure SignalR 服务与 Azure Web PubSub 服务之间进行选择？
Azure SignalR 服务和 Azure Web PubSub 服务都可帮助客户轻松生成大规模且高度可用的实时 Web 应用程序，使客户能够将工作重心放在业务逻辑上，而无需管理消息传递基础结构。 一般而言，如果你已使用 SignalR 库生成了实时应用程序，则可以选择 Azure SignalR 服务。 如果你正在寻求一种通用解决方案来基于 WebSocket 和发布-订阅模式生成实时应用程序，则可以选择 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 的现有高级协议（例如，基于 WebSocket 的 MQTT 或 AMQP）。
- 你正在寻求一台轻型服务器，例如，在不通过配置的后端的情况下将消息发送到客户端。