Azure SignalR 服务是一项完全托管的服务，可在 Web 和移动应用程序中实现实时双向通信。 它抽象化基础传输机制。 当 WebSocket 可用时，该服务会使用它们。 当它们不是时，它会回退到 Server-Sent 事件或长时间的轮询。 这种抽象意味着客户端和服务器代码可以实时通信，而无需绑定到特定的传输协议。
使用 Azure 时，可靠性是共同的责任。 Azure 提供了一系列支持复原和恢复的功能。 你负责了解这些功能如何在你使用的所有服务中工作，并选择满足业务目标和运行时间目标所需的功能。
本文介绍如何使Azure SignalR 服务应对各种潜在中断和问题，包括暂时性故障、可用性区域中断、区域中断和服务维护。 它还重点介绍了有关Azure SignalR 服务服务级别协议（SLA）的关键信息。
提高可靠性的生产部署建议
对于生产工作负载，我们建议您：
- 使用高级版本。 高级层能够抵御受支持区域的可用区故障，并允许你配置异地复制。
- 设计客户端应用程序和应用服务器，以确保在连接中断时能够安全地自动重新连接。 区域故障转移、区域故障转移和暂时性故障都会删除活动连接。
- 启用异地复制以防止区域范围的故障。 为每个副本分配足够的容量，以应对故障转移事件期间预计的全部流量负载。
可靠性体系结构概述
本部分介绍从可靠性的角度来看，服务工作原理最相关的一些重要方面。 本部分介绍逻辑体系结构，其中包括部署和使用的某些资源和功能。 它还讨论了物理架构，该架构提供了服务内部运作方式的详细信息。
逻辑体系结构
创建的资源是 SignalR 服务 资源。 配置包含多个单位的资源，这些 单位表示资源的容量，包括最大并发连接数。 有关详细信息，请参阅 Azure SignalR 服务性能指南。
Azure SignalR 服务支持两种服务模式。 在默认模式下，应用服务器连接到 Azure SignalR 服务 资源，并负责包含和处理集线器逻辑。 在无服务器模式下，该服务与Azure Functions集成，Functions 充当事件驱动的消息处理程序，因此你不会直接管理应用服务器。 有关详细信息，请参阅 Azure SignalR 服务中的服务模式。
SignalR 服务资源具有类似于 contoso.service.signalr.net 的全局唯一终结点。 客户端与此终结点建立连接。 应用程序服务器连接到同一终结点，以从客户端发送消息和接收事件。
物理体系结构
Azure SignalR 服务跨一组计算资源管理连接状态和消息路由。 Azure管理底层基础结构。 不会直接看到或与服务使用的各个 VM 或其他基础结构组件进行交互。
暂时性故障的复原能力
暂时性故障是指组件发生短暂的间歇性故障。 这些故障经常出现在云之类的分布式环境中，在运营过程中比较常见。 暂时性故障在短时间内自行纠正。 应用程序通常可以通过重试受影响的请求来处理暂时性故障，这一点很重要。
与任何云托管的 API、数据库和其他组件通信时，所有云托管的应用程序都应遵循 Azure 暂时性故障处理指南。 有关详细信息，请参阅有关处理暂时性故障的建议。
Azure SignalR 服务使用客户端、应用服务器和服务之间的长期连接。 由于网络不稳定、负载均衡器重新配置或浏览器选项卡挂起等暂时性故障，可能会删除这些连接。 设计客户端应用程序和应用服务器以自动处理连接断开和重新连接。
Azure SignalR 服务 SDK 包含内置的重新连接处理功能，以用于服务器与服务之间的连接。 客户端重新连接取决于您使用的客户端代码库。 ASP.NET Core SignalR 客户端支持有状态重新连接，这样客户端就可以恢复其以前的连接，而不会丢失状态（如果客户端使用同一连接 ID 快速重新连接）。 如果重新连接导致新的连接 ID，例如，在长时间服务中断后，服务会将客户端视为新连接。 在这种情况下，客户端需要重新加入以前处于的任何组并还原任何会话状态。
有关设计应用程序以处理客户端断开连接和重新连接的详细指南，请参阅 理解 Azure SignalR 服务中的客户端断开连接和重新连接。
应对可用区故障的弹性
可用性区域 是 Azure 区域内物理上独立的数据中心组。 当某个区域发生故障时，服务可以切换到其他可用的区域。
Azure SignalR 服务支持高级层中的区域冗余部署。 在支持可用性区域的区域中创建或升级到高级层资源时，Azure SignalR 服务会自动将其计算容量分配到该区域中的所有可用性区域。 如果可用性区域失败，Azure SignalR 服务将新连接路由到剩余正常区域中的实例。
Requirements
区域支持： 大多数区域都支持区域冗余，其中这两个条件都适用：
- Azure SignalR 服务可用。 有关服务可用区域的列表，请参阅 “按区域列出的产品可用性”。
- 该区域支持可用性区域。 有关具有可用性区域的区域列表，请参阅 Azure 区域列表。
层： 高级层提供区域冗余。
Cost
区域冗余不会增加成本，你支付标准高级层费率。 有关详细信息，请参阅 Azure SignalR 服务 定价。
配置可用性区域支持
除了选择高级层之外，区域冗余不需要任何配置。 这两种情况下会自动启用它：
创建新的区域冗余 SignalR 服务资源。 创建资源时，请选择高级层 SKU。 有关详细信息，请参阅快速入门，例如 快速入门：使用 SignalR 服务创建聊天室。
将现有资源升级到高级层。 将现有资源升级到高级层 SKU 时，会自动启用区域冗余。 从标准升级到高级不会导致服务停机。 有关详细信息，请参阅 更改 Azure SignalR 服务层级。
所有区域正常时的行为
本部分介绍如何为可用区冗余配置 Azure SignalR 服务 资源，并在所有可用区运行正常时，可以预期的情况。
跨区操作：Azure SignalR 服务自动管理连接和操作在可用区中的分布方式。 多个区域中的基础结构处理主动-主动模型中的流量。 你不需要进行任何配置即可利用这种行为。 服务自动跨区域路由实例之间的消息，因此，一个区域中的客户端发送的消息将传递到任何其他区域中连接的客户端。
跨区域数据复制：Azure SignalR 服务 不会保留客户数据，因此区域之间没有要复制的数据。 连接状态为临时状态，与每个活动连接相关联。
区域故障期间的行为
本节介绍在配置 Azure SignalR 服务 资源以实现区域冗余时，当某个可用区发生中断时可以预期的情况。
- 检测和响应：Azure SignalR 服务 平台负责检测可用区中的故障。 无需执行任何操作即可启动区域故障转移。
- 通知：Azure 不会在区域关闭时自动通知你。 但是，可以使用 Azure 资源运行状况 监视单个资源的运行状况，并且可以设置 资源运行状况警报 来通知问题。 还可以使用 Azure 服务运行状况 来了解服务的总体运行状况，包括任何区域故障，还可以设置 服务运行状况警报 来通知问题。
活动请求： 在区域故障期间，将删除与受影响区域中节点的活动连接。 如果客户端适当地处理 暂时性故障 ，例如在短时间内重新连接，它们通常会避免产生重大影响。
Expected data loss： Azure SignalR 服务不会持久保存消息，因此区域故障不应导致Azure SignalR service内数据丢失。 但是，在区域关闭事件期间会删除任何活动连接，因此主动传输的任何数据都可能会丢失。
预期的停机时间： 删除的活动连接重新连接通常需要几秒钟时间。 实现重新连接逻辑的客户端会经历最少的中断。
Redistribution： Azure SignalR 服务检测区域丢失情况，并自动跨正常区域重新分发流量。 你不必执行任何操作。
区域恢复
当可用性区域恢复时，Azure SignalR 服务自动将其重新集成到活动服务拓扑中。 您无需对区域恢复执行任何操作。
区域恢复后，新连接可能会定向到恢复区域中的基础结构。 任何现有的连接都不会被转移或重新均衡到恢复区域，但随着这些连接随时间断开和重新连接，它们将逐渐被重新均衡。 跨区域的连接不平衡对工作负荷没有任何影响。
测试区域故障
Azure SignalR 服务自动管理区域冗余高级层资源的流量路由、故障转移和区域恢复。 你不需要开始任何事情。 由于区域冗余是完全托管的，因此无需验证可用区故障处理流程。
对区域范围的故障的复原能力
Azure SignalR 服务是单区域服务。 如果区域不可用，则SignalR 服务资源也不可用。
若要保护应用程序免受区域范围的故障的影响，可以使用高级层中提供的 异地复制。 或者，可以通过在不同的区域中部署多个SignalR 服务资源来生成自定义多区域解决方案。
异地复制
使用地理复制可以在其他 Azure 区域添加 SignalR 服务资源的 副本。 Azure 流量管理器 使用基于 DNS 的路由将每个客户端传输到最近的正常区域副本。 如果某个区域失败，流量管理器会通过运行状况检查检测失败，并停止将客户端定向到该副本。 新的客户端连接会自动路由到最接近的正常副本。
您创建 Azure SignalR 服务资源的区域称为 主要区域，其副本称为 主要副本。 主资源的 控制平面管理 Azure SignalR 服务资源的配置。
Requirements
- Region support： 可以在可用Azure SignalR 服务的任何区域中添加副本。
- 层： 必须使用高级层来启用异地复制。
- Replica limit：每个主SignalR 服务资源最多支持 8 个副本。
注意事项
配置继承： 副本从主要资源继承大多数配置设置。 必须在每个副本上单独配置某些设置。 有关未继承设置的完整列表，请参阅 Azure SignalR 服务中的 地理复制。
配置更改：主要控制平面在主要区域中处理对SignalR 服务资源的任何配置更改。 如果主控制平面不可用，则无法更新资源配置，但现有副本将继续处理数据流量，而不会中断。
Cost
每个副本单独计费，基于其自身的单位数量和发出的消息量。 当在副本之间传输消息并传递到另一区域中的客户端或服务器时，会收取跨区域出口费用。 有关详细信息，请参阅 Azure SignalR 服务 定价。
配置异地复制
若要向 SignalR 服务 资源添加或删除副本，请参阅 Azure SignalR 服务 中的地理复制。
容量计划和管理
每个副本独立处理流量。 在区域故障转移期间，来自失败区域的客户端重新连接到最近的正常副本。 为了确保幸存的副本具有足够的容量来应对额外的负载，请为每个副本配置可以处理工作负荷全部预期流量的单元，而不仅是它通常处理的部分。
或者，在每个副本上启用自动缩放，以便单位可以自动横向扩展以响应更高的负载。 当辅助副本不可用时，自动缩放将继续工作，但如果主控制平面不可用，则自动缩放不起作用。 有关自动缩放的详细信息，请参阅 Azure SignalR 服务中的自动缩放。
有关过度预配作为策略的一般指导，请参阅 通过过度预配管理容量。
当所有区域都正常时的行为
本节描述在为地理复制配置 Azure SignalR 服务时的预期，同时所有副本均正常运行。
Cross-region operation： Azure 流量管理器将每个客户端路由到最近的健康区域副本。 不同地理区域中的客户端可能会连接到不同的副本。 SignalR 服务跨副本同步消息，以便连接到任何副本的客户端可以相互通信。
跨区域数据复制： 将消息发送到副本时，服务会将该消息同步传输到其他副本，以便连接到其他位置的客户端可以接收该消息。 对于最常见的消息模式，同步开销很小，例如向大型组广播或向单个连接发送消息。 向小组（少于 10 个成员）发送消息可能会导致同步开销略有增加。
Azure SignalR 服务不会持久保存消息;只有活动传递在副本之间同步。
区域故障期间的行为
本部分介绍如何配置 Azure SignalR 服务以实现异地复制，以及在一个副本区域发生中断时可能遇到的情况。
- 检测和响应：SignalR 服务负责检测区域内的故障，并自动将传入流量重新路由到您配置的其他区域中的副本。
- 通知： Azure 不会在某个区域关闭时自动通知你。 但是，可以使用 Azure 服务运行状况 来了解服务的总体运行状况，包括任何区域故障，并且可以设置 服务运行状况警报 来通知问题。
活动请求： 删除与失败区域中副本的活动连接。 在副本故障转移后，客户端必须重新连接。
预期数据丢失： Azure SignalR 服务，不会保留消息。 在发生故障时传输到失败区域中的客户端的消息可能会丢失。 由于服务不存储客户数据，因此不会造成永久性数据丢失。
预期停机时间： Azure 流量管理器 针对每个副本执行运行状况检查。 当区域中断导致副本运行状况检查失败时，流量管理器会从其 DNS 解析结果中删除该副本的终结点。 删除终结点后，在客户端看到更新的 DNS 记录之前，DNS TTL 必须经过 90 秒。 总共，转换通常需要几分钟时间。 在重新连接到正常副本后，实现重新连接逻辑的精心设计的客户端可以恢复正常操作。
如果主控制平面不可用，则无法对SignalR 服务资源或其副本的配置进行任何更改。 但是，连接将继续在正常运行的副本中工作。
Redistribution： Azure 流量管理器将传入请求定向到正常运行的副本。 但是，如果客户端在Azure 流量管理器检测到副本故障转移并且更新的DNS条目尚未传播到客户端之前尝试重新连接，则客户端的重新连接尝试可能会继续面向不可用的区域，并且可能会失败。
DNS 更新传播后，重新连接客户端会自动路由到最近的正常副本。
区域恢复
故障区域恢复时，Traffic Manager 健康检查会检测到已恢复的副本，并将其端点重新纳入 DNS 解析中。 当前连接到其他副本的客户端不会受到影响，并且一直保持连接，直到它们断开连接。 当新连接是最接近正常的副本时，再次路由到恢复区域的副本。
针对区域故障进行测试
若要模拟区域故障转移并测试客户端应用程序的重新连接行为，可以禁用副本的终结点。 此操作会导致流量管理器停止将流量路由到该副本，这样就可以观察客户端连接到的副本变得不可用时客户端的行为方式。 有关详细步骤，请参阅 “禁用”或“启用副本终结点”。
用于复原的自定义多区域解决方案
如果需要跨区域复原但未使用异地复制，则可以在多个区域中部署和管理单独的SignalR 服务资源，并在应用程序服务器中实现自己的故障转移逻辑。 此方法比异地复制更为复杂，不支持客户端到客户端连接的零停机时间故障转移。 有关详细的体系结构概述、故障转移模式和测试指南，请参阅 Azure SignalR 服务中的弹性和灾难恢复。
备份和还原
Azure SignalR 服务是无状态消息传送服务。 它不会保留客户消息，并且没有备份或还原功能。
若要保护资源配置，请使用基础结构（如Bicep或 ARM 模板）定义SignalR 服务资源，并将这些定义存储在源代码管理中。 如果需要重新创建资源，请从存储的配置重新部署它。
服务维护期间的系统弹性能力
Microsoft定期应用服务更新并执行其他维护。 Azure平台会自动处理这些活动，确保维护是无缝且透明的。 除非通过 Azure 服务运行状况 计划内维护 通知，否则在维护事件期间不会有停机。
在计划内维护期间，Azure SignalR 服务使用正常关闭策略来降低对已连接客户端的影响。 连接在设定的时间窗口内逐渐断开，使客户能够逐步重新连接，而不是一次性重新连接。 有关详细信息，请参阅 服务维护期间的断开连接。
当连接断开时，维护事件会显示给客户端。 确保您的客户端应用程序实现重新连接逻辑，这样它们就可以从与维护相关的断开连接中恢复，而不会造成用户可见的中断。
服务级别协议
Azure服务的服务级别协议（SLA）描述了每个服务的预期可用性以及解决方案必须满足的条件，以实现该可用性预期。 有关详细信息，请参阅 联机服务的 SLA。