微服务分布式事务疑惑

Question

消息驱动模式我刚看到一半， 有些疑惑？
分布式事务的出现很大程度是因为微服务架构的流行，微服务架构体系都出现这么久了，应该有相关解决技术框架， 我去查看了相关资料， 像 spring cloud alibaba 提供的 Seata ， 还有像 SpringCloud TX-LCN 技术框架， 都是解决分布式事务的技术呢？
消息驱动我还未看完， 微服务架构体系中， 服务和服务间的调用，都是基于 RestTemplate 或 Fegin 做的调用， 也就是基于 resful 的请求，很少说采用消息队列交互？
有个疑惑，老师讲的这些，是目前公司解决微服务架构体系分布式事务解决方案吗？

Answer 1

大漠风 2020-06-01 10:31:24

在使用SpringCloud的微服务框架的时候，各个微服务之间一般是用feign进行直接调用，其实也就是rest请求。

但是，之间进行rest请求调用时，出错的情况下，怎么样才能保证事务性？这个在视频中也解释过。所以，服务之间rest的读请求都没有问题，我们需要考虑的是服务之间的写请求怎么保证。

对于这个，有两个办法，一个是在RPC框架里面解决，在springcloud里就是feign框架，在调用某个服务的时候，如果出错了，进行重试（但是也要区分业务的异常、系统异常）；

如果再复杂一点，那就是在RPC的框架里面，通过一定方式实现事务，比如说TCC事务补偿，也就是说，如果调用一个接口出错了，就要调用其他服务和接口进行补偿或回滚。但是这种方式就很难，而且对代码的侵入性也非常重。

就像你在回答里面写的，我们需要减少代码的侵入性，而在几种分布式事务的实现方式当中，用消息驱动的方式，代码的侵入性相对是比较小的，但是在设计上就要做一些特殊设计。但是这个设计，其实也是在大部分系统架构中会用到的，因为很多时候，我们都会通过消息队列，将原先的同步操作，变成异步操作，从而提高系统的吞吐量。

在我们之前公司的架构中，是结合服务间feign调用和消息驱动结合来实现分布式事务的，对于关键的服务间调用的场景，使用消息驱动的方式，这既能保证数据的最终一致性，也能通过异步提高并发量，提高响应速度。

Answer 2

提问者 上游猴子 2020-05-29 12:59:23

从设计角度来看的话，分布式事务设计应该尽量去减少代码的入侵性，  业务服务专心做业务，不去参杂太多的事务实现东西。