从 AWS 故障反思：广告系统的全球单元化部署

昨天下午（2025/10/20 15:00 UTC+8），AWS 在 us-east-1 区域 出现了大规模的服务异常。

起因是 DynamoDB 的 SLA 故障，进一步影响到了该区域的 API 响应、控制平面和一系列依赖服务。短短几十分钟内，不少依赖 us-east-1 的核心系统出现雪崩------广告投放延迟、任务队列堆积、素材分发超时，甚至一些看似"多活"的系统也一起瘫痪。

对于许多依赖云上托管的业务来说，这次事件无异于一次突如其来的"区域性停电"。哪怕系统已经跨多个可用区（AZ）部署，只要依赖的是某个区域级别的服务（例如 DynamoDB、STS、Route 53 等），依然可能在区域层面的异常中被"一锅端"。

这次故障再次提醒我们一个老生常谈的事实：云不是免疫区。 在公有云上构建高可用架构，并不意味着"部署在 AWS 就天然可靠"。当一个 region 出现系统性异常时，依赖它的所有组件都会连锁反应。

而对广告系统而言，这种依赖尤其致命。因为广告系统的核心闭环------投放 → 播放 → 数据上报 → 结算------天然要求实时、连续和准确，一旦链路中断，就意味着直接的收入损失与数据对账风险。

一、从故障看出的问题

我们的广告系统运行在 AWS 的多区域部署之上。为了服务全球广告主与流量方，我们在美国、东南亚等多个地区都建立了区域集群。

然而，us-east-1 是我们的事实性中心：无论是广告主配置写入，还是东南亚脱敏数据的入境落地，都绕回到美东。

1. 我们的投放（广告主平台）依赖单 region 的中心化存储（us-east-1），为保障投放数据的一致性和写延迟，我们把投放数据库集中写在美东；
2. 我们的在线流量链路在全球多 region 部署，但是由于数据合规要求（如 GDPR、CCPA 等），每个合规区的数据处理与存储都必须严格隔离；
3. 由于我们需要服务全球广告主与流量源，因此东南亚等区域的广告数据在本地先做脱敏/去标识化处理后，再同步到 us-east-1 做统一落地与后续处理。

出于成本考虑，我们在每个合规区内只选择了单个 region 进行多可用区（AZ）部署。

很多团队会说："我们已经多可用区部署了，为什么还会一起挂？" 问题在于，多可用区（AZ）≠ 多区域（Region）隔离，更不等于业务单元隔离。

以 DynamoDB 为例，它的多 AZ 设计确实能抵抗单 AZ 故障，但当控制平面、API 或 DNS 出问题时，整个 region 都会不可用。而如果你的投放引擎、实时计数、配置中心、日志写入都绑定在 us-east-1 的 DynamoDB 上，那么无论你有多少个副本，都会同时失效。

当 us-east-1 出问题时，后果是直接且全面的：投放无法写、策略无法生效、跨区（脱敏）数据无法正常落地；播放端（流量方的拉取）因策略/素材不可用而返回空或超时；计费与仓库链路因数据缺失或延迟而停摆。换句话说，这一单 region 的失效，使得整个合规区（美国）成为完全不可用状态------而我们也没有合规上能替代的可切流 region。

二、为什么需要单元化

从 us-east-1 的故障来看，我们发现一个核心问题：多 AZ、多合规区并不等于业务的高可用。

即便流量节点和数据节点在物理上分布在不同的地方，如果控制面、投放数据或关键同步依赖单一区域，一旦该区域失效，整个合规区可能同时瘫痪。

这次事故让我们第一次直观地感受到：单点依赖的爆炸半径可能远比我们想象的更大。

2.1 什么是单元化

单元化（Unitization / Unit-based Architecture）是一种架构设计理念：

将系统拆解为相对自治的业务单元，每个单元可以独立部署、独立运行、独立恢复，单元之间的耦合尽可能降低。

在广告系统的语境下，每个单元可能包括：

• 投放单元：广告主平台、策略配置写入、预算管理；
• 播放单元：流量场广告请求拉取、素材匹配和展示逻辑；
• 数据单元：曝光/点击/转化事件的本地收集、聚合、计费及数据仓库入库。

