云服务多区域部署与健康检查全解析

### 云服务多区域部署与健康检查全解析 #### 1. 多区域部署的必要性与拓扑选择 在当今的云服务环境中，多区域部署变得越来越重要。因为区域中断的原因可能是不可预测甚至前所未有的，而多区域部署能够确保在遇到新的区域中断情况时，部分用户不受影响。 当然，有些自治服务并非关键服务，可以在单区域运行，但多区域设置是常见做法，排除它们反而需要更多精力。而有些关键服务在多区域大规模运行时，则需要细致考虑。 在多区域部署中，有两种主要的区域拓扑可供选择： - **主/热备拓扑（Primary/Hot - Secondary）**：这是传统系统中最常见的区域拓扑。通常将用户路由到主区域（如东部区域），在出现问题时故障转移到备用区域（如西部区域）。在传统系统中，故障转移过程通常需要手动干预，更准确地说应称为主/冷备拓扑。而在无服务器系统中，采用主/热备拓扑，所有服务会部署在两个区域，并且通过近乎实时的数据复制确保服务随时可用。同时，利用区域健康检查服务和区域路由配置实现自动化的区域故障转移。这种拓扑对于新的无服务器系统是一个很好的起点，也是那些对多区域支持有限的外部依赖系统的最佳选择。 - **双活拓扑（Active/Active）**：这是最复杂的区域拓扑，是主/热备拓扑的渐进式演进。但在使用时需要仔细考虑各种使用场景的并发特性。例如，多个区域同时更新相同数据时，可能会出现一个区域覆盖另一个区域更新的情况。双活拓扑有两种变体： - **用户均衡（Balanced Users）**：无服务器系统需要支持多个地理区域的用户。以食品配送系统为例，它在全国范围内运行并可能扩展到其他国家。为了让所有用户都能获得最佳性能，使用基于延迟的路由将用户均衡分配到多个区域，确保将用户路由到最近的健康区域。这样，当一个区域出现故障时，不会直接影响其他健康区域的用户。在这种情况下，通常不存在区域并发问题。但像库存系统这样的系统，在库存消耗时可能会出现竞争问题。对于这类系统，可以让读模型采用双活模式，写模型采用主/备模式。 - **数据处理均衡（Balanced Data Processing）**：当用户在BFF服务上调用命令时，会引发下游服务对域事件的连锁反应。数据处理在发起命令的同一区域异步进行，结果会复制到其他区域。在双活拓扑中，这会基于用户的地理位置自然平衡后台数据处理。但并非所有数据处理都是用户操作的直接结果。例如，在执行多区域定时任务时，为避免重复数据处理，应确保只在主区域启动定时任务。对于大多数系统，即使BFF服务配置为双活拓扑，后台数据处理采用主/备拓扑也是可行的，处理结果会近乎实时地复制到其他区域。如果系统的数据更具时效性，可以实现基于内容的路由逻辑，将数据分发到最佳区域以平衡数据处理负载。 #### 2. 为区域故障转移做准备 从传统的单体系统角度来看，设计一个多区域运行的系统似乎是一项艰巨的任务。在云计算出现之前，系统通常只设计为在一个本地数据中心运行，演示层假设网络连接始终可用，数据层需要强一致性，部署未自动化，故障转移需要手动操作且通常涉及从最新备份恢复数据库，过程耗时。将这些脆弱的系统改造为在多个云区域运行非常痛苦，通常最多只能实现主/冷备拓扑。 相比之下，无服务器系统从一开始就设计为多区域运行。在当今高度互联的世界中，系统的环境和期望有了很大不同。以下是前端和后端为多区域运行所做的重要改进： - **离线优先（Offline - first）**：用户高度移动，期望应用程序始终可用。因此，无服务器系统的演示层需要设计为能够承受间歇性网络连接中断，并为用户提供无缝体验。采用离线优先方法，通过入站和出站缓存（即隔离舱）强化前端。在读取数据时，采用陈旧数据验证缓存策略，优先为用户提供陈旧数据而非无数据或错误信息。主动缓存参考数据，并在后台刷新所有查询以确保数据尽可能最新。在写入数据时，通过在本地存储用户更改来实现会话一致性，然后再将其发送到后端。如果出现中断，将更新排队并在后台无缝重试，同时更新缓存以便读取更改。前端会向用户透明展示网络连接状态和缓存数据的新鲜度，帮助用户在中断期间利用现有数据做出明智决策。同时，后端的最终一致性方法有助于在故障转移到健康区域时实现平稳过渡。 - **长期最终一致性（Protracted Eventual Consistency）**：通过创建具有入站和出站隔离舱的自治服务，确保无服务器系统的健壮性和弹性。上游服务即使下游消费者不健康也会产生事件，下游服务会缓存所需数据，即使上游服务不健康也能继续工作。通过命令发布 - 消费 - 查询（CPCQ）流程将这些服务链接在一起，编排复杂的业务流程。每个事件都会引发下游事件的连锁反应，确保系统最终一致。在一切顺利时，可实现近乎实时的一致性。当服务不健康时，可能不会立即消费事件，但恢复后会最终消费所有所需事件。在区域中断期间，由于不健康区域的错误率增加，连锁反应可能会减慢，但事件最终会通过，更新会跨区域复制。这种情况可视为长期最终一致性，系统达到一致状态可能需要更长时间，但最终会实现一致。同时，前端的透明度让用户了解进度。在这个过程中，增加的错误率会导致更多重试，但由于每个自治服务都具备幂等性，这不是问题。事件接收顺序可能会受到影响，但通过采用逆操作锁和事件状态转移等技术，系统能够容忍事件乱序接收。 #### 3. 区域健康检查 为了确定何