异地多活是大型架构核心，下面我详解阿里异地多活@mikechen
阿里异地多活
异地多活，顾名思义，是指将同一套业务系统，部署在不同地域的多个数据中心中，并且这些数据中心同时对外提供服务。
比如：
北京机房； 上海机房； 深圳机房；
同时运行同一套业务。
其中一个机房故障，流量自动切换，业务继续运行，这就是异地多活。
为什么需要异地多活
在大型互联网系统中，最怕的不是服务器宕机，而是：
机房整体故障； 城市级故障； 网络中断； 电力故障； 自然灾害；
如果整个机房挂掉，业务全部不可用，损失往往是千万甚至上亿元。
因此，阿里、淘宝、支付宝等核心系统都采用了：异地多活。
其目标是：
即使一个城市、一个机房完全瘫痪，业务依然正常运行。
阿里异地活动架构
整体架构，如下：
用户
│
┌───────────┼───────────┐
▼ ▼ ▼
北京单元 上海单元 深圳单元
│ │ │
▼ ▼ ▼
应用集群 应用集群 应用集群
│ │ │
▼ ▼ ▼
数据库 数据库 数据库
└──────同步复制──────┘
首先，在流量层。
如果用户的物理位置在上海，但其绑定的 user_id 属于杭州单元。
网关会通过内部网络直接将请求转发（或 304 重定向）给杭州 RZone 的应用，确保“正确的人，到正确的单元”。
其次，在应用层。
在本地单元（如杭州）内，用户的下单操作会调用一系列微服务（商品、库存、优惠券）。
阿里的 RPC 框架（HSF/Dubbo）和消息队列（RocketMQ），会默认将流量锁定在当前单元内部调用。
绝对禁止为了一个下单动作，去调用上海机房的服务（因为跨城 RT 延迟几十毫秒，会瞬间拖垮高并发系统）。
再次，在数据层。
杭州单元只写尾号 00~49 的用户数据，上海单元只写 50~99 的用户数据。
两个地域的数据库通过阿里云的 DTS（数据传输服务）进行双向实时异步复制。