4、多AZ高可用架构：同城双活、异地多活、跨AZ流量调度
说到多AZ架构，我脑子里第一个蹦出来的画面，是几年前某次大促前的压测现场。当时我们以为同城双活已经稳了，结果流量一上来，主AZ扛了90%，备AZ几乎在“看戏”。说白了，架构画得再漂亮，流量调度没做好，一切都是白搭。
今天咱们就聊聊多AZ高可用这件事。我会把同城双活、异地多活、跨AZ流量调度这三个核心点拆开讲，顺便穿插一些我踩过的坑。
4.1 同城双活：距离近，延迟低
同城双活，就是在一个城市里建两个AZ。两个AZ之间通过专线互联，延迟通常在1-2ms以内。你想想看，这个延迟几乎可以忽略不计。
核心思路：两个AZ同时承载业务流量，任何一个AZ挂了，另一个AZ能直接接管全部流量。注意，是“同时承载”，不是“主备”。
关键点：同城双活要求应用层无状态，数据层必须支持多活写入或近实时同步。
我在项目中遇到过一种情况：业务团队说“我们已经是双活了”，结果一查，数据库还是主备模式。主AZ挂了，数据库切换要30秒，业务直接中断。嗯，这里要注意——双活不是简单的部署两套，而是从网络到数据都要能同时读写。
4.2 异地多活：距离远，挑战大
异地多活，说白了就是跨城市甚至跨地域部署。比如上海一个AZ，北京一个AZ。距离远了，延迟就成了大问题。上海到北京的专线延迟大概在10-20ms，这可不是闹着玩的。
为什么还要做异地多活？ 因为同城双活扛不住区域性灾难。比如整个城市停电、地震，同城双活就废了。异地多活才是真正的“保命”方案。
我曾经参与过一个异地多活的项目，踩了最大的坑就是——流量调度策略太粗糙。我们一开始按地域就近接入，结果上海的用户全打到北京AZ去了，延迟飙升，用户体验直线下降。后来我们改成了基于DNS+GSLB的智能调度，才把问题解决。
避坑指南：我曾经以为异地多活只要把代码部署两套就行，结果发现数据一致性才是最大的难题。跨AZ的数据同步，建议用异步复制，别用强一致，否则延迟会让你崩溃。
4.3 跨AZ流量调度：核心中的核心
流量调度，说白了就是“把用户请求送到最合适的AZ”。怎么才算“最合适”？延迟低、负载低、可用性高。这三者往往需要权衡。
常见的调度手段：
- DNS调度：按地域解析到不同AZ的入口IP。简单，但生效慢（TTL缓存问题）。
- GSLB调度：全局负载均衡，基于健康检查和负载情况动态调整。我建议优先用这个。
- Anycast调度：多个AZ共享同一个IP，路由协议自动选路。延迟最优，但排障困难。
我个人习惯是：DNS做粗粒度调度，GSLB做细粒度调度。比如，先按省份把用户分到不同AZ，再根据AZ的实时负载做二次调度。
4.4 架构图：多AZ流量调度逻辑
下面这张图是我自己画的，展示了同城双活+异地多活的流量调度逻辑。你仔细看，核心就是“入口分流、AZ内闭环、跨AZ兜底”。
你看这个图，用户请求先到DNS/GSLB，然后根据策略分到同城AZ1或AZ2。两个AZ之间通过专线同步数据。如果同城两个AZ都挂了，GSLB会把流量切到异地AZ。这就是典型的“两地三中心”架构。
4.5 流量调度策略对比
| 策略 | 延迟 | 成本 | 复杂度 | 适用场景 |
|---|---|---|---|---|
| DNS就近接入 | 低 | 低 | 低 | 静态业务，用户地域分布明确 |
| GSLB动态调度 | 中 | 中 | 中 | 动态业务，需要负载均衡 |
| Anycast | 最低 | 高 | 高 | 对延迟极度敏感的业务 |
| 手动切流 | 最高 | 最低 | 最低 | 应急场景，临时兜底 |
我的建议：别一上来就搞Anycast，成本高、排障难。先从DNS+GSLB入手，等业务规模上去了再考虑升级。我在项目中吃过Anycast的亏——流量调度没问题，但出了问题根本查不到是哪个AZ的节点在响应。
4.6 跨AZ流量调度的核心原则
最后，我总结几条原则，你记一下：
- 健康检查是命根子：没有健康检查的调度就是盲人摸象。我建议每5秒做一次探测，连续3次失败就摘除节点。
- 灰度切流：别一下子把100%流量切过去。先切1%，观察5分钟，没问题再逐步增加。我曾经因为切流太快，把异地AZ打挂了，教训深刻。
- 数据同步是瓶颈：跨AZ的数据同步延迟决定了你的RPO。同城用同步复制，异地用异步复制，别搞反了。
- 回滚方案要提前准备：调度策略出问题，怎么快速回滚？脚本、工具、权限，都得提前准备好。别等出事了再临时写脚本。
嗯，多AZ高可用这件事，说白了就是“用钱换时间，用架构换稳定”。你设计得再好，没有流量调度，一切都是空谈。希望今天的内容对你有帮助。
公众号:蓝海资料掘金营，微信deep3321