2. 微做事系统是分布式系统，业务与业务之间完备解耦，随着业务的增加可以根据业务再拆分，具有极强的横向扩展能力。
3. 做事间采取 HTTP 协议通信，做事与做事之间完备独立。每个做事可以根据业务场景选取得当的编程措辞和数据库。
4. 做事独立支配，每个做事的修正和支配对其他做事没有影响。
虽然微做事有以上的上风，但是微做事实践仍处于探索阶段，很多中小型互联网公司，鉴于履历、技能实力等问题，微做事落地比较困难。著名架构师Chris Richardson指出，目前微做事紧张存如下几方面困难：
1. 单体运用拆分为分布式系统后，进程间的通讯机制和故障处理方法变的更加繁芜。
2. 系统微做事化后，一个看似大略的功能，内部可能须要调用多个做事并操作多个数据库实现，做事调用的分布式事务问题变的非常突出。
3. 微做事数量浩瀚，其测试、支配、监控等都变的更加困难。
随着RPC框架的成熟，第一个问题已经逐渐得到办理。例如Dubbo可以支持多种通讯协议，Spring Cloud可以非常好的支持restful调用。对付第三个问题，随着Docker、DevOps技能的发展以及各公有云PaaS平台自动化运维工具的推出，微做事的测试、支配与运维会变得越来越随意马虎。
而对付第二个问题，现在还没有通用方案很好的办理微做事产生的事务问题。分布式事务已经成为微做事落地最大的阻碍，也是最具寻衅性的一个技能难题。下面将深入和大家磋商微做事架构下，分布式事务的各种办理方案。
微做事架构下，如何战胜分布式事务难题？什么是事务事务是由一组SQL语句组成的逻辑处理单元，事务具有以下4个属性，常日简称为事务的ACID属性：
原子性（Atomicity）：事务是一个原子操作单元，其对数据的修正，要么全都实行，要么全都不实行。
同等性（Consistent）：在事务开始和完成时，数据都必须保持同等状态。这意味着所有干系的数据规则都必须运用于事务的修正，以保持数据的完全性。
隔离性（Isolation）：数据库系统供应一定的隔离机制，担保事务在不受外部并发操作影响的“独立”环境实行。数据库事务隔离级别由低到高依次为Read uncommitted、Read committed、Repeatable 、Serializable。
持久性（Durability）：事务完成之后，它对付数据的修恰是永久性的，纵然涌现系统故障也能够保持。
分布式事务范例场景：银行转账业务是一个范例分布式事务场景，常日包括以下三种情形：
A. 支行内转账：同一银行的相同支行内转账
B. 行内转账：同一银行的不同支行间转账
C. 跨行转账：不同银行的系统进行转账
对付传统集中式架构，A、B常日为本地事务，C为分布式事务。业务微做事改造后，转入、转出常日为不同的微做事，同一个微做事也常日运行于不同实例中。A可能变成一个分布式事务，也可能通过一些方法规避，在本地事务内完成。B和C很难规避，只能是分布式事务。
微做事最佳实践建议只管即便规避分布式事务，但是在很多业务场景（比如上面的B、C转账场景），分布式事务是一个绕不开的技能问题。
分布式事务常用办理方案为理解决分布式系统同等性问题，古人在性能和数据同等性的反反复复权衡过程中总结了许多范例的协议和算法。个中，最常用的是两阶提交协议（2 Phase Commitment Protocol）。
两阶段提交方案交易中间件与数据库通过 XA 接口规范，利用两阶段提交来完成一个全局事务， XA 规范的根本是两阶段提交协议。
第一阶段是表决阶段，所有参与者都将本事务能否成功的信息反馈发给折衷者；第二阶段是实行阶段，折衷者根据所有参与者的反馈，关照所有参与者，步调同等地在所有分支上提交或者回滚。
两阶段提交方案运用非常广泛，范例商用软件包括Oracle Tuxedo和IBM CICS。它的优点是对业务代码侵入较低，但缺陷也很明显：
性能低下：由于 XA 协议自身的特点，它会造成事务资源永劫光得不到开释，锁定周期长，而且在运用层上面无法干预，数据并发冲突高的场景性能很差。
单点问题：折衷者在全体两阶段提交过程中扮演着举足轻重的浸染，一旦折衷者所在做事器宕机，就会影响全体数据库集群的正常运行。比如在第二阶段中，如果折衷者由于故障不能正常发送事务提交或回滚关照，那么参与者们将一贯处于壅塞状态。
同步壅塞：两阶段提交实行过程中，所有的参与者都须要屈服折衷者的统一调度，期间处于壅塞状态而不能从事其他操作，效率及其低下。
因此，两阶段提交方案在互联网业务中很少利用，无法知足高并发需求。
为了这个填补这种方案带来性能低的问题，大家又想出了很多种方案来办理，通过在运用层做文章，即入侵业务的办法，比较范例的是TCC 方案和基于可靠的终极同等性方案。
TCC事务方案TCC事务模型在电商、金融领域落地较多。TCC方案实在是两阶段提交的一种改进。其将全体业务逻辑的每个分支显式的分成了Try、Confirm、Cancel三个操作。Try部分完成业务的准备事情，confirm部分完成业务的提交，cancel部分完成事务的回滚。基本事理如下图所示。
事务开始时，业务运用会向事务折衷器注册启动事务。之后业务运用会调用所有做事的try接口，完成一阶段准备。之后事务折衷器会根据try接口返回情形，决定调用confirm接口或者cancel接口。如果接口调用失落败，会进行重试。
TCC方案让运用自己定义数据库操作的粒度，使得降落锁冲突、提高吞吐量成为可能，比如华为分布式事务中间件DTM性能极高，普通配置做事器可以支持全局事务1万+ TPS，分支事务3万+ TPS。 当然TCC方案也有不敷之处，集中表现在以下两个方面：
业务侵入性强。业务逻辑的每个分支都须要实现try、confirm、cancel三个操作，运用侵入性较强，改造本钱高。
实现难度较大。为了知足同等性的哀求，要充分考虑幂等操作，许可重复实行，也要防止资源悬挂，做好并发访问掌握和数据可见性掌握等。
上述缘故原由导致TCC方案大多被研发实力较强、有急迫需求的大公司所采取。微做事倡导做事的轻量化，而TCC方案中很多事务的处理逻辑须要运用自己编码实现，繁芜且开拓量大。
基于的终极同等性方案同等性方案是通过中间件担保高下游运用数据操作的同等性。基本思路是将本地操作和发送放在一个本地事务中，担保本地操作和发送要么两者都成功或者都失落败。下贱运用向系统订阅该，收到后实行相应操作。
终极同等方案从实质上讲是将分布式事务转换为两个本地事务，然后依赖下贱业务的重试机制达到终极同等性。基于的终极同等性方案对运用侵入性也很高，运用须要进行大量业务改造，本钱非常高。
入侵代码的方案是基于现有环境“迫不得已”才推出的办理方案，实际上它们实现起来非常不优雅，比如TCC，一个事务的调用常日伴随而来的是对该事务接口增加一系列的反向操作，提交逻辑一定伴随着回滚的逻辑，这样的代码会使得项目非常臃肿，掩护本钱高。
针对上面所说的分布式事务办理方案的痛点，很显然，我们空想的分布式事务办理方案肯定是性能要好而且要对业务无侵入，业务层无需关心分布式事务机制的约束，做到事务与业务分离，也便是本文所重点推举的非侵入事务。
非侵入事务方案a. 范例架构非侵入事务范例架构如下图所示：
事务核心组件包括：
Transaction Coordinator (TC)： 事务折衷器，分布式事务大脑，产生和掩护全局事务、分支事务，推进事务提交与回滚的二阶段处理。TC Server以集议论势供应事务折衷能力。
Transaction Manager (TM)： 定义全局事务的边界，与事务折衷器通信以开启、提交或回滚全局事务。
Resource Manager (RM)： 资源管理器，管理分支事务处理的资源，与事务折衷器通信以开启、结束事务分支，并吸收事务折衷器指令完成二阶段分支事务提交或回滚。
Lock Server （LS）： 分布式锁做事器，可以通过它对进行中的分布式事务所操作的资源查询、加锁、放锁。
一个分布式事务称为一个全局事务，下面挂多少个分支事务，一个分支事务是一个知足 ACID 确当地事务。非侵入事务的核心思想是资源管理器拦截业务SQL，对其解析并做额外的一些数据处理，产生undo log并保存，一旦发生全局事务回滚，通过各个分支事务对应的undo log完成所有分支事务回滚。
大家很随意马虎想到，两个全局事务并行修正了相同数据，可能会造成根据undo log完成回滚产生数据缺点。办理的方法是通过Lock Server对事务所修正数据加锁，全局事务提交后立即放锁，全局事务回滚则等待分支事务回滚完成放锁。
b. 范例流程范例分布式事务紧张实行步骤如下：
1. TM要求TC开始新的全局事务，TC创建全局事务并返回全局事务ID（XID）。
2. 根据XID构建事务高下文，通过微做事的调用链传播。
3. RM创造自己处于事务高下文，得到全局事务ID并解析SQL，产生undo log和分布式事务锁数据，要求TC创建分支事务。
4. TC 通过LS加锁，加锁成功后创建分支事务ID并返回。
5. RM 把分支事务ID与undo log关联，与业务原始SQL在一个本地事务内提交。
6. 重复3~5，为全局事务范围内的每个本地事务创建一个分支事务。
7. 如果全局事务边界内没有任何非常，则TM要求TC提交全局事务；如果有非常，则TM要求TC回滚全局事务。
8. TC标记全局事务状态，如果为提交则立即通过LS放锁。推进XID所对应全局事务下的所有分支事务进行二阶段处理，发送要求到RM。
9. RM完身分支事务的提交或回滚，并返回状态到TC。
10. TC对完成回滚的分支通过LS放锁。所有分支完成后，返回全局事务处理结果到TM。
二阶段事务处理比较关键，在此重点解释一下。
c. 分支事务提交如果全局事务状态为提交，则对每个分支发起分支提交，流程如下图所示：
RM收到分支事务提交要求，先保存分支事务的ID在行列步队中并返回。一个线程定时从行列步队中取出一批分支事务ID，构建SQL批量删除所对应的undo log日志。分支事务提交可以异步批量处理，是由于全局事务已经提交，undo log作为中间状态已经不再主要，只要定期清理即可。
d. 分支事务回滚如果全局事务状态为回滚或超时，则对每个分支发起分支回滚，流程如下图所示：
RM收到分支事务回滚要求，开启一个本地事务，通过分支ID找到对应的undo log，构建回滚SQL语句并实行，删除undo log，然后提交本地事务。如果顺利完成，TC收到相应后通过LS清理该分支所占用资源。
e. 性能剖析非侵入事务比较XA两阶段提交一个主要性能上风在于锁定资源韶光更短。实际业务中，我们知道绝大多数事务状态为提交，很少比例为回滚。对付XA来说，无论是提交还是回滚，资源都是在二阶段开释。对本文所先容的非侵入事务来说，提交状态的全局事务，二阶段没有必要拿锁，只有少比例的回滚状态的全局事务，才须要在二阶段放锁。
非侵入事务不受限于数据库XA接口，实现完备可控。TC、RM、LS这些关键组件对性能影响很大，良好的设计、实现可以取得非常高的性能。非侵入式事务实践证明，它可以轻松知足绝大多数高并发业务场景的性能需求。
范例核心业务系统分布式事务改造实例华为云Stack为某运营商核心业务系统分布式事务改造，该客户业务在月初充值、扣费业务高峰期等常见的并发场景时，对分布式系统提出寻衅：
高并发的分布式事务访问账户表，XA两阶段提交由于加锁韶光长，严重影响业务。整体性能哀求达1000+ TPS，传统或开源分布式事务难以知足高可用性与高性能哀求。XA事务与其他数据库操作的同等性问题。须要把XA事务作为DTM TCC事务的一个分支，将别的数据库操作是其余的分支。华为云Stack稠浊云办理方案分布式事务中间件DTM通过一系列创新技能，供应高性能、高可用、高可靠、高安全、低侵入、易利用的分布式事务做事，支持TCC事务和非侵入事务两种模型，助力企业微做事化改造，优雅地办理分布式系统下数据同等性难题。
