浅析多可用区容灾、多活到两地三中心的架构
0. 引言
高可用架构设计从单机房走向多可用区、同城多活乃至两地三中心，每一层（基建、入口、逻辑、数据、公共组件）都有各自的容灾要点。本文先厘清核心概念，再按 DNS、LB、MySQL 三个层面讲解高可用设计。
1. 核心概念
| 概念 | 说明 |
|---|---|
| 地域 | IDC 规划、业务覆盖范围与网络质量评估的基本单元，以城市为最小单元命名 |
| 可用区 | 独立机房 IDC，风火水电与网络需物理隔离；同城多可用区距离通常 100 公里内，互访延迟尽量在 2ms 以内 |
| 可用区容灾 | 两个以上可用区以主备形式存在，备区平时不对外服务，主区故障时切换 |
| 同城多活 | 同地域多个可用区同时对外服务，一个可用区故障不影响整体访问 |
| 两地三中心 | 同城双活数据中心 + 异地灾备数据中心 |
高可用设计关注的五层：入口层（代理网关、负载均衡）、逻辑层（代码服务）、数据层（数据/文本存取）、基建层（物理设施与网络设备）、公共组件层（DNS、K8s 等平台化服务）。各层要点：基建层要求独立设施与低延迟；逻辑层尽量把状态下放到数据层以支持弹性扩容；公共组件层提供多可用区调度；入口层从 DNS 解析考虑流量分配与故障调度；数据层要求数据一致性与实时性，是数据库多活的最大难题。
2. 入口层：DNS 服务高可用设计
2.1 DNS 服务本身的高可用
DNS 协议本身具备可靠性（多个 DNS 地址、权威 DNS 自动切换）。大企业把权威 DNS 分地域部署并结合主从架构：一个地域 AZ 的 DNS 故障后，其他地域的权威 DNS 仍可正常解析；后端启用一套配置与数据服务源，负责配置文件与 DNS 数据文件的同步分发。大流量场景再结合 Anycast：Anycast + DNS 分地域部署，从入口层打散流量请求，并实现动态容灾。
2.2 DNS 解析的高可用模式
轮询解析模式：服务端返回多个 AZ 记录的 A 解析，客户端轮询访问，降低单点压力；实现简单，但无法按用户地域智能调度。
智能 DNS：动态判断访问者来源 IP 与地域，返回针对地域的特定 IP。广州用户请求解析时返回广州节点 IP，北京用户返回北京节点 IP，把不同地域用户调度到最近的 AZ 服务节点，既打散请求又降低延迟。缺点是自建难度与成本高，小企业多用第三方服务。
2.3 局部切换：LB 级别容灾
可用区整体挂掉的情况并不多见，常见的是可用区内部分服务故障（如 LB 调用 DB 异常）。通过 DNS 整体切换代价大，更优的做法是局部切换：LB 直接切换到可用区 2 的 DB。这要求底层网络支持多可用区 IP 分发，让 LB 能通过 VIP 在多可用区间动态飘移。
3. 数据层：MySQL 服务高可用设计
3.1 主从同步原理
数据先写入主库，主库以 Binlog 方式记录日志；从库 IO 线程从主库拉取 Binlog 写入本地 relay log，SQL 线程读取 relay log 写入本地数据库。主库的任何更改都能通过 Binlog 同步到从库。
3.2 灾备模式（主备）
AZ2 部署主库、AZ1 部署从库，正常时读写 AZ2，从库以 Binlog 方式同步。AZ2 故障后，通过前端 LB、数据库代理或应用层做读写切换，把流量切到 AZ1 的库。AZ2 恢复后需重做主从，可用自动化工具自动修复。该模式要求网络延迟尽量低（1-2ms 范围）。
3.3 双活模式（互相同步）
双活要求两个可用区同时对外服务，两个 DB 之间要相互同步。MySQL 原生 Binlog 很难实现双向同步（存在数据写入回环问题），通常自研同步工具解决：
- MySQL1 写入数据时本地生成 Binlog；
- 自研同步进程（如 Rsync SQL）读取 Binlog 并反向解析成 SQL 语句，同步执行到 MySQL2；
- 必须处理回环问题：数据同步到 AZ1 后可能又被同步回 AZ2 造成重复写入，需通过设置标签等方案避免重复同步。
4. 小结
多可用区高可用设计的核心分层：DNS 层解决"用户从哪进"（轮询/智能 DNS/Anycast），LB 层解决"局部故障怎么切"（VIP 飘移），MySQL 层解决"数据怎么不丢"（灾备走主从切换、双活走自研双向同步 + 防回环）。演进路径是从可用区容灾（主备）到同城多活（双活）再到两地三中心（双活 + 异地灾备），每进一步，数据一致性与网络延迟的挑战都成倍增加，需要按业务可用性目标（RTO/RPO）选择合适层级。
下一章浅析云原生关键技术，把容器、服务网格、DevOps 串成完整的云原生技术体系。