1. 高可用Web业务系统概述

在开始动手部署之前，我们需要先建立一套共同的语言：什么叫“高可用”？它和“永不宕机”是不是一回事？当故障真的发生时，系统应该多快恢复、允许丢多少数据？AWS 又是靠什么在全球范围内支撑这种能力？本章把这些概念讲清楚，并引出贯穿全课程的实战项目。

1.1 高可用的定义：不是不坏，而是坏得起

高可用（High Availability，HA）指的是系统在约定的时间内持续对外提供服务的能力。它的核心前提是承认故障必然发生——服务器会宕机、可用区会断电、网络会抖动、程序会有 Bug。高可用的目标不是消灭故障，而是让单个组件的故障不转化为整体业务的中断。

衡量高可用最常用的指标是可用性百分比，它由“正常运行时间 / 总时间”计算得出。业界习惯用“几个 9”来描述：

需要特别注意的是，可用性是“串联”计算的。如果一次请求要依次经过负载均衡、Web 服务器、数据库三个环节，每个环节都是 99.9%，那么整体可用性约为 0.999³ ≈ 99.7%，年停机时间从 8.76 小时放大到约 26 小时。这解释了为什么高可用设计必须消除单点、减少关键路径上的串联环节，并尽量把组件做成并联冗余。

1.2 SLA、RTO 与 RPO：把承诺变成可度量的数字

SLA（Service Level Agreement，服务等级协议）是服务提供方对可用性和性能的正式承诺。AWS 对 EC2、S3、RDS 等服务都发布了各自的 SLA，例如 Amazon EC2 的区域级服务承诺为 99.99%，若未达标会按比例返还服务抵扣金。作为架构设计者，我们既要理解云厂商给我们的 SLA，也要定义自己对业务方承诺的 SLA，两者之间必须留出余量。

当故障发生时，真正决定业务损失的是两个恢复指标：

• RTO（Recovery Time Objective，恢复时间目标）：从故障发生到业务恢复可用的最长可接受时间。它回答“能停多久”。
• RPO（Recovery Point Objective，恢复点目标）：故障发生时最多可接受丢失多长时间的数据。它回答“能丢多少”。

举例来说，一个电商下单系统若设定 RTO = 15 分钟、RPO = 5 分钟，就意味着：故障后 15 分钟内必须恢复服务，且最多只能丢失最近 5 分钟内的订单数据。这两个数字直接决定了技术选型——RPO 接近 0 通常需要同步复制或持续日志传送，RTO 越短则越依赖自动化故障转移而非人工介入。

1.3 AWS 全球基础设施：高可用的物理底座

AWS 的高可用能力建立在分层的基础设施之上，理解这套层级是后续所有设计的基础：

• 区域（Region）：地理上独立的数据中心集群，例如 ap-northeast-1（东京）、us-east-1（弗吉尼亚北部）。区域之间完全隔离，是容灾的最高层级。
• 可用区（Availability Zone，AZ）：一个区域内由独立供电、制冷和网络支撑的一个或多个数据中心。同一区域内 AZ 之间通过低延迟专线互联，延迟通常在个位数毫秒。AZ 是日常高可用设计的基本单元。
• 边缘站点（Edge Location）：用于 CloudFront 内容分发和 Route 53 就近解析，全球数百个，缩短终端用户访问延迟。

由此形成两种典型的高可用形态：多 AZ 部署用于应对单机房故障，成本低、延迟小，是绝大多数业务的第一道防线；多区域部署用于应对整个区域级灾难，成本和复杂度显著上升，通常只用于核心业务。本课程的项目将以多 AZ 为主线，并在后期引入跨区域容灾。

1.4 课程实战项目：一个可演进的高可用电商 Web 系统

为了让抽象概念落地，本课程将围绕一个统一的实战项目逐步演进：一个面向公众的电商 Web 业务系统，包含商品浏览、用户登录、下单和订单查询四类核心功能。项目不会一次性建成，而是随着章节推进不断加固，每一章都在上一章的基础上解决一个具体的高可用问题。

项目的初始形态是单台 EC2 承载 Web 与数据库，这显然不满足高可用。后续演进路径大致如下：

1. 用 ALB + 多 AZ 的 EC2 Auto Scaling 组消除单实例和单 AZ 故障，把可用性从 99% 提升到 99.9% 量级；
2. 把数据库迁移到 RDS 多 AZ，获得自动故障转移能力，将 RTO 从小时级压缩到分钟级；
3. 引入 ElastiCache 缓存热点商品数据，降低数据库压力并缩短响应时间；
4. 用 S3 + CloudFront 托管静态资源，把图片和前端资源从应用服务器卸载；
5. 通过 Route 53 健康检查与故障转移路由，实现跨区域的容灾切换；
6. 最后用 CloudWatch 告警、指标和演练验证整套架构是否真的达到设定的 RTO/RPO。