亚马逊云国际站高可用架构设计：跨可用区（AZ）容灾与ELB负载均衡

在云计算时代，“高可用（High Availability, HA）”几乎是被各类架构师挂在嘴边的词。很多人认为，只要把系统搬上亚马逊云（AWS），买了EC2，配了负载均衡，高可用就自然实现了。

然而，真实的生产环境往往会给这种盲目乐观一记响亮的耳光。

当某个AWS可用区（Available Zone, AZ）因为底层光缆被挖断、电力故障或软件定义网络（SDN）异常而陷入瘫痪时，你的服务是会自动无缝切换，还是跟着一起宕机、客服电话被打爆？

真正的高可用架构不是买出来的，而是设计出来的。本文将彻底抛弃复杂的PPT黑话，用最通俗易懂的“大白话”，带你拆解亚马逊云国际站上最核心的两个高可用命题：跨可用区（Cross-AZ）容灾与ELB负载均衡。

一、 重新定义“高可用”：Region与AZ的底层真相

在动笔设计架构之前，我们必须先认清AWS的底层物理基础设施。这是所有高可用设计的地基。

• 区域（Region）： 地理上完全隔离的区域（比如东京、弗吉尼亚、爱尔兰）。区域之间距离极远，除非发生地缘政治级别的灾难，否则一个区域停电绝不影响另一个。
• 可用区（AZ）： 一个区域内包含多个可用区。请记住：一个AZ并不等于一个数据中心（Data Center）。 一个AZ可能由数个彼此靠近、但电力和网络完全独立的数据中心群组成。

💡 核心痛点：为什么单AZ架构必死？很多出海企业为了省钱，把Web服务器、数据库全部丢在同一个AZ（比如 ap-northeast-1a）。这就相当于把所有的鸡蛋放在了一个虽然号称“防弹”但依然可能漏雨的篮子里。一旦该AZ发生骨干网故障，你的业务就会瞬间失联。

因此，跨AZ（Multi-AZ）架构不是一种“高级选项”，而是生产环境的硬性底线。

二、 流量的交警：ELB（弹性负载均衡）的正确打开方式

要实现跨AZ容灾，第一步必须有一个“流量交警”，把来自全球用户的请求均匀、聪明地分发到不同可用区的服务器上。在AWS中，这个角色由 ELB（Elastic Load Balancing） 担任。

AWS提供了多种负载均衡器，但在现代Web架构中，我们主要聚焦于 ALB（Application Load Balancer） 和 NLB（Network Load Balancer）。

1. ALB vs NLB：别选错了武器

对于绝大多数出海企业，ALB 是最推荐的选择。

2. 跨可用区负载均衡（Cross-Zone Load Balancing）

这是ELB设计中最容易让人踩坑的地方。

默认情况下，ALB的跨可用区负载均衡是开启的，而NLB默认是关闭的。这有什么区别？

• 关闭状态下： 如果DNS把流量50%分配给AZ-A的负载均衡节点，50%分配给AZ-B的负载均衡节点。即便AZ-A里只有1台服务器，AZ-B里有4台服务器，AZ-A的那台服务器也会顶着50%的流量活活累死。
• 开启状态下： 无论流量先到达哪个AZ的负载均衡节点，ELB都会把请求平均分配给背后所有AZ里的所有后端实例。

结论： 除非你有极度苛刻的延迟要求（微秒级），否则强烈建议保持跨可用区负载均衡开启，确保后端压力绝对平均。

三、 跨AZ容灾的铁三角：计算、网络与存储

有了ELB这个交警还不够，后端的车道（计算）、路网（网络）和仓库（存储）必须也具备跨AZ的能力，才能在某个AZ暴毙时实现“无感切换”。

1. 计算层：Auto Scaling（自动扩展组）是唯一的正确姿势

永远不要手动去创建两台机器放两个AZ。你应该使用 AWS Auto Scaling Group (ASG)。

你只需要配置一个启动模板（Launch Template），告诉ASG：“我最少需要2台机器，最多需要10台，请帮我部署在 ap-northeast-1a 和 ap-northeast-1b 这两个AZ中。”

• 健康检查机制（Health Check）： 别让ELB只检查EC2是不是开着的（Ping）。要配置ELB去请求你代码里的一个特定接口（如 /health）。如果这个接口返回500，或者数据库连接失败，ELB会立刻判定该实例“不健康”，停止向其发送流量。
• 自愈能力： 一旦某个AZ挂了，该AZ内的机器全部失联，ASG会立刻触发报警，在另外一个健康的AZ中自动开出新机器补上缺口。

2. 网络层：子网（Subnet）与路由的黄金法则

在私有网络（VPC）的设计上，很多人会犯结构混乱的错误。一个标准的高可用网络架构应该遵循“成对出现、绝对隔离”的原则。

• 公有子网（Public Subnet）： 放置Internet Gateway、ELB以及NAT网关。每个AZ各配一个。
• 私有子网（Private Subnet）： 放置真实的EC2应用服务器。这些机器不需要公网IP，绝对不能直接暴露给互联网。每个AZ各配一个。
• 高可用NAT网关陷阱： 很多团队为了省钱，在整个VPC里只建了一个NAT网关放在AZ-A，让AZ-B的私有EC2也跨AZ绕过来上网。一旦AZ-A挂了，AZ-B的服务器虽然活着，但也因为无法上网（无法访问外部API、无法下载依赖）而废掉。正确的做法：每个AZ各自拥有独立的NAT网关。

