微服务篇：将事件驱动架构与现有系统集成

将组织转变到事件驱动架构需要将现有系统集成到新的生态系统中。你的组织可能有一个或多个单体关系型数据库应用程序。很可能存在不同实现之间的点到点连接。也许组织内已经有在系统之间传输大量数据的类似于事件的机制，比如通过中间的文件存储定期同步数据库镜像。如果是从头建立一个事件驱动型微服务架构，没有历史遗留系统，那真是太棒了！你可以直接跳过本章（尽管应该考虑一下事件驱动型微服务可能并不适合你的新项目）。但是，如果你需要支持现有的遗留系统，请继续阅读。

任何业务领域中都存在通常需要跨多个子领域的实体和事件。例如，一个电子商务零售商将需要提供产品信息、价格、库存和图像到各种界限上下文中。也许付款数据由一个系统收集，但需要在另一个系统中进行验证，然后在第三个系统中分析购买模式。将这些数据放于一个中心化的位置作为新的单一事实来源，当数据可用时，每个系统都可以消费它们。迁移到事件驱动型微服务需要在事件代理中提供必要的业务领域数据，这些数据可以作为事件流使用。这是一个被称为数据解放（data liberation）的过程，涉及从现有系统和包含数据的状态存储中获取数据。

任何系统都可以访问事件流中的数据，无论是事件驱动系统还是其他系统。事件驱动应用程序可以使用流式框架和原生消费者方式来读取事件，但是遗留的应用程序可能由于各种因素（比如技术和性能上的限制）而无法方便地访问这些事件。在这种情况下，需要将事件流中的事件落地到现有的状态存储中。

许多模式和框架可用于获取和落地事件数据。对于每种技术，本章将介绍为什么需要、如何做到以及不同方法间相关的权衡。然后，本章将回顾数据解放和落地如何融入整个组织、它们的影响以及让努力转化为成功的方式。

什么是数据解放

数据解放是对跨领域数据集的识别并发布到相应事件流中的过程，也是事件驱动架构迁移策略的一部分。跨领域的数据集包括所有存储在某个存储系统中的、其他外部系统所需要的数据。服务间和数据存储间的点到点依赖常常凸显出应该被解放的跨领域数据，如图 4-1 所示，3 个依赖的服务正在直接查询遗留系统。

数据解放强化了事件驱动架构的两个主要特性：单一事实来源和消除系统间的直接耦合。解放的事件流允许将新的事件驱动型微服务构建成消费者，并在适当的时候迁移现有系统。数据解放之后，响应式事件驱动框架和服务可用于消费和处理数据，下游消费者不再需要直接耦合到源数据系统上。通过充当单一事实来源，这些事件流标准化了跨组织系统访问数据的方式。系统不再需要直接耦合底层的数据存储和应用程序，而是可以只在事件流的数据契约上进行耦合。数据解放后的工作流如图 4-2 所示。

数据解放的折中方案

数据集及其解放的事件流必须保持完全同步，尽管由于事件传播的延迟，此要求仅限于最终一致性。解放的事件流必须能物化成原表的一个精确副本，这个特性被广泛应用于事件驱动型微服务（如第 7 章所述）。相反，遗留系统不会从任何事件流中重建数据集，而是通常有自己的备份和恢复机制，并且不从解放的事件流中读取任何数据。

在理想的情况下，所有的状态都要从作为单一事实来源的事件流中创建、管理、维护和恢复。所有共享状态都应该首先被发布到事件代理中，然后物化到所有需要物化这些状态的服务中，包括一开始生产这些数据的服务，如图4-3 所示

虽然对新的微服务和经过重构的应用程序来说，在事件代理中维护状态的理想可以实现，但要在所有应用程序中这么做并不一定适合且可行。对那些在开始集成“变更数据获取”机制前不太可能重构或更改的服务来说尤其如此。遗留系统对组织来说非常重要又难以重构，最糟糕的情况是原来的代码就是“一个大泥球”（a big ball of mud）。尽管系统很复杂，但其他新系统仍然需要访问它们的内部数据。虽然很希望进行重构，但现实中有许多问题会阻止其进行。

缺乏开发人员支持

　　许多遗留系统有极少的开发人员支持，需要低成本的解决方案来生成“解放的数据”。

