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，应用程序使用此 握手步骤将客户端切换至其他健康的备用服务。 详细步骤如下：

1. 当客户端与应用服务器 协商 时，应用服务器应仅返回主 Web PubSub 服务终结点，因此在正常情况下，客户端仅连接到主终结点。
2. 当主实例出现故障时， 协商 SHOULD 返回一个正常的辅助终结点，使客户端仍能建立连接，并连接到该辅助终结点。
3. 当主实例启动时，协定应该返回正常的主终结点，以便客户端能够连接到主终结点。
4. 当应用服务器 广播消息时，它应将消息 广播 到所有 正常的 终结点，包括 主要 终结点和 辅助终结点。
5. 应用服务器可以关闭连接到 辅助 终结点的连接，以强制客户端重新连接到正常的主终结点。

使用此拓扑，一台服务器的消息仍可传送到所有客户端，因为所有应用服务器和 Web PubSub 服务实例都是互连的。

我们尚未将策略集成到 SDK 中，因此现在应用程序需要自行实施此策略。

总之，应用程序端需要实现的是：

1. 运行状况检查。 应用程序可以定期在后台使用 服务健康检查 API 来检查服务是否正常，也可以在每次 协商 调用时按需检查。
2. 谈判逻辑 默认情况下，应用程序返回正常的 主 终结点。 当主要终结点关闭时，应用程序将返回正常运行的辅助终结点。
3. 广播逻辑。 将消息发送到多个客户端时，应用程序需要确保将消息广播到所有 正常的 终结点。

下图演示了此类拓扑：

故障转移序列和最佳做法

现已设置正确的系统拓扑。 每当一个 Web PubSub 服务实例关闭时，联机流量将路由到其他实例。 下面是主实例关闭时会发生什么情况（并在一段时间后恢复）：

1. 主服务实例已关闭，连接到此实例的所有客户端都将被删除。
2. 新客户端或重新连接客户端与应用服务器协商
3. 应用服务器检测到主服务实例已关闭，协商停止返回此终结点并开始返回正常的辅助终结点。
4. 客户端连接到辅助实例。
5. 现在，辅助实例将接收所有联机流量。 由于备份服务器已连接到所有应用服务器，因此从服务器到客户端的所有消息仍然可以传递。 但客户端到服务器事件消息仅发送到同一区域中的上游应用服务器。
6. 恢复主实例并重新联机后，应用服务器将检测到主实例恢复正常。 协商现在将再次返回主终结点，确保新客户端能重新连回主终结点。 但是，现有客户端不会被删除，并且将继续连接到辅助客户端，直到它们自行断开连接。

下图展示了故障转移的实现方式：

在的 Fig.1

故障转移图 2

Fig.3 主恢复后不久

正常情况下，只有主应用服务器和 Web PubSub 服务具有联机流量（蓝色）。

故障转移后，备用应用服务器和 Web PubSub 服务也处于活动状态。 主 Web PubSub 服务重新联机后，新客户端将连接到主 Web PubSub。 但是，现有客户端仍连接到从属实例，因此这两个实例都接收流量。

所有现有客户端断开连接后，系统将会恢复正常（图 1）。

可以使用两种主要模式来实现跨区域的高可用性体系结构：

1. 第一个实例是让一对应用服务器和 Web PubSub 服务实例获取所有联机流量，并将另一对作为备份（称为主动/被动，如图 1 所示）。
2. 另一个方案是使用两对（或更多对）应用服务器和 Web PubSub 服务实例，每个实例承担部分在线流量，并为其他对提供备份服务（称为主动/主动模式，类似于图 3）。

Web PubSub 服务可以支持这两种模式，主要区别在于如何实现应用服务器。 如果应用服务器是主动/被动的，Web PubSub 服务也将是主动/被动（因为主应用服务器仅返回其主 Web PubSub 服务实例）。 如果应用服务器处于活动状态/主动，Web PubSub 服务也将处于活动状态/主动（因为所有应用服务器都将返回自己的主 Web PubSub 实例，因此所有这些服务器都可以获取流量）。

无论选择使用哪种模式，都需要将每个 Web PubSub 服务实例作为 主要 角色连接到应用服务器。

此外，由于 WebSocket 连接的性质（这是一个长时间的连接），客户端在发生灾难和故障转移时会遇到连接下降。 你需要在客户端处理此类情况，使其对最终客户透明。 例如，关闭连接后不要重新连接。

适用于客户-客户模式的高可用体系结构

对于客户端模式，目前无法使用多个实例支持零下限灾难恢复。 如果有高可用性要求，请考虑使用 异地复制。

如何测试故障转移

按照以下步骤触发故障转移：

1. 在门户中主要资源的“网络”选项卡中，禁用公用网络访问。 如果资源已启用专用网络，请使用访问控制规则来拒绝所有流量。
2. 重启主要资源。

后续步骤

本文介绍了如何配置应用程序以实现 Web PubSub 服务的复原能力。

使用这些资源开始生成自己的应用程序：