12 11 阿里云混沌测试容器服务混沌工程实践02--混沌平台演示

 

 

一、 架构深度解析：异地多活的“分而治之”

这个架构的核心思想是单元化（Cell-Based）设计。整个系统被划分为多个独立的“单元格”，每个单元格内包含完整的业务逻辑处理能力。

1. 流量的“单元化”路由（核心机密）

页面顶部的“设置用户ID”是理解这个架构的关键。在真实的异地多活系统中，通常会对用户ID进行哈希取模，或者通过“单元化路由规则”，将特定用户的所有请求（读+写）都固定路由到某一个城市的数据中心（例如：北京用户永远访问北京单元，杭州用户访问杭州单元）。

• 收益：实现了流量的天然物理隔离。北京单元宕机，只会影响分配到北京单元的那部分用户，而不会波及全国用户。

• 挑战：跨单元调用（比如北京用户想买杭州仓库的商品）会变得非常复杂，通常只允许读操作跨单元，写操作必须强约束在本单元内。

2. 数据层的“本地优先”策略

注意左侧的“北京单元”和右侧的“杭州中心单元”。每个单元内都有独立的“商品中心库”和“订单库”。

• 强一致性边界：在同一个单元内，应用、数据库、缓存（Redis）是紧密耦合的，这里可以使用我们之前讨论的半同步复制，保证本单元内的数据强一致性。

• 最终一致性边界：不同城市之间的同名数据库（如北京的商品库和杭州的商品库）通常是物理隔离的。它们的数据同步（如果业务需要全局商品视图）必须通过异步消息（MQ）来完成。这必然引入跨城网络延迟（通常在 20ms-100ms 级别），因此绝对不能在这些库上使用强一致性事务。

3. 故障隔离的极致体现

如果每个单元都是独立闭环，那么当一个城市发生地震或断网时，其他城市的单元依然可以提供完整的服务。这正是异地多活架构的终极目标——城市级容灾。