Milo源码解析（二）

引入Milo框架

在样例工程中保护了三个微服务模块cloud-order、cloud-account、cloud-stock。这三个模块模拟了具有分布式事务场景的下单场景，用户购买商品下单，生成订单，接着扣减用户的账号金额，最后扣除商品的库存。由于实在分布式环境，三个微服务拥有自己独立的数据库，这使得如果没有处理号这种分布式业务场景，很容易就会出现三个微服务数据不一致的情况，最严重的应该就是订单没有生成，但是用户的账号金额被扣减了。所以我们需要分布式事务Milo去控制这样的业务场景。

springcloud微服务引入Milo框架非常简单，先在项目中引入milo-spring-cloud-starter依赖

接着在application.yml配置文件配置milo的相关参数即可

测试样例的数据库表结构

在我们的样例中的三个微服务分别对应着自己的数据库

账户服务milo_account库

账户表，balance表示用户的账户余额，freeze_amount：表示用户账户的冻结总金额。

账户冻结明细表，表示每一个订单对应的冻结金额，在完成订单后删除冻结明细，下单失败，则回退冻结金额给用户，删除冻结明细。

库存服务milo_stock库

库存表，total_stock表示商品的总库存，lock_stock表示冻结的库存，这和账户表是类似的。

库存冻结明细表，表示每一个订单对应的冻结库存，在完成订单后删除冻结明细，下单失败，则回退冻结库存给总库存，删除冻结明细。

订单服务milo_order库

订单表，count表示购买的件数，amount表示订单的总金额，status表示订单的状态。

解析测试样例的下单业务

测试样例的下单业务入口是cloud-order服务，所以我们先看cloud-order服务的下单入口


下单请求过来后去调用OderService创建订单，创建订单时先通过AccountInter和StockInter的feign接口类去调用账户服务和库存服务查询是否有足够的金额和库存，接着创建未支付的订单。

插入未支付的订单之后，发起具有分布式事务业务场景的订单支付，也就是我们TCC分布式事务中的Try阶段方法。

可以看到在支付订单的业务方法中引入了分布式事务控制注解@MiloTCC。我们先来了解一下@MiloTCC这个注解，它定义在milo-core模块的com.luke.milo.core.annotation包里面。

@MiloTCC注解定义了作用目标在方法上，指明了需要填充事务方法对应的confirm方法和cancel方法，并且对应的方法需要具备幂等性，从这里我们也可以看出来这种是分布式事务中典型的TCC解决方案。

回到刚才的方法中，下单过程更新订单状态为支付中，接着就是扣减库存，扣减账户余额，整个过程成功后会调用@MiloTCC注解定义的confirm属性对应的方法paymentConfirm

失败就会调用@MiloTCC注解定义的cancel属性对应的方法paymentCancel

这里要注意一点就是发起远程调用的AccountInter和StockInter接口方法中，发起在分布式事务Try阶段的方法都需要添加@MiloTCC注解，而查询方法则不需要。


对于Milo框架来说Try阶段的执行过程是由一个个参与者构成的，参与者是Milo框架一个非常重要的概念，又被称为TCC角色。

框架定义了事务角色有三个（嵌套者暂时没有用到），分别是INITATOR发起者、CONSUMER消费者和PROVIDER提供者，这里我们需要知道的就是下单的Try阶段是由三个参与者组成，分别是PaymentService的payment方法、StockInter的decreaseStock方法和AccountInter的decreaseAccount方法。这其中payment方法是整个TCC事务的发起方又被成为INITATOR发起者，decreaseStock方法和decreaseAccount方法被称为CONSUMER消费者，被发起者调用的远程方法被成为消费者，而对应的库存服务和账户服务的feign接口方法实现方，被称为PROVIDER提供者。具体的含义作用后面会详细介绍。

对应的账户服务提供者方法


对应的库存服务提供者方法


我们对应的提供者也需要引入@MiloTCC框架，并且需要指定confirm方法和cancel方法。可以看到虽然项目引入TCC框架很简单，使用一个注解即可，但是对应的try阶段参与者都需要实现对应的confirm方法和cancel方法并保证其幂等性，开发成本相对于其他分布式解决方案例如消息最终一致性来说是较高的。另一方面TCC模式下的分布式事务又是实时性较高的，所以使用哪种模式下的分布式事务完全取决于业务需要。

执行测试样例

从上面的分析我们已经知道了整个下单业务样例，现在我们就将样例运行起来并发送一个下单请求。将cloud-order、cloud-account、cloud-stock和注册中心cloud-eureka跑起来，然后用postman发起一个下单请求

请求前的账户数据、库存数据和订单数据

发起一个下单请求

请求后的账户数据、库存数据和订单数据



整个下单过程完成，账户和库存扣减成功，生成支付状态已完成的订单，并且数据一致。我们还可以从项目Console界面看到大量的Milo日志，这些日志将在后面帮助我们更好的解析整个框架背后到底做了些什么控制操作。

我的公众号