分布式事务

        在微服务结构中，分布式事务是经常要考虑的问题。分布式事务解决方案有多种，有各自的优劣势和适用场景。主流的分布式事务框架库是阿里的 seata， 将根据 seata 库说明这些分布式事务的特点。

        尽量避免使用分布式事务。按照领域驱动设计思想，微服务之间是低耦合，微服务内部是高内聚，领域的限界上下文一般都在一个微服务里，那么微服务内的领域模型也是高内聚的。良好的架构设计只需在微服务里通过本地事务和领域事件就能够用，如果必须使用分布式事务一般意味着微服务之间存在高耦合，此时，应该考虑一下架构设计是否有问题，是否需要重构来解耦，从而避免使用分布式事务。还有一些场景也能避免使用分布式事务。一般要完成一个业务操作，先进行各种查询验证，再进行本地和外部服务同步增删改操作，然后做一些异步操作。先进行一系列查询验证，任何一步没有通过就不用进行后续操作，也就不涉及到事务相关的。如果查询验证通过了，要进行业务关键同步操作，如果依赖外部微服务关键操作只有一个，并且该关键外部请求失败，则代表整个业务失败，也就无需相关事务。 如果先执行的本地操作成功，再执行外部服务关键同步操作失败，那么通过本地事务完成本地操作的回滚。如果前面关键操作都成功后，在执行一些异步事件通知时，即使立即失败了，通过事件缓存和多次重试从而最终能完成一致性，不会对整个业务操作有大的影响。 因此，在关键外部服务的操作不超过 1 个情况下，可以不用分布式事务。 通过良好架构设计和具体关键同步操作分析，可以避免绝大多数的分布式事务。

        seata AT 模式。这个适合本地服务里有多个 jdbc 数据源，对多个 数据库操作来完成分布式事务，并且对现有业务没有侵入性。一般情况下，常规的微服务的数据源除了主从集群外只有一个数据源，一个微服务访问另一个微服务的数据库是不合规的，因此，seata AT 模式能适用的场景很少，也就不怎么推荐。

        seata TCC 模式。这个适合自定义控制业务的分布式事务的解决方案，需要自己实现prepare、commit、rollback 的具体业务逻辑，能够做到控制精细，但对业务的侵入性强，自己工作量大还要考虑各种复杂逻辑的处理，但性能相对 AT 和后面的 XA 模式都要高。TCC 模式一般情况下不推荐使用，它对开发人员要求高，对现有业务侵入性强。

        seata XA 模式。XA 模式对业务是无侵入的，并且只要数据库 XA 协议就行，而且主流数据库厂家都支持 XA 协议，这样使用起来简单，适用面广，和使用本地事务模式相同。XA 模式性能较差，事务锁定资源周期长，不过既然使用事务了，性能已经不是关键考虑项。如果你的微服务使用的是主流关系型数据库，都支持 XA 协议的话，优先推荐使用 seat XA 模式。

        saga 模式。saga 模式适合业务流程长、业务流程复杂，涉及微服务多，并且不支持 XA 协议数据库，例如 noSql 数据库，此时 saga 模式比较合适。saga 采用 base 理论，通过事件驱动架构，参与者都异步执行，自定义实现补偿。saga 模式实现分为协同式和编排式，协同式需要多个参与微服务一起协同参与，编排式则由一个参与者主导完成各方参与者，显然编排式业务逻辑比较集中，容易把控维护，不像协同式那么分散，所以推荐编排式，编排式实现一般通过状态机框架协助实现，seata saga 主要也就是提供了状态机。saga 模式对业务的侵入性强，都需自定义实现，但灵活性高，适用面广，采用异步事件，性能也高，可用性也好，有些微服务架构方面书籍力主推荐 saga 来完成分布式事务。saga 的隔离性有些问题，但通过一些复杂方案也可以解决。当 XA 模式不能满足的情况下，请考虑使用 saga 模式。

        总结：在面对微服务中分布式事务时，优先考虑是否通过重新架构设计和分析来避免分布式事务。如果不能，请优先使用 seata 的 XA 模式，如果 XA 模式不合适，再考虑 saga 的编排式来实现分布式事务。