高可用是大型架构核心，下面我详解阿里高可用系统@mikechen
阿里高可用系统
在互联网业务快速发展的背景下，系统高可用性已成为企业基础架构设计的核心目标之一。
对于阿里这样的超大规模互联网公司而言，业务连续性不仅关系到用户体验，也直接影响交易安全、品牌信誉与商业收益。
因此，阿里在系统架构上普遍采用：“两地三中心”等容灾模式，以实现99.99%甚至更高等级的可用性。
99.99%意味着全年不可用时间约52.6分钟，因此需要从单机、机房、可用区到地域多个故障域进行设计。
两地三中心
所谓“两地三中心”，是指在两个地理区域内部署三个数据中心。
其中通常包含一个主中心、一个同城灾备中心以及一个异地灾备中心。
[ 流量入口: DNS / Global SLB / CDN ]
│
┌─────────────────────────┴─────────────────────────┐
│ (同城双专线 <2ms) │ (异地专线 >10ms)
▼ ▼
┌──────────────────────┐ ┌──────────────────────┐
│ 同城中心 A │ ◄───(同城实时同步)───► │ 异地中心 C │
│ (应用集群 + 主DB) │ │ (冷备/残血双活/灾备) │
└───────────┬──────────┘ └──────────────────────┘
│
│ (同城实时同步)
▼
┌──────────────────────┐
│ 同城中心 B │
│ (应用集群 + 备DB) │
└──────────────────────┘
同城中心 A：承担主要业务流量的读写。
同城中心 B：同城双活/主备，通过专线）实现数据强同步或同步复制。
异地中心 C：跨省/跨区域（如杭州-北京/深圳），防止区域性灾难（地震、特大暴雨、大面积断电），通过异步复制传输数据。
当某一个数据中心彻底失效（如挖掘机挖断光缆、机房断电）：
同城故障（中心 A 宕机），接入层：GSLB 秒级将流量从中心 A 摘除，全量切到同城中心 B。
异地灾难（整个城市 A/B 瘫痪），路由重切：将原来分配在城市 A/B 单元的用户规则切至异地中心 C。
这样的设计能够在单机故障、机房故障、城市级灾害等不同层级的风险事件中，保证业务具备快速切换和持续运行的能力。