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

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

麦当劳事件驱动架构图

四大模块如下：

1 - Event Broker: 它是平台的核心, 负责管理生产者和消费者之间的通信. 麦当劳使用 AWS, 因此他们使用 AWS Managed Streaming for Kafka (MSK) 作为事件代理。

2 - Schema Registry: 工程师希望为事件实施统一的架构, 以确保下游消费者的数据质量. Schema Registry 包含所有事件模式, 生产者和消费者将在发布/消费时检查注册表以验证事件。

3 - Standby Event Store: 如果 kafka 无法使用, 生产者将会发送他们的事件到备用事件存储库中(DynamoDB). 一个 AWS 的 Lambda function 将会从中尝试重新发送或发布到 kafka。

4 - Custom SDKs: 想要使用 Eventing Platform 的工程师可以使用 SDK. 事件平台团队为生产者和消费者构建了特定语言的库来编写和读取事件. 执行模式验证、重试和错误处理是通过 SDK 抽象出来的。

工作流程如下：

1、工程师定义事件的模式并将其注册到模式注册表中。

2、需要生产事件的应用使用生产者SDK发布事件。

3、SDK 执行架构验证以确保事件遵循架构。

4、如果验证通过, SDK 会将事件发布到主要 topic 中。

5、如果 SDK 在发布到主要 topic 时遇到错误, 则会将事件路由到该生产者的 dead-letter topic. 一个管理程序允许工程师修复这些事件的任何错误。

6、如果 SDK 遇到 Kafka 错误, 则事件将写入 DynamoDB 数据库中。Lambda 函数稍后将重试将这些事件发送到 Kafka。

7、消费者消费来自 Kafka 的事件。

感谢您耐心读完这篇文章，如果您喜欢我的分享风格和技术见解，希望您能将这篇文章分享给更多的朋友。我是编程探索者，一个热衷于技术交流与分享的程序员‍。关注我的头条号✨，更多精彩内容等您来发现，让我们一起成长，共同进步！