📚 课程目录第2章弹性架构设计原则

2. 弹性架构设计原则

弹性架构不是“多买几台服务器”这么简单，它是一组可以落到设计决策上的原则。AWS Well-Architected 框架的可靠性支柱把这些原则归纳为四个递进的问题：基础如何规划、变更如何管理、故障如何应对、需求如何满足。理解这些原则，才能在后面选择 ALB、NLB、Auto Scaling、多 AZ 部署时做出正确判断。

一、六个核心原则的含义与工程落点

高可用指系统在部分组件失效时仍能对外提供服务，衡量的是“服务不中断的能力”，通常用可用性百分比表达。例如单 AZ 内单实例的月度可用性大致在 99.5% 量级，而跨两个 AZ 的多实例架构可显著提升，因为单点故障不再直接导致整体不可用。

容错比高可用更进一步：系统不仅不中断，还能在故障发生时自动隔离并恢复。典型手段是健康检查加自动替换——ALB 目标组发现某实例连续 3 次健康检查失败（间隔 10 秒、超时 5 秒、阈值 3），将其移出轮转，Auto Scaling 随后终止并重建该实例。

解耦是把强依赖的同步调用改为通过中间层通信。例如订单服务不再直接调用库存服务，而是把消息写入 SQS 队列，库存服务按自身节奏消费。这样库存服务短暂不可用时，订单仍可正常接收，只是处理延迟增加。

松耦合强调组件之间只依赖稳定的接口契约，而非彼此的内部实现。ALB 后面的实例可以随时被替换，只要它们监听同一端口、返回同样的响应格式，调用方无需感知。

无状态化指应用实例不保存会话或业务状态，状态外置到 ElastiCache、DynamoDB 或 S3。这样任何实例都能处理任何请求，Auto Scaling 才能自由地增减实例。若必须保留会话，可用 ALB 的粘性会话作为过渡，但它会削弱负载均衡效果，不应作为长期方案。

幂等性指同一请求执行多次与执行一次的结果一致。在无状态化和自动重试的环境下，网络超时导致的重试很常见。例如支付接口以订单号作为幂等键，重复提交时返回首次结果而不重复扣款。这是弹性架构中容易被忽视但极其关键的一环。

二、单 AZ 与多 AZ 的差异分析

单 AZ 部署把所有计算和数据库放在同一个可用区。它的优点是网络延迟低、跨 AZ 流量费用为零、架构简单。但风险集中：一次 AZ 级故障（供电、网络、制冷）就会导致整个应用不可用。按 AWS 公开的可用性模型估算，单 AZ 单实例的月度可用性约 99.5%，意味着每月可能有约 3.6 小时不可用。

多 AZ 部署把实例分散到至少两个可用区，并通过 ALB 做跨 AZ 流量分发，数据库使用 RDS 多可用区（主备同步复制，故障时自动切换，切换通常在 60～120 秒内完成）。可用性可提升到 99.99% 量级，月度停机约 4.3 分钟。代价是跨 AZ 数据传输费用和约翻倍的基础设施成本。

选择的关键不是“越贵越好”，而是看业务对停机的容忍度。内部工具可能接受单 AZ，而面向用户的交易系统必须多 AZ。一个实用的判断方法是：先确定业务可接受的 RTO（恢复时间目标）和 RPO（恢复点目标），再反推需要几个 AZ、是否需要多区域。

三、Well-Architected 可靠性支柱的四个问题

可靠性支柱围绕四个问题展开，它们构成一个从设计到运营的闭环：

基础：如何管理服务配额和网络拓扑？例如为 Auto Scaling 预留足够的 EC2 配额，避免扩容时被限制。
变更管理：如何监控工作负载并适应需求变化？例如用 CloudWatch 指标驱动扩缩容策略。
故障管理：如何设计系统以检测故障并自动恢复？例如健康检查、重试与退避、断路器。
需求管理：如何设计以支持业务增长？例如无状态化、水平扩展、松耦合。

可靠性支柱的核心不是“不出故障”，而是“假设故障一定会发生”，并让系统在故障中仍能维持可接受的服务水平。这与容错、解耦、无状态化、幂等性四个原则直接对应。

四、把原则落到配置上的一个示例

假设一个订单服务部署在 ALB 后面，目标组配置如下：健康检查路径 /health，间隔 10 秒，超时 5 秒，健康阈值 2 次，不健康阈值 3 次。Auto Scaling 组最小 2 台、最大 6 台，跨两个 AZ 均匀分布，扩容策略为 CPU 平均利用率超过 60% 时增加 1 台。

目标组健康检查：
  路径: /health
  间隔: 10s    超时: 5s
  健康阈值: 2   不健康阈值: 3

Auto Scaling 组：
  最小容量: 2   最大容量: 6
  可用区: us-east-1a, us-east-1b
  扩容策略: CPUUtilization > 60% → +1 实例
  缩容策略: CPUUtilization < 30% → -1 实例

当 AZ A 的实例全部健康检查失败时，ALB 会在约 30 秒内（3 次 × 10 秒）将其移出轮转，流量全部转到 AZ B。同时 Auto Scaling 检测到 AZ A 容量不足，在 AZ A 重建实例。整个过程无需人工干预，这就是容错与高可用的实际体现。

需要注意的是，如果应用把会话保存在实例本地内存中，流量切换后用户会丢失登录状态。因此无状态化不是可选项，而是多 AZ 架构能真正生效的前提。同理，如果订单创建接口不幂等，ALB 重试或客户端重试可能导致重复下单。这四个原则彼此关联，缺一不可。

五、可靠性设计的检查清单

检查项	单 AZ 场景	多 AZ 场景
计算层分布	单 AZ 内多实例	至少 2 个 AZ 均匀分布
数据库	单实例或只读副本	RDS 多可用区，自动故障转移
会话状态	可存本地	必须外置到 ElastiCache/DynamoDB
健康检查	可选	必须，且阈值要合理
幂等性	影响较小	必须，防止重试导致重复操作
成本	低	约 2 倍，含跨 AZ 流量费

多 AZ 不等于多区域。多 AZ 应对的是单个可用区故障，多区域应对的是整个区域故障。两者成本、复杂度差异很大，不要混淆。大多数业务先从多 AZ 起步即可。

掌握这些原则后，后续选择负载均衡器类型、设计 Auto Scaling 策略、配置 RDS 高可用时，就能清楚地知道每个配置项在解决什么问题，而不是照搬模板。