APIRouter ： 路由分发服务
API Router 是一个 HTTP 反向代理和负载均衡器，部署在公有云中作为 HTTP API 流量的入口，它能识别
出流量的归属 shard ，并根据 shard 将流量转发到对应的 ezone 。 API Router 支持多种路由键，可以
是地理位置，也可以是商户 ID ，订单 ID 等等，最终由 API Router 映射为统一的 Sharding ID 。
Global Zone Service ：全局状态协调器
GZS 维护着整个多活的路由表，其他所有的服务都从 GZS 订阅路由信息。切换机房的操作也在 GZS 控
制台中完成。路由表包括：地理围栏信息， shard 到 ezone 的归属信息，商铺 ID ／订单 ID 等路由逻辑
层到 shard id 的映射关系等。 GZS 通过在 SDK 端建立 Cache ，来保证 shard 逻辑能够最快速度执行，
基本不需要和 GZS 交互，同时也有实时推送机制，确保在数据变更后能够快速通知到其他的服务。
SOA Proxy ：内部网关
SOA Proxy 实现了对 SOA 调用的路由，执行和 API Router 相似的逻辑，但只用在机房之间进行通信的
场景。业务使用 SOA Proxy 需要对代码做一些修改，把路由信息加入到调用的上下文中。
Data Replication Center ：数据复制
DRC 负责 Mysql 数据的实时双向复制，保证跨机房延时在 1s 以内。提供了基于时间的冲突解决方案，
确保各个机房的数据一致。 DRC 除了复制数据，还对外提供了数据变更的通知，让业务能够感知到其他
机房的数据变化，做相应的处理，例如清除 Cache 等。
除了 DRC ，我们还有 ZK 复制工具， RMQ 复制工具， Redis 复制工具，基本每个数据层次，都有对应的
复制方案。
Data Access Layer ：数据访问
数据访问层支撑了 Globa Zone 的逻辑，还提供了最后一道保护，拒绝路由错误的数据写入，是多活最 底层的支撑。
Mysql 数据复制工具 DRC:
Mysql 的数据量最大，每个机房产生的数据，都通过 DRC 复制到其他 ezone ，每个 ezone 的主键取值 空间是ezoneid + 固定步长，所以产生的 id 各不相同，数据复制到一起后不会发生主键冲突。按照分区 规则，正常情况下，每个 ezone 只会写入自己的数据，但万一出现异常， 2 个 ezone 同时更新了同一笔 数据，就会产生冲突。DRC 支持基于时间戳的冲突解决方案，当一笔数据在两个机房同时被修改时，最 后修改的数据会被保留，老的数据会被覆盖。
整体结构
推荐阅读
设计：异地多活的实现思路和方法