重构成本

　　将已存在的应用程序工作流重新改造成异步事件驱动和同步 MVC（模型–视图–控制器）模式混合的 Web 应用程序逻辑是代价非常高的事情，而对复杂的遗留单体系统来说更是如此。

遗留支持风险

　　对遗留系统所做的更改可能会产生意想不到的后果，尤其是当因技术债以及与其他系统的点到点连接不明确而导致系统的责任不明确时。

有一种折中的方案。可以使用数据解放的模式从数据存储中提取数据并创建必要的事件流。这是一种单向的事件驱动架构形式，因为遗留系统不会如图4-3 所示那样从事件流中读回数据。它的根本目标是通过严格控制的事件数据发布过程来保持内部数据集和外部事件流的同步。事件流会与遗留应用程序的内部数据集达到最终一致，如图 4-4 所示。

将被解放的数据转化成事件

与任何其他事件一样，被解放的数据也要遵循第 3 章中介绍的结构化建议。定义良好的事件流的一个特点是，它所包含的事件有一个显式定义的、可演化的兼容 schema。作为 schema 定义的数据契约的一部分，应该确保消费者有基本的数据质量保证。对 schema 的变更只能根据演化规则来进行。

　在整个组织中对被解放的事件数据和原始的事件数据采用相同标准的格式。

根据定义，在业务中与业务最相关且常用的数据就是需要被解放的数据。对数据源的数据定义做出更改，比如创建新的字段、更改现有字段或删除其他字段等，可能导致动态变更数据操作传播到下游消费者。如果不能为解放的数据使用显式定义的 schema，那么将迫使下游消费者解决所有不兼容问题。这对提供单一事实来源来说是很困难的，因为下游消费者不应该试图自己解析数据。提供可靠的数据以及最新的 schema 并仔细考虑数据随时间的演变，这一点非常重要。

数据解放模式

有 3 种主要的数据解放模式可用于从底层数据存储中提取数据。因为解放数据意味着要形成新的单一事实来源，所以它必须包含数据存储中的全部数据集合。此外，新的插入、更新和删除操作必须保持数据一致。

基于查询

　　通过查询底层状态存储提取数据。这可以在任何类型的数据存储中执行。

基于日志

　　可以根据记录着底层数据结构变更的追加日志来提取数据。该选项只适用于维护着数据修改日志的选择型数据存储。

基于表

　　在这个模式中，首先将数据推送到一个用作输出队列的表中。另一个线程或单独的进程会查询该表，将数据发布到相关的事件流中，然后删除相关实体。这种方法要求数据存储同时支持事务和输出队列机制，通常是将一个单独的表配置为队列使用。

虽然每种模式都是独特的，但这 3 种模式有一个共同点。每种模式都应该以排列好的时间戳顺序生成事件，在输出事件记录头中使用源记录的最新updated_at 时间。这将以事件的发生时间戳而不是生产者发布事件的时间来生成事件流。这对于数据解放是相当重要的，因为它准确地表示了事件在工作流中的发生时间。基于时间戳的事件交错场景将在第 6 章中进一步讨论。

数据解放框架

解放数据的一种方法是使用专用、集中式的框架将数据提取到事件流中。捕获事件流的集中式框架包括 Kafka Connect（专门用于 Kafka 平台）、Apache Gobblin 和 Apache NiFi。每个框架都让你可以对底层数据集执行查询，将结果通过管道传输到输出事件流。这里介绍的每个框架都是可伸缩的，这样就可以添加更多的实例来增加执行“变更数据捕获”（change datacapture，CDC）作业的能力。它们支持与 Confluent（Apache Kafka）提供的 schema 注册表进行多级别的集成方案，也可以执行自定义操作以支持其他 schema 注册方案。关于“schema 注册”的更多信息，请参见 14.5 节。

并非所有的数据解放过程都需要专用的框架，许多系统更适合直接开发自己的事件流数据生产方案。事实上，这些框架无意中滋生了数据访问的反模式。最常见的反模式之一是将内部数据模型暴露给外部系统，从而进一步增加耦合而不是减少耦合，而后者恰是事件驱动架构应提供的主要优点之一。这一点将在本章接下来的内容中进一步讨论。