使用华为servicecomb-pack框架实现协调器以处理分布式事务

记录一下公司开发社区讲解的有关微服务中分布式事务

对于我而言还是有点难以理解的。学习中。

微服务倡导将复杂的单体应用拆分为若干个功能简单、松耦合的服务，这样可以降低开发难度、增强扩展性、便于敏捷开发，从而被越来越多的开发者和公司推崇运用。但系统微服务化后，一个看似简单的功能，内部可能需要调用多个服务并操作多个数据库实现，服务调用的分布式事务问题变的非常突出，几乎可以说是无法避免。分布式事务已经成为微服务落地最大的阻碍，也是最具挑战性的一个技术难题。那么我们在实际开发中需要如何去应对呢？本文就介绍在实际微服务开发中分布式事务的实战。

事务原理

先看一下图片:

事务是数据库管理系统执行过程中的一个逻辑单元，它能保证要么一组数据库操作全部执行成功，要么全部失败，而做到这些的原理就是事务的ACID四大特性。
A. Atomic原子性的简称，事务作为一个整体来执行，要么全部成功，要么全部失败。
C. Consistency一致性的简称，事务应确保数据从一个一致的状态转变为另一个一致的状态。
I.  Isolation隔离性的简称，多个事务并发执行时，一个事务的执行不影响其他事务的执行。
D．Durability持久性的检查，已提交的事务修改数据会被持久保存。

传统单机数据库事务

在传统单体应用架构中，我们的业务数据通常都是存储在一个数据库中的，应用中的各个模块对数据库直接进行操作。在这种场景中，事务是由数据库提供的基于ACID特性来保证的。
例如，在一个用户购物下单的场景中，涉及到用户、订单、支付、库存等模块的一系列协同操作，如果其中一个模块出现问题，我们就可以通过数据库提供的事务特性来保证本次下单操作要么都成功，要么都失败。因为这些模块用的是同一个数据库，所处的是同一个事务管理器，不需要做额外的其他操作就能保证事务的特性

	从广义上来讲，分布式事务其实也是事务，只是区别于单机事务不同之处是：由于业务上的定义和系统微服务架构的设计，很多大型的业务流程都被拆分成了多个单一的基础服务，而为了保证每个微服务都能独立进行开发和部署运行，通常都会采用一个微服务一个数据库的架构配套，然后将内部服务进行封装，以Rest api方式对外暴露。
	这样以往基于数据库来实现的数据操作，就变成了多个对外提供微服务的微服务系统之间的协同操作。在这种情况下，原有的单机事务方式已经不能够使用了，因为多个服务就意味着存在多个事务管理器和多个资源，单个微服务的本地事务管理器只能保证本地事务的ACID，为了在多个服务之间能保证业务的事务性，参与分布式事务的微服务通常会依托协调器来完成相关的一致性协调操作。
那我们在微服务系统实际开发中，如何去实现协调器以处理分布式事务呢，这里的解决方案是采用华为提供的servicecomb-pack框架来解决这一问题。
servicecomb-pack出自于华为微服务框架servicecomb，是一个开源的分布式事务最终一致性解决方案，该项目已交由Apache软件基金会孵化，目前已经在apache毕业了。0.3.0版本之前叫service