具有共享数据库的模块化单体
模块化单体的优点和缺点在有些行业中，这种架构的收益远比其他地方所看重的更快的交付以及更快的变更节奏重要得多。表 1 总结了模块化单体架构的优点和缺点。
表 1：模块化单体架构的优点和缺点
分布式事务通常是最后的方案，通常会在如下的情况下使用：
- 当对不同资源的写入操作不允许最终一致性时；
- 当我们必须要写入到不同种类的数据源时；
- 当我们需要确保对消息的处理有且仅有一次，而且无法重构系统以实现操作的幂等性时；
- 当与第三方黑盒系统或实现了两阶段提交规范的遗留系统进行集成时。
在这些情况下，如果可扩展性不是重要的关注点的话，我们可以考虑将分布式事务作为一种可选方案。
实现两阶段提交架构两阶段提交技术要求我们有一个分布式事务管理器（如Narayana）和一个可靠的事务日志存储层。我们还需要能够兼容DTP XA的数据源，以及能够参与分布式事务的相关的 XA 驱动，比如 RDBMS、消息代理和缓存。如果你足够幸运有合适的数据源，但是运行在一个动态环境中，比如KUbernetes，那么你还需要有一个像 operator 这样的机制，以确保分布式事务管理器只有一个实例。事务管理器必须是高可用的，并且必须能够访问事务日志。
就实现而言，你可以尝试使用Snowdrop Recovery Controller，它使用Kubernetes StatefulSet模式来实现单例，并使用持久化卷来存储事务日志。在这个类别中，我还包含了适用于 SOAP Web 服务的Web Services Atomic Transaction（WS-AtomicTransaction）等规范。所有这些技术的共同点在于它们实现了 XA 规范，并且有一个中心化的事务协调器。
在我们的样例中，如图 4 所示，服务 A 使用分布式事务提交所有的变更到自己的数据库中，并且会提交一条消息到队列中，这个过程中不会出现消息的重复和丢失。类似的，服务 B 可以使用分布式服务来消费消息，并在同一个事务中提交至数据库 B，这个过程中也不会出现任何的重复数据。或者，服务 B 也可以选择不使用分布式事务，而是使用本地事务并实现幂等的消费者模式。在本节中，一个更合适的例子是使用 WS-AtomicTransaction 在一个事务中协调对数据库 A 和数据库 B 的写入，并完全避免最终一致性。但是，现在这种方式已经不太常见了。
跨数据库和消息代理的二阶段提交
两阶段提交架构优点和缺点两阶段提交协议所提供的保障与模块化单体中的本地事务类似，但有些例外情况。因为这里有两个或更多的独立数据源参与到原子更新之中，所以它们可能会以不同的方式失败并阻塞整个事务。但是，由于存在一个中心化的协调者，相对于我下面将要讨论的其他方式，我们还是能够很容易地发现分布式系统的状态。
表 2：两阶段提交的优点和缺点
编排式对于模块化单体来讲，我们会使用本地事务，这样我们始终能够知道系统的状态。对基于两阶段提交的分布式事务，我们也能保证状态的一致性。唯一的例外情况是事务协调者出现了不可恢复的故障。但是，如果我们想要减弱一致性的需求，而希望能够了解整个分布式系统的状态，并且能从一个地方对其进行协调，那么我们该怎么处理呢？
在这种情况下，我们可以考虑采取一种编排（orchestration）的方式，在这里，某个服务会担任整个分布式状态变更的协调者和编排者。编排者服务有责任调用其他的服务，直至它们达到所需的状态，或者在它们出现故障的时候执行纠正措施。编排者使用它的本地数据库来跟踪状态变更，并且要负责恢复与状态变更的所有故障。
实现编排式架构编排式技术最流行的实现是 BPMN 规范的各种具体实现，比如jBPM和Camunda。对这种系统的需求并不会因为微服务或 Serverless 这样的极度分布式架构的出现而消失，相反，这种需求还会增加。为了证明这一点，我们可以看一下较新的有状态编排引擎，它们没有遵循什么规范，但是却提供了类似的有状态行为，比如 Netflix 的Conductor、Uber 的Cadence和 Apache 的Airflow。像 Amazon StepFunctions、Azure Durable Functions 和 Azure Logic Apps 这样的 Serverless 有状态函数也属于这个类别。还有一些开源库允许我们实现有状态的协调和回滚行为，如 Apache Camel 的Saga模式实现和 NServiceBus 的Saga功能。许多实现 Saga 模式的自定义系统也属于这一类。
