设计全局事件处理机制：跨微服务事件标准搭建咨询

我们正着手制定系统间共享事件的标准。业务数据频繁变更，需让各独立系统实现通信与事件驱动任务，因此认为全局事件系统是成功关键。
产品每日约有1-2百万次数据更新，前端可通过状态管理追踪变更，但后端因微服务众多，实现难度更大。
典型场景如用户支付订单：订单处理微服务完成操作后，分析服务需捕获该事件以统计付费订单及日收益。

我初步设想的标准化方案：
在全局事件总线中为每个领域对象（如Orders/Customers/Payments）设置主题，事件对象包含以下字段：

• Object Id
• Version（用于追踪协议变更等）
• 对象本身（考虑通过GraphQL而非完整对象传递，但存在隐患）

随后将事件信息推送至Amazon SNS，各子系统按需处理通知。

现咨询该方案的实施思路，及相关实践经验（含不同实现方案），以规避潜在问题。

一、你的SNS方案落地步骤 #

1. 主题规划与标准化 #

• 按领域对象划分主题的思路没问题，但建议给主题加上环境标识（如prod-orders-events、staging-payments-events），避免跨环境事件串流污染。
• 强制制定事件Schema：用JSON Schema定义每个事件的结构，除了你提到的Object Id、Version，必须加上事件类型（如OrderPaid、CustomerUpdated）、触发时间、触发服务标识。Version字段建议用语义化版本（如1.0.0），方便后续兼容迭代。

2. 事件生产规范 #

• 事件必须在业务操作最终一致性确认后发送：比如订单支付完成，要等数据库事务提交成功再推SNS事件，避免事务回滚导致的虚假事件。
• 关于"对象本身"的传递：
  • 不建议直接传完整对象，冗余数据会增加传输成本和存储压力；
  • 用GraphQL片段传递必要字段可行，但要提前约定每个事件的最小字段集，同时在Schema中明确这些字段，防止消费方依赖未定义字段；
  • 更稳妥的方式是只传Object Id+核心元数据，消费方通过内部API（如GraphQL网关）拉取最新数据，能避免事件数据与源数据不一致的问题。

3. 事件消费规范 #

• 各子系统通过SQS订阅SNS主题（别直接订阅SNS，因为SNS不保证消息重试和持久化），每个消费服务对应独立的SQS队列，实现按需消费。
• 必须实现幂等处理：SNS/SQS可能重复投递事件，消费方要通过Object Id+Version或事件唯一ID判断是否已处理过该事件。
• 错误处理：配置死信队列（DLQ），把处理失败的事件转入DLQ，定期排查失败原因，避免阻塞正常消费流程。

二、替代实现方案对比 #

1. Kafka 替代 SNS #

如果后续数据量持续增长（当前1-2百万日更新Kafka也能轻松应对），Kafka是更优选择：

• 支持消息持久化，可回溯历史事件，适合数据分析服务初始化这类需要重放事件的场景；
• 自带分区机制，能更好支撑高并发消息生产和消费；
• 缺点是运维复杂度比SNS高，需要管理集群。

2. EventBridge 替代 SNS #

AWS EventBridge是SNS的进阶版，更适配微服务架构：

• 支持事件规则过滤，消费方可以只订阅符合特定条件的事件（比如只订阅金额大于1000的订单支付事件）；
• 内置与AWS其他服务的集成，可直接触发Lambda、Step Functions；
• 自带事件归档功能，方便审计和回溯。

三、潜在问题规避策略 #

1. 版本兼容性问题 #

• 事件Version升级时，生产方要同时兼容旧版本一段时间，消费方逐步迭代到新版本；
• 禁止删除事件中已有字段，只能新增字段，避免消费方出现解析错误。

2. 事件丢失与一致性问题 #

• 生产端实现事件发送重试机制，配合数据库的事件记录表（记录已发送的事件ID），定期扫描未成功发送的事件进行重试；
• 消费端实现至少一次投递的处理逻辑，通过幂等性保证重复处理不会产生副作用。

3. 性能瓶颈 #

• 百万级日更新SNS/SQS完全能支撑，但可以批量发送事件（比如把10个订单更新事件批量推送到SNS），减少API调用次数；
• 消费端根据自身处理能力调整SQS的批量接收参数，避免服务过载。

4. 安全与权限 #

• 给每个服务分配最小权限：生产服务只能向指定主题发送事件，消费服务只能访问自己的订阅队列；
• 启用SNS/SQS的加密功能，传输和存储都用AWS KMS加密，防止敏感数据泄露。

内容的提问来源于stack exchange，提问作者Alex Connolly