今天来讲讲事务的使用。

互联网发展到目前，基本上中大型的公司都已经对大型的业务做过系统拆分了，也就是所谓的“微服务化”

就比如说我之前待过的电商公司，整个电商项目可以拆分成很多个子系统，比如会员系统，购物车系统，订单系统等等。这些子系统都是拥有独立的数据库，独立的接入网关。而完成整个电商的购物过程往往都需要这些子系统互相配合，也就是所谓的微服务调用。

那通常拥有独立数据库的各个微服务都存在一个问题：本地事务和分布式事务协调的问题。

简单来说就是：微服务A有本地事务，微服务B有本地事务，一个完整的分布式事务由A和B一起完成，如果A或者B有一方失败，整个分布式事务失败。

当然，我今天来说的不是分布式事务的实现方式，而是更细微的来谈谈如何来更好的协调微服务调用和事务的使用

假设A服务中有一部分数据需要请求B服务来获取，并且这部分数据会作为某项业务的关键依据，最后会在A服务中落库，你会怎么做呢？

我看过很多人写代码都是直接在service层的一个大方法上直接用上spring的@Transactional注解。很明显，这种方式是极度不合理的！

为什么呢？首先，如果代码分层做的好的话，service层中的代码应该不会特别复杂，很多和外部系统的交互会通过类似rpc模块来实现，service只需要调用即可，这样往往会导致程序员在做code review时忽略掉rpc失败的事务处理（代码写多了，很容易只关注局部的代码细节，忽略整体的代码正确性）

举个栗子，A服务在处理业务开始时就开启了一个本地事务，然后做一些业务处理，到某一步的时候需要调用B服务的一个接口，此时事务还是开启状态，未提交。调用B服务，此时有以下几种场景：

接口调用失败，此时事务回滚，无影响A调B成功，B本地事务执行成功，但是A本地事务执行失败，导致B和A数据不一致A调B超时，导致数据库连接长时间不释放，如果接口调用量大，很容易导致数据库挂掉

通常我们应该怎么做呢？据我所知业内大厂一般有两种做法，一种是避免这种同步式的交互方式，意思就是，A服务调用B服务的所有接口都是设计成异步的，后续通过补偿的方式来保证事务的最终一致性，这种方式是应对大调用量接口的一种较好的处理方式，但是有的场景总是需要同步调用，这种时候就需要用到第二种方式：在做代码分层的时候增加一层mannager层，一般就变为了controller层，service层，manager层，dao层。

具体的做法就是，将所有涉及到本地事务的操作统一放在manager层，manager层来管理整个事务，service只负责业务逻辑处理和远程调用，最后将数据传递至manager层做事务处理。

还是上面的例子，A服务的某项业务先做了一部分的业务逻辑处理，在调用B服务接口前不开启事务，而是将需要落库的数据一直传递下去，然后同步调用B的同步接口，此时由于未开启事务，所以哪怕接口超时，影响的也只是业务系统，不会影响数据库（一般数据库是整个服务中最脆弱的）

如果B的接口正常返回，将返回的数据统一做包装，然后处理完逻辑后统一传递给manager层，由manager层开启事务，此时，由于是纯粹的crud操作，速度非常快。

这样做能很好的避免在大事务中同步调用外部接口带来的性能问题，但是缺点也很明显：参数传递过多，代码可读性变差

但是代码可读性这个问题因人而异，通过加注释，合理使用设计模式等等手段都是可以改善的，但是提升系统的性能和规避可能带来的风险相对来说更重要

关注我，持续给您带来优质的技术文章！