我读了一篇帖子说：
我们不能在分布式环境中实现微服务中的两阶段提交等传统的事务系统。
我完全赞同这一点。
但如果有人在这里可以解释其确切原因，那就太好了。如果我用微服务实现两阶段提交，那么我将要面对的问题是什么？
提前致谢
避免两阶段提交的主要原因是，事务协调器是一种独裁者，因为它告诉所有其他节点要做什么。通常，事务协调器嵌入在应用程序服务器中。在第一阶段或准备阶段之后，事务协调员或应用程序服务器发生故障时会出现问题。现在，参与节点不知道该怎么做。他们不能承诺，因为他们不知道其他人是否以“否”回复协调员，他们无法回滚，因为其他人可能对协调员说“是”。因此，在协调员在15分钟（比如说）之后回来并完成第二阶段之前，参与的数据存储将保持锁定状态。这会抑制可扩展性和性能。当协调器的事务日志在第一阶段之后被破坏时，会发生更糟糕的事情。在这种情况下，数据存储将永远保持在锁定状态。即使重新启动流程也无济于事。唯一的解决方案是手动检查数据以确保一致性，然后删除锁。这些事情通常发生在高压情况下，因此它肯定是一个巨大的运营开销。因此传统的两阶段提交不是一个好的解决方案。
但是，应该注意的是，像Kafka这样的一些现代系统也实现了两阶段提交。但这与传统解决方案的不同之处在于，每个经纪人都可以成为协调员，因此Kafka的领导者选举算法和复制模型可以缓解传统模型中提到的问题。
“我们不能”在这里真的意味着“这是一个坏主意，我不想，如果我承认这种可能性，那么我可能无法说服你不要坚持”。
当然，您可以跨微服务实现两阶段提交，但是：
这些问题很难在具有专用网络的共址服务器上的一些紧密耦合的服务之间进行管理。在更加异构的环境中，具有更多服务器和更高的延迟（这是微服务部署的特征），它变得更加困难。
微服务的整体思想是松散耦合和独立的服务。由于2pc意味着我们有2个阶段来提交事务。控制节点将驱动事务，所有其他节点首先响应它们准备好，在第二阶段它们都根据第一阶段提交或回滚。
如果控制节点关闭会发生什么？当任何其他节点关闭时会发生什么？由于这种限制，您的整个交易无法通过。在分布式事务中，您的节点可以位于不同的数据中心或区域中。最慢的响应节点将使其他节点在继续运行时保持等待状态。原子性阻碍了表现。
您无法扩展系统和整点，服务应该是独立的，并且可以扩展可扩展性。
2pc不是错误的答案，但在大多数情况下，我们考虑最终的一致性。如果您的系统需要强一致性，则可以选择2pc。
有些事情需要注意，并给出一些背景知识：