如何解决面向服务架构的分布式事务问题？

1.两阶段提交协议。

有两个阶段：准备阶段和提交阶段。 基于两阶段协议，事务管理器可以最大化跨数据库操作的事务原子性，这是分布式系统环境下最严格的事务实现方法。

但是，两阶段协议存在性能问题，难以横向扩展，因为在提交事务的过程中，事务管理器需要每个参与者协调准备和提交操作，在准备阶段锁定资源，在提交阶段消耗资源。 由于参与者数量众多，锁定资源和消耗资源之间的时间差会拉长，导致响应速度变慢，出现死锁或结果不确定的可能性更大。 两阶段提交协议在互联网上很少使用。

两阶段提交协议是一种在极端情况下无法快速响应请求者的阻塞协议，因此提出了一种三阶段提交协议来解决两阶段提交协议的阻塞问题，但它仍然需要事务管理器在参与者之间进行协调才能完成分布式事务。

2.尽力而为的保证模式。

这是保证分布式一致性的一种非常通用的模式，很多开发者一直在使用，但是没有认识到这是一种模式，而尽力而为的保证模式适用于一致性要求不是很严格但性能要求很高的场景。

具体实现如下：在更新多个资源时，尽可能将多个资源的提交延迟到最后一刻，如果业务流程出现问题，可以回滚所有资源更新，事务保持一致。 唯一可能出现的问题是在提交多个资源时出现系统问题，例如网络问题。

但是，这种情况非常罕见，当它发生时，需要实时补偿以回滚提交的事务。 当然，在使用这种模式时，我们需要考虑每个资源的提交顺序。 我们在生产实践中遇到的反模式之一是将远程调用嵌套在数据库事务中，而远程调用是耗时的任务，导致数据库事务被拉伸并最终拖累数据库。

3.交易补偿机制。

在性能关键型场景中，两阶段提交协议不是一个好的解决方案，并且尽力而为的保证模式还允许多个分布式操作相互嵌套，从而可能相互影响。 这里我们给出交易补偿机制，该机制具有很高的性能，可以尽可能地保证交易的一致性。

对数据库进行分片和表分片后，如果单个数据库内完成了多个更新操作，则可以使用数据库内的本地事务来保证一致性。 对于跨数据库的多个操作，可以进行补偿和重试，使其在一定时间窗口内完成操作，从而实现事务的最终一致性，突破了遇到问题时回滚事务的传统思路。 如果使用事务补偿机制，当遇到问题时，需要记录问题的环境、信息、步骤和状态，然后使用重试机制来实现最终的一致性。

房东的声明非常标准，不是不可用，只是不适用。 让我们来看看为什么分布式事务不再适合微服务架构。

多个微服务应用程序组成了一个分布式系统，这带来了固有的复杂性。 开发者需要在RPC和消息传递之间做出选择，并完成进程间的通信机制。 更重要的是，他们必须编写 ** 来处理消息传递中速度太慢或不可用的本地故障。

当然，这不是一项艰巨的任务，但该技术比使用语言级方法或进程调用的单体应用程序更复杂。

微服务的另一个挑战来自分区数据库体系结构。 在业务交易记录中，多个业务子实体同时更新是很常见的。 这种事务对于单体应用程序来说很容易，因为只有一个数据库。

在微服务架构应用中，需要更新不同服务使用的不同数据库。 使用分布式事务不一定是一个好的选择，这不仅是因为CAP理论，还因为当今高度可扩展的NoSQL数据库和消息中间件不支持这种需求。 最终，您必须使用最终一致的方法，这给开发人员带来了更高的需求和挑战。

部署微服务应用程序也很复杂，分布式应用程序可以简单地在复杂的均衡器后面部署自己的服务器。 每个应用实例都需要配置数据库、消息中间件等基础服务。 相比之下，微服务应用通常由大量的服务组成。

例如，根据 Adrian Cockcroft 的说法，Hailo 有 160 种不同的服务组合，而 Netflix 有大约 600 种服务。 每个服务都有多个实例。 这会产生许多需要配置、部署、扩展和监视的部分，此外还需要完成服务发现机制，以发现与其通信的服务的地址（包括服务器地址和端口）。

传统的解决问题的方法无法用于解决如此复杂的问题。 开启后，成功部署微服务应用需要开发人员对部署方法有足够的控制权和高度的自动化。

总而言之，简而言之，因为每个微服务都是以多种方式实现的，当微服务有很多时，一个服务进程可能会涉及多个服务，如果这些微服务耦合得太紧密，就需要保证它们事务的一致性，但这是一件非常困难的事情。

传统应用使用本地事务和分布式事务来保证数据的一致性，但在微服务架构中，数据是私有的，需要通过服务提供的API进行访问，因此分布式事务不再适用于微服务架构。

分布式事务是指事务的参与者、支持事务的服务器、资源服务器和事务管理器位于不同分布式系统的不同节点上的事务。