少有人走的路勇哥注：
SOA的源起，就是解决企业系统的架构重构，避免信息孤岛，以及提高服务负载应对企业的业务发展需求。
这个过程就涉及到了分布式应用。
最早的是单体架构
特点是：电商UI和订单等5个业务逻辑模块都是属于同一个项目的。
业务增长后，数据库开始扩容，每个业务模块对应一个数据库
当用户通过UI下单后，5个模块都得操作各自的数据库一次。
现在改为SOA，面向服务架构
５个模块都以服务方式提供，它们可以在同一电脑，也可以在不同的电脑上。
但是５个模块服务各自都有自己不同的操作系统平台，以及自己的技术栈。
怎么样能让５个服务的调用编一接口呢？
方法是使用数据总线（也称为网关）
UI层只需要调用数据总线即可。
最底层的“日志系统”等是所有服务模块公用的，也称为支撑系统。
企业的系统往往先是简单达到当前阶段的需求，但随着业务量的增加，系统出现了瓶颈，才会考虑系统增容。
当还是一家小公司的时候，可能只有一个账务系统和订单系统，然后再慢慢增加刚需的其它模块。
随着时间的推移，这些模块间你中有我，我中有你，形成了混乱的强偶合关系。
这是企业系统常见的一种历史包袱。
解决这个问题并不是要抛弃掉旧有系统然后重新来过，这个是不可能的。
我们可以通过SOA来做系统架构的重构
下面通过SOA把系统架构进行了升级，这个过程就是做了资源整合
这样整合后带来的另一个好处是，把服务模块分布在不同的服务器上，提升了系统总体的承载能力。
下面谈一下数据总线：
数据总线就是一种分布式框架：
常见的有：dubbo，zookeeper，DNS 在微服务里，数据总线也被称为网关
如下图所示。
总线的基本作用：
服务会先将自己注册到数据总线
假设客户客户端client1要访问用户服务，于是它向数据总线请求
数据总线会把请求到两台服务器其中的一个上去。
这个时候数据总线把服务请求做了路由转发。
DTC
通过服务总线还可以进行事务调用。
假设client1做了一次事务调用，这个事务包含３个步骤，总线会将它拆成对service1, service2,service3顺序进行调用
这３次调用要么全部成功，要么全部失败。
如果调用Service1成功了，但是调用Service2失败了，是不允许回退的。
（如果使用的服务器全部是windows服务器并且在同一个域内，还是可以使用DTC功能回退的，
它是操作系统的一个功能，任何一个服务操作失败，会把事务中所有服务器操作退回）
事务补偿
事务补偿则是另一种操作回退
假设一个事务有两步，1.把Services1某个变量由2变1 2. 对service2做个操作
第一步成功把2变1，但是执行第二步时失败了，此时因为设置了正命令与反命令，系统会回到第一步执行反命令
再把1变成2，也就是把值恢复到原来的值，相当于没有修改。
如果把services1退回去的过程也失败了，就只能找人工介入了。
事务补偿要求数据改了后能修改回来，并不是所有情况都能适用的。（例如发邮件，发出去就无法撤回了）
异步队列
分步式事务，另一种主流做法是异步队列
假设一个事务有三步。
系统先执行第一步，如果成功，则把第二步放进队列，如果失败，则重新把这一步放回队列再次执行。
错误可以重试次数，如果最终失败则转人工介入。
异步队列性能优秀，并且是数据是安全可靠不会丢失的。
总结一下分布式事务的三个方面：
1 DTC TransactionScope
2 事务补偿 命令，正命令反命令
3 异步队列
相关的扩展阅读：
ESB（企业服务总线）相关知识点总结
企业数据总线(ESB)和注册服务管理(dubbo)的区别
微软对应的ESB产品是：BizTalk Server
