麦当劳的事件驱动架构

bxb100 commented 1 year ago

译 https://blog.quastor.org/p/mcdonalds-uses-event-driven-architectures

过去几年, 麦当劳一直大力投资构建和推广他们的 APP; 顾客可以通过它来下单, 获取优惠券, 查看营养信息等.

因此, 麦当劳 2021 年有超过 2400 万次下载量, 成为美国下载量最多的餐厅类 app. 星巴克紧随其后, 去年下载量为 1200 万次.

麦当劳依赖事件驱动架构 (EDAs) 来支持他们后端的众多服务. 比如说, 发送营销信息 (交易或促销) 或者提供手机订单的处理进度.

麦当劳过去遇到的一个问题是缺乏创建 EDA 的标准方法(最佳实践). 他们看到了不同团队使用的各种技术和模式, 导致不一致和不必要的复杂性.

为了解决这个问题, 工程师创建了统一事件平台 (unified eventing platform), 公司内的不同组织能够在此之上构建自己的事件系统. 这降低了启动和维护这些服务的实施和操作复杂性, 同时还确保了一致性.

Vamshi Krishna Komuravalli 是麦当劳的首席架构师, 他写了一篇关于麦当劳统一事件平台架构的精彩博文

总结

麦当劳想要构建统一的事件平台来管理公司内不同生产者和消费者之间的通信.

他们希望这个平台是可升缩的, 高可用, 性能好, 安全和可靠的. 他们还希望在如何完成错误处理、监控和恢复等事情上保持一致.

这是他们为了处理这些构建的统一事件平台的架构图:

Event Broker: 它是平台的核心, 负责管理生产者和消费者之间的通信. 麦当劳使用 AWS, 因此他们使用 AWS Managed Streaming for Kafka (MSK) 作为事件代理.
Schema Registry: 工程师希望为事件实施统一的架构, 以确保下游消费者的数据质量. Schema Registry 包含所有事件模式, 生产者和消费者将在发布/消费时检查注册表以验证事件.
Standby Event Store: 如果 kafka 无法使用, 生产者将会发送他们的事件到备用事件存储库中(DynamoDB). 一个 AWS 的 Lambda function 将会从中尝试重新发送或发布到 kafka.
Custom SDKs: 想要使用 Eventing Platform 的工程师可以使用 SDK. 事件平台团队为生产者和消费者构建了特定语言的库来编写和读取事件. 执行模式验证、重试和错误处理是通过 SDK 抽象出来的.

在事件平台中事件活动的工作流程

工程师定义事件的模式并将其注册到模式注册表中
需要生产事件的应用使用生产者SDK发布事件
SDK 执行架构验证以确保事件遵循架构
如果验证通过, SDK 会将事件发布到主要 topic 中
如果 SDK 在发布到主要 topic 时遇到错误, 则会将事件路由到该生产者的 dead-letter topic. 一个管理程序允许工程师修复这些事件的任何错误(如何修复?).
如果 SDK 遇到 Kafka 错误, 则事件将写入 DynamoDB 数据库中. Lambda 函数稍后将重试将这些事件发送到 Kafka.
消费者消费来自 Kafka 的事件

为了确保数据完整性, 麦当劳依靠模式注册表对事件平台发布和消费的所有事件强制执行数据契约.

当生产者发布消息, 消息在开头包含版本的字符信息.

之后, 当消息被消费时, 消费者可以通过字符来决定什么版本的模式应当被遵循.

事件根据其域被分片到不同的 MSK 集群中. 这使得自动缩放更容易, 因为你可以为负载较重的域缩增加集群.

为了应对读/写负载的增加, 事件平台团队添加了逻辑来监视 MSK 的 CPU 指标, 并触发自动缩放功能以在负载过高时向集群添加额外的 broker 机器. 为了增加磁盘空间，MSK 具有自动缩放存储的内置功能.

查看更多信息, 你可以阅读完整的文章: 这里和这里

bxb100 commented 1 year ago

confluent 的 schema register + ksqlDB (可以用 lambda or FAAS 来控制) + Kafka + cloud 完全满足这一套...

bxb100 commented 1 year ago

记录一下, Python 项目好像现在也是 event 这一套, 可以看 NAStool