摘要
1) 一句话总结
Amazon Key 团队通过引入基于 Amazon EventBridge 的集中式事件驱动架构（“单总线、多账户”模式），解决了原有紧密耦合架构的扩展性瓶颈，大幅提升了事件处理性能、Schema 治理能力与服务接入效率。
2) 核心要点
- 原有架构痛点：早期架构紧密耦合，组件故障易引发连锁反应；事件路由需手动实现，Schema 定义松散且扩展困难，缺乏标准化的消费者接入机制。
- 核心架构演进：采用“单总线、多账户（single bus, multi-account）”模式，在核心账户部署集中式 EventBridge 事件总线接收领域事件。
- 路由与隔离机制：通过路由规则将事件匹配并转发至各订阅账户，各账户独立维护目标服务与处理逻辑，在实现服务隔离的同时保留了集中治理能力（路由、权限、合规）。
- 集中式 Schema 治理：引入集中式 Schema 仓库作为事件契约的权威来源，支持版本控制与结构化校验。
- 客户端库校验：通过定制客户端库，在事件发布端（序列化与校验）和订阅端（反序列化与校验）统一执行 Schema 规则，减少 Payload 不兼容导致的集成错误。
- 基础设施自动化：利用 AWS CDK 构建可复用组件，自动化配置订阅账户的事件总线、路由规则、跨账户 IAM 权限及监控告警，确保安全与可观测性的一致性。
- 性能指标提升：重构后平台每秒可处理约 2,000 个事件，成功率达 99.99%，端到端 p90 延迟约为 80 毫秒。
- 研发效率提升：事件接入时间从 48 小时大幅缩短至 4 小时，服务集成时间从约 40 小时缩短至约 8 小时。
正文
Amazon Key 团队对其事件平台进行了现代化改造，以解决由高度耦合的单体架构所带来的可扩展性与可靠性瓶颈。随着服务之间的交互逐渐演变为复杂的依赖网络，系统稳定性与集成效率不断受到限制。此次重构引入了基于 Amazon EventBridge 的 集中式事件驱动架构 ，用以支持每日数百万级事件处理、实现毫秒级延迟，同时改进 Schema 治理能力，并为新增服务消费者提供可持续的接入路径。
Amazon Key 套件为车库内安全投递和物业访问管理提供支持。其早期架构依赖紧密耦合的服务体系，一个组件的变更或故障往往会直接影响其他组件。事件路由逻辑需要手动实现，缺乏高级过滤和并行发布能力。事件 Schema 定义较为松散，仅支持对必填字段进行基础校验。若需扩展校验规则或演进数据契约，往往需要额外的跨团队协作与定制开发。同时，该平台能够支持的订阅方数量有限，在新业务场景不断出现时，也缺乏标准化的消费者接入扩展机制。
为解决这些限制，工程团队采用了“ 单总线、多账户 （single bus, multi-account）”架构模式。在这一模式下，核心账户中部署集中式 EventBridge 事件总线，用于接收来自事件生产者的领域事件。路由规则会根据事件模式进行匹配，并将符合条件的事件转发至各订阅账户，而每个账户则独立维护自身的目标服务与处理逻辑。这种结构在实现服务隔离的同时，也保留了对路由策略、权限管理以及合规控制的集中治理能力。各团队能够独立部署服务，同时共享统一的事件基础设施。
架构总览
团队还引入了集中式 Schema 仓库，用于统一事件定义并实施版本控制。Schema 成为事件契约的权威来源，并支持结构化校验。在事件发布至 EventBridge 之前，定制客户端库会依据已批准的 Schema 对事件进行校验与序列化；在订阅方侧，同一套库则负责事件的反序列化与校验，然后再触发下游服务调用。这一机制确保生产者与消费者之间的数据契约保持一致，并减少因 Payload 不兼容导致的集成错误。
在基础设施层面，订阅账户的资源配置通过 AWS Cloud Development Kit 构建的可复用组件实现自动化。这些组件负责配置事件总线、定义路由规则、建立跨账户访问所需的 IAM 权限 ，同时启用监控与告警能力。标准化流程减少了重复的基础设施配置工作，并确保各服务在可观测性与安全实践方面保持一致。
Schema 校验与发布流程
架构重设计带来了可量化的成果。目前平台每秒可处理约 2,000 个事件，成功率达到 99.99%。团队测得从事件接收到目标服务触发的 p90 延迟约为 80 毫秒。运营效率也显著提升：事件接入时间从原先的 48 小时缩短至 4 小时，而过去大约需要 40 小时完成的服务集成，如今约 8 小时即可完成。系统现已能够在保持低延迟与稳定可靠性的前提下，支持每日数百万级事件处理规模。
原文链接：
https://www.infoq.com/news/2026/02/amazon-key-event-driven-platform/