通过变更数据捕获实现的服务协同

Debezium 可以监控数据库的事务日志，执行必要的过滤和转换，并将相关的变更投递到 Apache Kafka 的主题中。这样的话，服务 B 就可以监听主题中的通用事件，而不是轮询服务 A 的数据库或 API。我们通过这种方式，将数据库轮询转换成了流式变更，并且在服务间引入了一个队列，这样会使得分布式系统更加可靠、可扩展，而且为新的使用场景会引入其他消费者提供了可能性。Debezium 提供了一种优雅的方式来实现发件箱模式，能够用于基于编排式和协同式的Saga模式实现。

这种方式的一个副作用在于，服务 B 有接收到重复消息的可能性。这可以通过实现幂等的服务来解决，可以在业务逻辑层面来解决，也可以使用技术化的去重器（deduplicator，比如 Apache ActiveMQ Artemis 的重复消息探测或者 Apache Camel 的幂等消费者模式）。

事件溯源（event sourcing）是另外一种服务协同的实现模式。在这种模式下，实体的状态会被存储为一系列的状态变更事件。当有新的更新时，不是更新实体的状态，而是往事件的列表中追加一个新的事件。往事件存储中追加新的事件是一个原子性的操作，会在一个本地事务中完成。如图 9 所示，这种方式的好处在于，对于消费数据更新的其他服务来讲，事件存储的行为也是一个消息队列。

通过事件溯源实现的服务协同

在我们样例中，如果要转换成使用事件溯源的话，要把客户端的请求存储在一个只能进行追加操作的事件存储中。服务 A 可以通过重放（replay）事件重新构建当前的状态。事件存储需要让服务 B 也订阅相同的更新事件。通过这种机制，服务 A 使用其存储层作为与其他服务的通信层。尽管这种机制非常整洁，解决了当有状态变更时可靠地发布事件的问题，但是它引入了一种很多开发人员所不熟悉的编程风格，并且围绕状态重建和消息压缩，会引入额外的复杂性，这需要专门的存储。

不管使用哪种方式来检索数据变更，协同式的模式都解耦了写入，能够实现独立的服务可扩展性，并提升系统整体的弹性。这种方式的缺点在于，决策流是分散的，很难发现全局的分布式状态。要查看一个请求的状态需要查询多个数据源，这对于服务数量众多的场景来说是一个挑战。表 4 总结了这种方式的优点和缺点。

表 4：协同式的优点和缺点

在协同式模式中，没有一个中心化的地方可以查询系统的状态，但是会有一个服务的序列，以便于在分布式系统中传播状态。协同式模式创建了一个处理服务的序列化管道，所以我们能够知道当一个消息到达整个过程的特定步骤时，它肯定已经通过了前面的所有步骤。如果我们能够放松这个限制，允许独立地处理这些步骤的话，情况又会怎样呢？在这种场景下，服务 B 在处理一个请求的时候，根本不用关心服务 A 是否已经处理过它。

在并行管道的方式中，我们会添加一个路由服务，该服务接收请求，并在一个本地事务中通过消息代理将请求转发至服务 A 和服务 B。如图 10 所示，从这个步骤开始，两个服务可以独立、并行地处理请求。

通过并行管道进行处理

尽管这种模式很容易实现，但是它只适用于服务之间没有时间约束的场景。例如，服务 B 不管服务 A 是否已经处理过该请求，它都能够对请求进行处理。同时，这种方式需要一个额外的路由服务，或者客户端知道服务 A 和服务 B，从而能够给它们发送消息。

这种方式有一种轻量级的替代方案，被称为“监听自身（listen to yourself）”模式，在这里，其中有个服务会同时担任路由。在这种替代方式下，当服务 A 接收到一个请求时，它不会写入到自己的数据库中，而是将请求发送至消息系统中，而消息的目标是服务 B 以及服务 A 本身。图 11 阐述了这种模式。