单元化并不意味着完全分散，而是明确边界、降低依赖，让每个单元在外部故障或其他单元不可用时，仍能维持核心功能或可控降级。

2.2 为什么其他大型公司也在做单元化

在当今互联网业内，很多大型系统已经在实践单元化，包括淘宝、支付宝、抖音等，并从中获得明显收益。原因主要有三点：

1. 成本控制与资源优化

   • 单元化允许不同业务单元独立扩容或缩容，避免了全系统一刀切的资源浪费。
   • 对广告系统来说，不同投放策略或流量场可以按需独立部署，降低集群资源压力。
   • 对于淘宝、支付宝、抖音这样体量的公司，单计算中心或单Region的算力已经无法支撑业务增长。

2. 降低风险，控制爆炸半径

   • "鸡蛋不能放在一个篮子里"：单元化可以防止单点故障波及整个系统。
   • 当一个单元不可用时，其他单元可以继续运行或按降级方案服务，减少整体业务中断。

3. 提升效率与用户体验

   • 单元化让播放单元和流量端节点部署更靠近用户或流量源，广告请求的响应延迟更低，用户端体验更流畅。
   • 对广告系统而言，播放端即使投放端短暂不可用，也能利用缓存或保底策略继续展示广告，用户体验不受完全中断影响。

通过这次 us-east-1 的事故，我们看到如果不进行单元化，即便做了多 region 部署，也可能在核心链路出现整个合规区不可用的情况 。 单元化不仅是应对区域级故障 的手段，也是优化资源、提升业务韧性和用户体验的必然选择。

三、广告系统的单元化实践

在理解了单元化的概念和价值之后，我们需要思考：如何将广告系统实际拆解成可以自治、可独立运行的单元。结合广告系统的链路，我们将服务划分为三类：本地服务、单元服务、中心服务。

3.1. 本地服务（Local Service）

本地服务是最贴近用户的单元，它完全无状态，能够在本地完成全部计算和处理逻辑，无需依赖中心存储。

特点：

• 无状态：处理逻辑完全基于本地输入数据，不依赖远程数据库或中心策略；
• 靠近用户：部署在流量侧节点或合规区内边缘数据中心；
• 高可用与低延迟：即使中心或其他单元失效，本地服务仍能独立完成广告请求处理和实时计算；
• 典型应用：播放端广告拉取、素材匹配、简单策略计算。

本地服务的核心优势是隔离爆炸半径：它不会因为中心服务或其他单元故障而直接影响用户端体验。

3.2. 单元服务（Unit Service）

单元服务介于本地服务和中心服务之间，它拥有一定的数据存储能力，但数据是分片的，可以部署在多个单元中，通过路由将流量调度到不同实例。

特点：

• 数据分片与可路由：同一类数据可以分片存储在单元 A 或单元 B，系统通过路由或负载均衡将请求引导到对应单元；
• 自治能力：单元内的服务可以独立处理数据，只依赖本单元的存储和计算；
• 灵活扩展：当某个单元过载或不可用时，流量可以动态切换到其他单元的实例；
• 典型应用：区域内的广告投放策略服务、临时事件聚合、边缘缓存与预处理。

单元服务的核心价值是在保证业务连续性的前提下，实现跨单元的容错和扩展能力。

3.3. 中心服务（Central Service）

中心服务是传统的集中式存储和处理服务，数据完全部署在某个单元或 region 内。

特点：

• 集中存储：核心投放数据、全局策略、计费与结算数据等集中管理；
• 单点风险：中心服务一旦失效，会影响依赖它的多个单元和服务；
• 尽量避免：在单元化架构设计中，中心服务应尽可能减少依赖范围或被替代；
• 典型应用：投放数据库、全局汇总仓库、核心控制面。

在单元化策略中，中心服务越少越好，只有在业务确实需要统一存储、全局一致性或合规约束时才使用，并尽量隔离对本地服务和单元服务的影响。

四、三条链路的单元化实践

在前一节中，我们把服务划分为本地服务、单元服务、中心服务。现在，把广告系统的三条核心链路套用进这个模型，可以更直观地理解单元化的落地。

4.1 投放链路（广告主平台）

