事务一致性
事务一致性的问题在Monolithic下面不是大问题，在微服务下面却是很致命，我们回顾一下所谓的ACID原则
Atomicity – 原子性，改变数据状态要么是一起完成，要么一起失败
Consistency – 一致性，数据的状态是完整一致的
Isolation – 隔离线，即使有并发事务，互相之间也不影响
Durability – 持久性， 一旦事务提交，不可撤销
在单体服务和关系型数据库的时候，我们很容易通过数据库的特性去完成ACID。但是一旦你按照DDD拆分聚合根-微服务架构，他们的数据库就已经分离开了，你就要独立面对分布式事务，要在自己的代码里面满足ACID。
对于分布式事务，大家一般会想到以前的JTA标准，2PC两段式提交。我记得当年在Dubbo群里面，基本每周都会有人询问Dubbo啥时候支撑分布式事务。实际上根据分布式系统中CAP原则，当P(分区容忍)发生的时候，强行追求C（一致性），会导致（A）可用性、吞吐量下降，此时我们一般用最终一致性来保证我们系统的AP能力。当然不是说放弃C，而是在一般情况下CAP都能保证，在发生分区的情况下，我们可以通过最终一致性来保证数据一致。
例：
在电商业务的下订单冻结库存场景。需要根据库存情况确定订单是否成交。
假设你已经采用了分布式系统，这里订单模块和库存模块是两个服务，分别拥有自己的存储（关系型数据库），
