微服务分布式事务落地方案

我认为微服务，应该有如下特征：1、专注某个领域的服务提供   2、独立JVM隔离  3、独立资源管理    4、可拔插

1、微服务实现

其实很简单，用dubbo就可以轻易实现不同service project 独立部署，实现高可用，高性能和高扩展性的API。其实这个实现方式太多了，没什么难度，难就难在如何实现微服务分布后的分布事务。这个是很多人避而不谈的，下面我们着重探讨一下。

2、分布事务实现

先看看下图，主要表述了以下几个东西：

1、web project（controller类）通过jetty容器分布部署，通过rpc（dubbo实现）方式远程调用service api。

2、微服务service api通过dubbo进行集群。

3、微服务service api有自己独立的数据库资源，独立管理。如果是某些业务涉及垮库写操作，可以通过混合事务实现。



说到事务，有必要对事务进行分类，以便分而治之。以比较典型的电商业务为例：

1）强一致性事务

场景：下订单，扣库存，必须实时保持一致。

对于要求较高的实时性业务，只要保证垮库操作在同一个虚拟机内完成，即可最大限度的保证强一致性事务。要保证同一虚拟机内，不同数据库连接操作实现同一事务，可以通过sharding-jdbc中间件实现。当当这个中间件名字起的有点高大尚，实质就是通过装饰器模式对datasource二次封装。在内部两个不同库操作的执行是这样的：



通过把commit后置，就可以有效控制回滚，而不需要实现复杂的所谓补偿事务。这个简单而有效的解决垮库事务问题，内部实现其实很简单。因为sharding-jdbc是通过装饰器模式对外提供了connection，而这个connection实质上是包装了两个库的连接，最后操作和提交都是循环两个连接分别执行的，没什么特别高深的奥秘。

按照微服务的思想，如果下单的时候需要操作库存，应该调用库存服务接口。但是，一旦这样做的话，就跨虚拟机了，这样只能保证最终一致性事务，无法保证实时。所以对于这种场景，必须要折衷处理，扣库存操作也在下单业务里面做，才能保证垮库事务实时性。

2）最终一致性事务

商户充值，储备金增加，财务记账，不必对实时性要求太高，但要保证尽可能快最终一致性。

显而易见可以通过事件总线解决，事件总线的实现核心，我建议采用kafka。