Azure Web PubSub 服务中的复原能力和灾难恢复
复原能力和灾难恢复是联机系统的常见需求。 Azure Web PubSub 服务可保证 99.9% 的可用性，但它仍是一个区域性的服务。 发生区域范围的服务中断时，服务能够继续在另一区域中处理实时消息是至关重要的。
对于区域灾难恢复，建议采用以下两种方法：
- 启用异地复制（简便方法）。 此功能将自动处理区域故障转移。 启用后，将仅保留一个 Azure SignalR 实例，并且不会引入任何代码更改。 有关详细信息，请查看异地复制。
- 利用多个终结点。 本文档将介绍此操作
Web PubSub 服务的高可用性体系结构
使用 Web PubSub 服务有两种典型模式：
- 一种是客户端-服务器模式，即客户端向服务器发送事件，然后服务器将消息推送到客户端。
- 另一种是客户端-客户端模式，即通过 Web PubSub 服务向其他客户端发送发布/订阅消息。
以下部分描述了这两种模式进行灾难恢复的不同方法
客户端-服务器模式的高可用性体系结构
若要获得 Web PubSub 服务的跨区域复原能力，需要在不同的区域中设置多个服务实例。 这样，当某个区域出现故障时，可将其他区域用作备用区域。
跨区域方案的一种典型设置是使用两对（或更多对）Web PubSub 服务实例和应用服务器。
在内部，每对应用服务器和 Web PubSub 服务位于同一区域，Web PubSub 服务在同一区域中的应用服务器上游设置事件处理程序。
为了更好地演示该体系结构，我们将 Web PubSub 服务称作同一对中应用服务器的“主要”服务。 我们将其他对中的 Web PubSub 服务称作应用服务器的“辅助”服务。
应用程序服务器可以使用服务运行状况检查 API 检测其“主要”和“辅助”服务是否正常。 例如，对于名为 demo 的 Web PubSub 服务，如果该服务正常，则终结点 https://demo.webpubsub.azure.com/api/health 将返回 200。 应用服务器可以定期调用终结点或按需调用终结点来检查终结点是否正常。 WebSocket 客户端通常先与其应用程序服务器协商以获取连接到 Web PubSub 服务的 URL，应用程序使用此协商步骤将客户端故障转移到其他正常的“辅助”服务。 详细步骤如下：
- 当客户端与应用服务器协商时，应用服务器应该只返回主要 Web PubSub 服务终结点，因此在正常情况下，客户端只连接到主要终结点。
- 当主要实例关闭时，协商命令应该返回正常的辅助终结点，使客户端仍可建立连接；客户端将连接到辅助终结点。
- 当主实例启动时，协商应该返回正常的主要终结点，以便客户端现在可以连接到主要终结点
- 当应用服务器广播消息时，应该将消息广播到所有正常的终结点，包括主要终结点和辅助终结点。
- 应用服务器可以关闭连接到辅助终结点的连接，以强制客户端重新连接到正常的主要终结点。
使用此拓扑时，来自一个服务器的消息仍可传送到所有客户端，因为所有应用服务器和 Web PubSub 服务实例是互连的。
我们尚未将策略集成到 SDK 中，所以现在应用程序需要靠自身实现此策略。
综上所述，应用程序端需要实现的是：
- 运行状况检查。 应用程序可以通过下列两种方式之一来检查服务是否正常运行：在后台定期使用服务运行状况检查 API，或者根据需要对每个“协商”调用使用此 API。
- 协商逻辑。 默认情况下，应用程序返回正常运行的主要终结点。 当主要终结点关闭时，应用程序返回正常运行的辅助终结点。
- 广播逻辑。 向多个客户端发送消息时，应用程序需要确保将消息广播到所有正常运行的终结点。
下图演示了这种拓扑：
故障转移序列和最佳做法
现已设置正确的系统拓扑。 每当某个 Web PubSub 服务实例关闭时，联机流量将路由到其他实例。 下面是当主要实例出现故障（以及一段时间后进行恢复）时发生的情况：
- 主要服务实例已关闭，已连接到此实例的所有客户端均将断开连接。
- 新客户端或重新连接的客户端与应用服务器协商
- 应用服务器检测到主要服务实例已关闭，协商命令将停止返回此终结点，并开始返回正常的辅助终结点。
- 客户端连接到辅助实例。
- 现在，辅助实例将接收所有联机流量。 由于辅助实例已连接到所有应用服务器，因此从服务器发往客户端的所有消息仍可传送。 但是，从客户端到服务器的事件消息只发送到同一区域中的上游应用服务器。
- 主要实例恢复并重新联机后，应用服务器将检测主要实例是否恢复正常状态。 协商现在会再次返回主要终结点，因此，新客户端将重新连接到主要实例。 但是，现有客户端不会断开连接，而是继续连接到辅助实例，直到它们自行断开连接。
下图演示了故障转移的执行方式：
图 1：故障转移之前 
图 2：故障转移之后
图 3 主实例恢复后的短时间内
可以看到，在正常情况下，只有主要应用服务器和 Web PubSub 服务包含联机流量（以蓝色表示）。
故障转移后，辅助应用服务器和 Web PubSub 服务也处于活动状态。 主要 Web PubSub 服务重新联机后，新客户端将连接到主要 Web PubSub。 但是，现有客户端仍连接到辅助实例，因此这两个实例都包含流量。
所有现有客户端断开连接后，系统将会恢复正常（图 1）。
可以使用两种主要模式来实现跨区域的高可用性体系结构：
- 第一种模式是使用一对应用服务器和 Web PubSub 服务实例来接收所有联机流量，并使用另一对作为备用实例（称为主动/被动配置，如图 1 所示）。
- 另一种模式是使用两对（或更多对）应用服务器和 Web PubSub 服务实例，其中每个实例接收一部分联机流量，并充当其他对的备用实例（称为主动/主动配置，类似于图 3）。
Web PubSub 服务支持这两种模式，主要差别在于实现应用服务器的方式。 如果应用服务器采用主动/被动配置，则 Web PubSub 服务也采用主动/被动配置（因为主要应用服务器仅返回其主要 Web PubSub 服务实例）。 如果应用服务器采用主动/主动配置，则 Web PubSub 服务也采用主动/主动配置（因为所有应用服务器将返回其自己的主要 Web PubSub 实例，因此它们都可以接收流量）。
请注意，无论选择使用哪种模式，都需要将每个 Web PubSub 服务实例作为“主要”角色连接到应用服务器。
另外，由于 WebSocket 连接的性质（远距离连接），发生灾难和故障转移时，客户端会遇到连接断开的情况。 需要在客户端上处理这种情况，使其对最终客户透明。 例如，关闭连接后不要重新连接。
客户端-客户端模式的高可用性体系结构
对于客户端-客户端模式，目前还无法支持使用多个实例的零停机时间灾难恢复。 如果有高可用性要求，请考虑使用异地复制。
如何测试故障转移
按照以下步骤触发故障转移：
- 在门户中主要资源的“网络”选项卡中，禁用公用网络访问。 如果资源已启用专用网络，请使用访问控制规则来拒绝所有流量。
- 重启主要资源。
后续步骤
在本文中，你已了解如何配置应用程序以实现 Web PubSub 服务的复原能力。
使用这些资源开始生成自己的应用程序：