McDonald‘s Event-Driven Architecture 麦当劳事件驱动架构

原文链接 1 mcdonalds-technical-blog/

原文链接 2 mcdonalds-technical-blog/

麦当劳在异步、事务性和分析性处理用例中使用跨技术栈的事件，包括移动订单进度跟踪和向客户发送营销通信（交易和促销）。

统一事件平台（unified eventing platform）旨在为跨域服务和应用程序之间的实时数据流提供一个可扩展、安全可靠的平台。它确保了一致性，并降低了维护和采用事件架构所涉及的实现和操作复杂性。

挑战:

虽然基于事件的集成在麦当劳并不新鲜，但我们已经看到了各种各样的技术和模式在构建平台时使用的各种技术和模式。缺乏标准化的方法可能导致实现不一致且操作复杂，从而影响可用性、可靠性和数据质量。当我们开始设想这个平台时，我们建立了一些高层次的设计目标，使我们的团队能够朝着正确的方向工作。

设计目标:

可伸缩（Scalable）：需要自动伸缩，以适应不断增加的事件数量，而不会影响服务质量。

可用性（Available）：需要高可用性，以承受（withstand）其组件的故障。

高性能（Performant）：应该实时交付事件，并能够处理高度并发的工作负载。

安全（Secure）：数据必须遵循围绕加密、访问控制等的数据安全指南。

可靠的（Reliable）：必须可靠的控制到位，以避免丢失任何事件。

一致性（Consistent）：必须在围绕错误处理、弹性、模式演变、监视和灾难恢复的模式实现中保持一致性。

简单（Simple）：需要最小化实现和操作的复杂性，并使团队能够轻松地在平台上构建。
考虑到这些目标，我们选择了一组工具、技术和模式来创建统一的平台。

引擎盖下面（Under the hood）：

在整体层面，可以创建事件并将其发送到 architecture，消费者（其他应用程序）进一步处理事件。

它有几个关键组成部分：

事件代理（Event Broker）：- AWS Managed Streaming for Kafka

        我们使用AWS Managed Streaming for Kafka Service （MSK）来托管主题和事件，并为生成和消费事件提供语义，因为它与我们使用的其他AWS服务集成在一起。在减少操作开销和对用例进行定制的灵活性之间取得良好的平衡是很重要的。

模式注册表（Schema Registry） - AWS Elastic Container Service：

        发布到基于事件的体系结构的事件遵循定义良好的契约，确保下游消费应用程序中的数据质量，同时在事件模式更改时为生成应用程序提供清晰的演进路径。注册中心在事件的不同版本之间运行模式验证和兼容性检查。

备用事件存储（Standby Event Store） - AWS DynamoDB：

        为了避免在MSK不可用的情况下丢失消息，平台连接了一个备用数据存储，它将事件写入数据库。该体系结构提供了工具和实用程序来读取消息，并在MSK可用时将其发布回MSK。

自定义软件开发工具包（SDK） (Custom Software Development Kits)：

        我们构建了特定于语言的库，为生产者和消费者提供api，以编写和读取具有内置逻辑的体系结构事件，以执行模式验证、处理错误和实现重试模式。sdk作为我们开发团队的加速器，提高了他们的生产力，并提供了实现最佳实践的一致方法。

事件网关(Event Gateway)：- AWS API Gateway

        McDonald的基于事件的体系结构既支持我们应用程序内部生成的事件，也支持外部合作伙伴应用程序生成的事件，这些事件通过带有身份验证和授权层的事件网关进行路由。网关在不暴露内部主题管理的情况下提供了灵活性和抽象性。

支持的实用程序和工具(Supporting Utilities and Tools)：Infrastructure as code, monitoring UI&CLI tools

        我们的开发人员和服务可靠性工程师有一组工具来纠正死信主题中的事件，提供对集群健康状况的可见性，并执行任何集群管理任务。

可靠的事件处理

下面是一个典型的数据流，说明事件是如何从平台可靠地产生和消费的：

1，在模式注册中心定义并注册事件模式。

2，需要生成事件的应用程序利用生产者SDK来发布事件。

3，当应用程序启动时，在生成应用程序中缓存事件模式以获得高性能。

4，SDK执行模式验证以确保事件符合模式。

5，如果验证通过，SDK将事件发布到主主题。

6，如果SDK遇到错误，比如模式验证或可检索的错误，它将被路由到绑定到该生产者的死信主题。

7，如果SDK遇到错误，例如MSK不可用，则将其写入DynamoDB数据库。

8，需要消费事件的应用程序利用消费者SDK来实现这一点。

9，SDK类似地执行模式验证，以确保所消费的事件与模式一致。

10，一次成功的消费将导致将偏移量提交回MSK，并继续消费该主题的下一个事件。

11，死信主题中的事件稍后通过管理实用程序进行修正，并发布回主主题。

12，我们的合作伙伴产生的事件，或“外部事件”，通过事件网关发布。

数据治理（Data governance）

        消费系统（ consuming systems）的一个关键问题是数据完整性。在保证数据完整性的前提下，可以为下游系统的设计节省大量的时间和复杂性。MSK以及模式注册表允许我们在系统之间强制执行数据契约。模式被定义为描述预期的数据字段和类型，以及可选字段和必选字段。在实时情况下，将根据该模式（通过序列化库）检查每个消息的有效性，否则将消息路由到死信主题以进行更正。

模式的使用方式如下所示：

在启动时，生产者将一个已知模式列表缓存到内存中。可以出于多种原因更新模式，包括增加更多字段或更改数据类型。当生产者发布消息时，在每个消息的开头使用自定义魔术字节将版本控制信息存储在主题中。稍后，当使用消息时，魔术字节将确定应该使用哪种模式来使用消息。该系统有助于减少主题中的滚动更新和混合消息版本。如果我们需要回滚或进行新的模式更新，消费者有权解析每条消息。

以这种方式使用模式注册中心可以验证跨不同系统的数据契约，并有助于确保下游分析系统中的数据完整性。

集群自动扩展（Cluster autoscaling）

        虽然MSK提供了连接到代理的存储的自动伸缩，但是必须构建一个扩展集群的解决方案。我们创建了一个自动缩放函数，当代理的CPU利用率超过可配置的阈值时触发该函数，将代理添加到MSK集群，然后触发另一个lambda函数在代理之间移动分区。

域的分片（Domain-based sharding）

        为了有效地扩展和最小化故障，我们将事件分为多个基于域的MSK集群。事件的域决定主题将驻留在哪个集群中，消费应用程序可以灵活地使用来自任何基于域的主题的事件。该平台旨在支持跨区域的全球部署，并在每个区域中配置高可用性配置。

【🤣  你看完什么感觉？  🤣】