投放端原本设计为集中式系统，存在单 region 单点依赖 的问题。为了提升可用性并规避区域级故障，我们将投放端建模为单元服务：

• 单元服务：每个合规区部署投放单元，缓存策略快照、处理广告主请求、生成本地正排索引。

  • 写操作通过广告主或策略主键路由到特定单元，保证单点可控；
  • 单元之间通过发布-订阅或事件流异步同步更新，实现跨单元可读。

• 本地服务：无状态请求处理节点快速响应前端操作，将写请求异步提交到本单元，降低请求延迟。

特点：

• 高可用性：单元服务独立处理请求，即便某个 region 暂时不可用，其他单元仍能继续服务；
• 降低依赖：没有中心服务参与写操作，避免单 region 故障导致投放全局不可用；
• 异步同步：通过异步机制与其他单元保持数据一致性，同时支持正排索引生成并流转到播放链路。

4.2. 播放链路（流量场广告拉取）

• 本地服务：播放端部署在流量侧，完全无状态。它使用本地缓存的正排/倒排索引完成广告匹配与素材选择。
• 单元服务：区域索引单元维护倒排索引，负责广告策略与素材在本地的快速查询和更新。

通过发布-订阅机制：

1. 投放链路的单元服务生成的正排索引，通过消息总线异步推送到播放链路的单元服务；
2. 播放单元根据策略和地域信息构建倒排索引，保证快速匹配流量请求；
3. 这一异步流转方式实现正排/倒排索引的松耦合异构架构，即便投放服务短暂不可用，播放端仍可使用已同步的索引继续服务。

4.3. 数据链路（计费与数据仓库）

• 本地服务：事件收集节点在流量侧完成曝光/点击/转化事件的本地缓冲和聚合。
• 单元服务：区域数据单元负责本地存储、去标识化、初步计算与汇总。
• 中心服务：全局仓库和计费系统集中处理核心账务、报表和模型训练，数据从各单元异步汇聚而来。

特点：

• 数据链路使用发布-订阅 + 异步汇聚模式，将事件从本地服务推送到单元服务，再汇总到中心服务；
• 在中心服务不可用时，本地和单元服务仍能保证事件收集、临时聚合和本地计算，避免数据完全中断；
• 异步处理允许跨单元的去标识化和合规控制，使数据在不同合规区之间安全流转。

五、总结与思考

通过这次 us-east-1 的事故，我们对广告系统的全球单元化部署有了更深的理解：

1. 单点依赖的隐患 即便多 AZ、多 region 部署，如果核心链路或关键存储集中在某个 region，仍然可能造成整个合规区不可用。我们深刻感受到：单点的爆炸半径往往超出预期。

2. 单元化的价值 单元化不仅是技术架构的演进，更是业务韧性和用户体验的保障：

   • 隔离故障范围：每个单元自治，本地服务和单元服务能够独立处理请求，即使某些区域或中心不可用，其他单元仍能运行；
   • 降低依赖：通过将投放建模为单元服务、播放和数据链路异步同步，实现单处写、全局读的模式，避免中心服务成为瓶颈；
   • 靠近用户：本地服务部署靠近流量端或合规区，缩短请求路径，提高广告响应速度，优化用户体验；
   • 灵活扩展：新增业务单元或拓展区域时，可以按需部署，保持业务连续性。

3. 演进方向 对于未来的广告系统：

   • 投放端可以进一步优化路由策略，实现写入分散、可快速切换单元；
   • 中心服务的依赖应尽量降低，仅保留必要的全局一致性或合规存储；
   • 数据链路可以继续强化异步汇聚、跨单元去标识化和合规控制，让事件处理和计费在各单元内可降级执行。

这次 AWS us-east-1 的事件，是一次痛苦但必要的教训。它提醒我们：任何集中化的依赖都是潜在风险。而单元化架构提供了应对区域级故障的可行路径，使广告系统在复杂的全球部署中保持韧性、持续性和可控性。

对于广告业务来说，单元化不仅仅是架构优化，更是一种业务风险管理、性能保障和用户体验提升的实践。它让系统从"云的假象可靠"走向"可控、高可用、可演进"的真实状态。