编排两个服务的分布式事务
在我们的示例图中，我们让服务 A 作为有状态的编排者，负责调用服务 B 并在需要的时候通过补偿操作从故障中恢复。这种方式的关键特征是，服务 A 和服务 B 有本地事务的边界，但是服务 A 有协调整个交互流程的知识和责任。这也是为什么它的事务边界会接触到服务 B 的端点。在实现方面，我们可以使用同步的交互，就像上图所示，也可以在服务之间使用消息队列（在这种情况下我们也可以使用两阶段提交）。
编排式的优点和缺点编排式是一种最终一致的方法，它可能会涉及到重试和回滚才能使分布式系统达到一致的状态。虽然避免了对分布式事务的需求，但是编排的方式要求参与的服务提供幂等的操作，以防协调者必须进行重试操作。参与的服务还必须要提供恢复端点，以防协调者决定执行回滚并修复全局状态。这种方式的最大优点是，能够仅通过本地事务就能驱动那些可能不支持分布式事务的异构服务达到一致的状态。协调者和参与的服务只需要本地事务即可，而且始终能够通过协调者查询系统的状态，即便它目前可能处于部分一致的状态。在下面我所描述的其他方式中，是不可能实现这一点的。
表 3：编排式的优点和缺点
协同式从迄今为止的讨论中，我们可以看到，一个业务操作可能会导致服务间的多次调用，并且一个业务事务完成端到端的处理所需的时间是不确定的。为了管理这一点，编排式（orchestration）模式会使用一个中心化的控制器服务，它会告诉参与者该做什么。
编排式的一种替代方案就是协同式（choreography），在这种风格的服务协调中，参与者在交换事件时没有一个中心化的控制点。在这种模式下，每个服务会执行一个本地事务并发布事件，从而触发其他服务中的本地事务。系统中的每个组件都要参与业务事务工作流的决策，而不是依赖一个中心化的控制点。在历史上，协同式方式最常见的实现就是使用异步消息层来进行服务的交互。图 6 说明了协同式模式的基本架构。
通过消息层进行服务协同化
具有双重写入的协同式为了实现基于消息的服务协同，我们需要每个参与的服务执行一个本地事务，并通过向消息基础设施发布一个命令或事件，以触发下一个服务。同样的，其他参与的服务必须消费一个消息并执行本地事务。从本质上来讲，这就是在一个较高层级的双重写入问题中又出现了另一个双重写入的问题。当我们开发一个具有双重写入的消息层来实现协同式模式的时候，我们可以把它设计成跨本地数据库和消息代理的一个两阶段提交。在前面，我们曾经介绍过这种方式。另外，我们也可以采用 publish-then-local-commit 或 local-commit-then-publish 模式：
- Publish-then-local-commit：我们可以先尝试发布一条消息，然后再提交本地事务。虽然这种方案听起来不错，但是它有一些切实的挑战。举例来说，在很多时候，我们需要发布一个由本地事务所生成的 ID，而这个 ID 此时还没有生成，因此无法发布。另外，本地事务有可能会失败，但是我们无法回滚已经发布的消息。这种方式缺乏“读取自己的写入”的语义，因此对于大多数场景来说，这并不是合适的方案。
- Local-commit-then-publish：一个稍好一点的办法是先提交本地事务，然后再发布消息。在本地事务提交之后和消息发布之前这里有很小的概率会出现故障。但即便是出现这样的情况，你也可以把服务设计成幂等的并对操作进行重试。这意味着会再次提交本地事务并发布消息。如果你能控制下游的消费者并且确保它们是幂等的，那么这种方式就是行之有效的。总体而言，这是一个很好的实现方案。
实现协同式架构的各种实现方式都限制每个服务都要通过本地事务写入到单一的数据源中，而不能写入到其他的地方中。我们看一下，如何在避免双重写入的情况下实现这一点。
假设服务 A 接收到一个请求并要对数据库 A 进行写入操作，除此之外不再操作其他的数据源。服务 B 周期性地轮询服务 A 并探测新的变更。当它读取到变更时，服务 B 会基于变更更新自己的数据库，并且会更新索引或时间戳来标记获取到了变更。这里的关键在于，这两个服务只对自己的数据库进行写入操作，并以本地事务的形式进行提交。如图 7 所示，这种方式可以描述为服务协同（service choreography），或者我们也可以用非常古老的数据管道的术语来对其进行描述。至于可供选用的实现方案就更有趣了。
通过轮询实现的服务协同
对于服务 B 来说，最简单的场景就是连接到服务 A 的数据库并读取服务 A 的表。但是，业界会尽量避免共享数据表这种级别的耦合，原因在于：服务 A 的实现和数据模型的任意变更都可能干扰到服务 B。我们可以对这种场景做一些改进，例如使用发件箱（Outbox）模式，为服务 A 提供一个表作为公开接口。这个表可以只包含服务 B 所需的内容，它可以设计得易于查询和跟踪变更。如果你觉得这还不够好的话，进一步的改进方案是让服务 B 通过API管理层查询服务 A 的所有变化，而不是直接连接数据库 A。
从根本上来讲，所有的这些变种形式都有一个相同的缺点：服务 B 需要不断地轮询服务 A。这种方式会给系统带来不必要的持续负载，或者在接收变更时存在不必要的延迟。轮询微服务的变更并不是常见的做法，那么我们看一下如何进一步改善这个架构。
使用 Debezium 的协同式在改进协同式架构时，有一种方式很有吸引力，那就是引入像Debezium这样的工具，它使用数据库 A 的事务日志执行变更数据捕获（change data capture，CDC）。这种方式如图 8 所示。
