阿里双11
每年 双十一购物狂欢节 期间，阿里巴巴集团 的交易系统需要承受 峰值数百万 QPS、每秒几十万订单 的巨大流量。
一旦某个机房出现故障，如果系统无法快速切换，就可能造成大规模交易中断。
为了解决这一问题，阿里核心系统采用了 异地多活架构，全程是：“Multi-Active Architecture”。
异地多活架构
异地多活：是指在多个城市部署多个数据中心，每个机房都能同时对外提供服务。
即使某个机房宕机，系统仍然可以继续运行。
这种架构常见于大型互联网系统，例如 阿里巴巴集团 在 双十一购物狂欢节 场景下的核心交易系统。
如下所示：
用户请求 │ ▼ 全局流量调度（DNS / GSLB） │ ┌───────────────┬───────────────┐ ▼ ▼ ▼ 杭州机房 上海机房 深圳机房 (Active) (Active) (Active) │ │ │ ├──微服务集群───┼──微服务集群───┤ │ │ │ └──数据库同步（多主/复制）
该架构通过多地数据中心同时对外提供服务，在设计上解决了容量扩展、容灾切换与低时延访问的核心问题。
首先要解决：
用户请求进入哪个机房？
通常通过 全局负载均衡（GSLB） 实现：
北京用户 → 上海机房 广州用户 → 深圳机房 杭州用户 → 杭州机房
进入机房后，再通过多层负载均衡分发：
DNS → SLB → Nginx → 微服务。
然后，每个机房都部署 完整业务系统。
用户服务 订单服务 库存服务 支付服务
这样即使某个机房宕机，流量自动切到其他机房，用户几乎无感知。
然后，最小落地。
比如：搭建两个机房/两个地域集群（同一云厂商两个可用区也行）。
接入层：用一个全局负载均衡 + 健康检查，先按“地域就近”或“用户ID奇偶”分流。
数据层：选
要简单就用“一个主库 + 跨地域只读库”做单写多读；
要多活就按“用户ID%2”分片，偶数在A中心写，奇数在B中心写，各自异步复制给对方。
演练：手动“拔掉”一个中心，看是否还能访问、数据是否能在几秒内追平。
总之，异地多活，让多个地域的数据中心（Region）,同时承担读写流量。
避免单点故障：和传统冷/热备切换的服务中断。