3. 存储与数据库层：告别单点，拥抱Multi-AZ

计算节点是无状态的（Stateless），死掉可以随时重开。但数据是有状态的，数据绝不能丢。

• 关系型数据库（RDS / Aurora）：强烈开启 Multi-AZ 部署。AWS会自动在另一个AZ创建一个完全同步的备用（Standby）实例。当主库所在的AZ发生故障时，RDS会自动进行DNS漂移，在几s到几十s内把备用库提升为主库，你的应用代码甚至不需要修改连接字符串（Endpoint）。
• 文件存储（EFS vs EBS）：EBS（云硬盘）： 它是绑定在特定AZ的。这意味着AZ-A的EC2挂了，你无法直接把它的EBS挂载到AZ-B的EC2上。EFS（弹性文件系统）： 原生支持跨AZ。多个AZ的EC2可以同时读写同一个EFS。如果你的业务需要共享文件存储（比如Wordpress的图片上传目录），请毫不犹豫地选择EFS。

四、 终极实战：一个标准的多AZ高可用架构演练

为了让你有更直观的感受，我们来模拟一个标准的用户请求是如何在AWS跨AZ高可用架构中流转的。

场景：用户访问一个电商网站 [https: //example.com ]

1. 域名解析： 用户发起请求，AWS Route 53（智能DNS）解析该域名。由于配置了延迟或轮询策略，Route 53将流量指向部署在公有子网的 ALB。
2. 流量分发： ALB接收到HTTPS请求，在本地完成SSL证书解密（卸载压力），然后根据跨可用区负载均衡策略，将请求转发给位于AZ-A或AZ-B私有子网中的 EC2实例。
3. 业务处理与数据读写： EC2上的应用处理业务。如果需要读写数据库，它会连接到 RDS 主库（位于AZ-A）。此时，RDS会自动将数据同步复制到 RDS 备库（位于AZ-B）。
4. 灾难发生（模拟AZ-A彻底断网）：ELB反应： ALB发现AZ-A内的EC2实例心跳停止，或者健康检查连续失败，立刻将AZ-A从转发列表中剔除。100%的流量被瞬间导入AZ-B的EC2。RDS自愈： AWS监控到RDS主库失联，自动启动故障转移（Failover）。AZ-B的备用库在30秒内升级为新主库，Route 53自动更新RDS的内部Endpoint。AZ-B的EC2短暂报错后恢复正常读写。ASG扩容： Auto Scaling Group发现当前存活的机器数量少于设定的最小期望值，立刻在健康的AZ-B中弹出一台全新的EC2，并自动注册到ALB背后。

结果： 整个过程中，除了极少数在切换瞬间发起请求的用户可能会遇到一次重试（502/504），99%的用户完全感知不到后台经历了一场“生死时速”的机房级灾难。

五、 避坑指南：架构师常犯的三个致命错误

在实际落地这套架构时，根据大量的翻车案例，我总结了以下三个最容易被忽略的暗礁：

1. 跨AZ传输费用（Cross-AZ Data Transfer Costs）

AWS的入站流量（从互联网进来）是免费的，但在同一个Region内，流量跨越不同的AZ传输是要收费的（通常是 $0.01/GB）。
如果你的微服务拆得太碎，服务A（AZ-A）频繁通过RPC调用服务B（AZ-B），到了月底，你会收到一张极其恐怖的网络账单。
优化方案：尽量让流量在同一个AZ内完成内网闭环，只有在容灾切换时才跨AZ。

2. 数据库“脑裂”与同步延迟

虽然RDS Multi-AZ是同步复制，性能非常好，但如果你们是自己搭建的自建数据库集群（如自己硬核魔改的MySQL MHA），在跨AZ网络抖动时，极易发生两个节点都认为自己是主库的“脑裂”现象，从而导致数据写乱。
优化方案：专业的事交给专业的工具，生产环境强烈建议优先使用 RDS 或 Aurora，把底层的分布式一致性问题交给AWS去解决。

3. 忘记测试：纸面上的高可用不是高可用

很多团队架构设计得很完美，但上线三年从未做过一次容灾演练。结果真的发生故障时，发现代码里把数据库IP写死了、或者安全组（Security Group）忘记放行另一个AZ的网段。
优化方案：定期执行 Chaos Engineering（混沌工程）。在低峰期，手动去RDS控制台点一下“Failover”，或者故意关掉一个AZ的所有EC2，看看系统能否如预期般自愈。

结语

在云原生时代，容灾不应该是一件昂贵且繁琐的体力活，而应该是一种设计直觉。

通过将 ELB的智能分发、Auto Scaling的无状态自愈 以及 RDS的跨AZ同步复制 结合在一起，我们只用了几项标准的亚马逊云国际站服务，就构建出了一个足以抵御机房级灾难的钢铁架构。

记住，高可用的最高境界，不是保佑故障永远不发生；而是当故障如期而至时，你的系统只是轻轻晃动了一下，便继续在风雨中稳步前行。