传统单体架构下的分布式事务概念并不适合微服务，面临的挑战很多(挑战问题点击标题见原文)，想在微服务中进行分布式事务处理？需要改变思路和视角：
- 组合，如果您认为您应该合并几个微服务或将事务集成到一个服务中，那么进行此练习永远不会晚。（banq注：根据DDD有界上下和聚合的概念将需要事务的操作聚合起来：https://www.jdon.com/54023）
- 为事务构建一致且有用的审核，并确保您始终捕获审核，即使服务超时也是如此。一个简单的示例，比如有事务ID，实体ID的结构化日志以及定义策略的能力，这些策略使您能够跟踪失败的事务并由数据操作团队进行修复（这是非常关键的）。您需要使他们能够解决这些问题，如果涉及工程团队，则您的审核设置将失败）
- 重新设计过程以进行混乱测试。不要用假设的场景进行测试（例如杀死服务，然后查看其他组件的行为），而是尝试生成可能导致服务终止或超时的情况或数据或序列，然后查看弹性/重试在其他服务中的工作方式。
- 对于新需求，请始终根据测试时间而不是开发时间进行估算，影响分析并制定行动计划（因为现在您将花费大部分时间进行测试）。
- 将断路器集成到您的生态系统中，以便您能够检查所有服务（即将参与这些交易的服务）是否都处于健康状态。这样，您甚至可以在开始交易之前就避免半成品交易。
- 采用批处理，其中您可以批量和脱机转换一些关键事务，以使系统更加稳定和一致。例如，在电子商务中，您在供应商和消费者数据库中都有产品。在这里，您不必先编写分布式事务在两个数据库中来创建新产品，而是首先只能在供应商数据库中编写并运行批处理以挑选100个新产品并将其插入到消费者数据库中。对于订单微服务和库存微服务之间需要实现分布式事务，您可以使用以下设计以批处理替代：
在这里，您仍然可以进行扩展，隔离和独立部署，但是批处理过程将使其更加一致。 - 不要尝试构建两阶段提交，而要使用一种仲裁器模式，该模式本质上支持弹性，重试，错误处理，超时处理和回滚。这也适用于PUB-SUB，使用此方法，您无需使每个服务都强大，只需确保仲裁员能够处理大多数情况。
- 为了提高性能，您可以使用IPC，跨进程的内存共享和TCP，（如果有闲聊的微服务检查gRPC或websocket）作为其余API的替代方法。
- 如果处理不当，配置将成为噩梦。如果您的应用由于缺少配置而导致生产失败，并且您正忙于回滚，修复和重新部署，则此处还需要其他内容。很难精简每个微服务配置，并且在交付生产之前您永远无法弄清所有缺失的配置。