3层架构如何在 AWS 上实现高可用性

Source: Dev.to

什么是高可用性

高可用性指的是系统在单个组件出现故障时仍能保持运行的能力。它不是依赖单台服务器或单一路径，而是将工作负载分布在多个故障域中，使得故障不会立即导致停机。

在 AWS 中，实现高可用性的核心构件是 可用区 (Availability Zone, AZ)。每个 AZ 在物理上相互独立，拥有独立的电力、冷却和网络。跨多个 AZ 部署可以显著降低硬件或数据中心故障的影响。

高可用性并不是要彻底防止故障，而是要设计出在故障不可避免时仍能继续提供服务的系统。

3‑层架构概念

3‑层架构将应用程序划分为三个逻辑层：

1. 表示层 (Presentation tier) – 处理来自用户的请求。
2. 应用层 (Application tier) – 处理业务逻辑。
3. 数据库层 (Database tier) – 存储持久化数据。

在 AWS 上，这些层通常映射到 VPC 内的不同子网和服务。层间的分离使得流量和访问控制更加严格，便于随时间进行扩展、安全和运维。

表示层（Web 层）

表示层负责处理进入的 HTTP/HTTPS 请求。

• 组件：位于公共子网的应用负载均衡器 (ALB)，以及运行在 EC2 实例或容器上的多个 Web 服务器。
• 部署：跨多个 AZ，以避免单点故障域。
• 健康检查：ALB 持续检查目标实例的健康状态，仅将流量路由到健康实例。如果某个实例或整个 AZ 不可用，流量会自动重新路由。
• 暴露方式：放置在公共子网，通常开放 80 和 443 端口。

应用层（逻辑层）

应用层处理业务逻辑，并在 Web 层和数据库层之间进行通信协调。

• 放置位置：私有子网，未直接接入互联网。
• 访问方式：仅接受来自 Web 层的请求，通常通过内部负载均衡器。
• 高可用性：多个应用实例跨不同 AZ 运行；Auto Scaling 会自动替换不健康的实例。
• 收益：降低整体攻击面，并在故障或流量激增时保持响应能力。

数据库层（数据层）

数据库层存储持久化的应用数据，需要最高级别的稳定性和保护。

• 实现方式：启用 Multi‑AZ 的 Amazon RDS。
• 放置位置：私有、隔离的子网；仅允许来自应用层的入站访问。
• 故障转移：AWS 在另一个 AZ 维护一个备用副本；主实例故障时，备用会自动提升为主实例，最大限度地减少停机时间。
• 安全性：无出站互联网访问；通过安全组和路由规则进行严格限制。

可用区如何协同工作

在高可用的 3‑层架构中，每一层都跨多个 AZ，但流量遵循严格且可预测的顺序：

1. 用户通过 Web 层的公共负载均衡器访问系统。
2. 请求被转发到应用层，进行业务逻辑处理。
3. 应用层根据需要与数据库层通信。

如果整个 AZ 失效，负载均衡器会停止向该区域路由流量。健康的 AZ 中的应用实例继续提供服务，数据库层则在必要时切换到备用副本。此层级设计提供了弹性。

网络与流量路径

• 公共子网 托管面向互联网的组件（负载均衡器、Web 服务器）。
• 私有子网 托管内部工作负载（应用服务器、数据库）。
• 路由表 控制每一层的互联网访问。
• 安全组 定义层之间允许的通信。

流量按层向下受控流动，简化故障排查并降低意外暴露的风险。

扩展与容错

将高可用性与自动扩展相结合，可进一步提升系统弹性：

• 负载均衡器 均匀分配流量。
• 健康检查 及早发现故障。
• Auto Scaling 根据需求和实例健康状态自动调节容量。

系统会自动替换不健康的资源，而不是手动修复故障服务器，从而降低停机时间和运维成本。

常见使用场景

高可用的 3‑层架构常用于：

• 面向公众的 Web 应用
• 具备复杂业务逻辑的后端 API
• 对正常运行时间要求严格的电商平台

这些工作负载通过层级隔离和多 AZ 部署，在故障期间仍能保持可用性。

设计建议

• 将每一层放在独立的子网中。
• 至少跨两个可用区部署。
• 使用负载均衡器而非直接实例访问。
• 使用安全组限制流量，而不是宽泛的 IP 范围。

结论

在 AWS 上的高可用 3‑层架构结合了逻辑分离、多 AZ 部署以及受控的流量路径。每一层都有明确的职责，AWS 服务协同工作以隔离故障并保持正常运行时间。拥有此结构后，即使单个组件或可用区失效，应用仍能继续为用户提供服务。