微服务事务的选型和应用问题？

微服务架构中涉及到跨数据库，跨微服务，跨系统之间的服务调用，若对数据一致性有要求，那么都是属于分布式事物范畴。一旦架构中涉及到了分布式事物，那么需要梳理下，
1、能否把分布式事物变成事物（即通过服务划分的方式把涉及到多库调用合并在一个库上执行），即尽可能减少分布式事物的产生。
2、如通过方案1解决不了的问题，那么可以使用开源的分布式事物框架，例如阿里开源的seta，最简单的AT模式只需要增加注解就可以满足分布式事物，但是对性能损耗比较大。 它为用户提供了 AT 、 TCC 、 SAGA 和 XA 事务模式 。
3、如是非强一致性数据要求（例如有1秒的数据不一致性），那么可以使用柔性事物，使用MQ事物来解决。这个也是互联网比较通用的做法，通过本地事务和发送 MQ 消息这种柔性事物方式来解决分布式事物所面临的问题，既能保障服务的稳定性又能保障调用效率的高效性，在 MQ 可以使用 Apache 的 RocketMQ 所提供的事物消息和本地事物表结合。其中以下概念需要理解下：

² 半事务消息：暂不能投递的消息，发送方已经成功地将消息发送到了消息队列服务端，但是服务端未收到生产者对该消息的二次确认，此时该消息被标记成“暂不能投递”状态，处于该种状态下的消息即半事务消息。

² 消息回查：由于网络闪断、生产者应用重启等原因，导致某条事务消息的二次确认丢失，消息队列服务端通过扫描发现某条消息长期处于“半事务消息”时，需要主动向消息生产者询问该消息的最终状态（ Commit 或是 Rollback ），该询问过程即消息回查。
总的来说，看业务方对数据不一致性的容忍度有多少，具体的需求需要根据业务需求来处理。