前言
今天写篇文章讨论下传统ESB和主流分布式服务框架的差异和自己对他们的思考，也为大家对不同服务框架的选型提供一些建议。10多年前SOA的理念已经在业界非常风行，其中以传统软件厂商提出的以ESB实现SOA的方案为主流，这也是为什么几乎所有传统企业的客户都认为ESB是SOA理念的最佳实践，甚至是唯一的实现，这是一种"中心化"服务框架。
随着互联网架构和技术的普及，很多人都已经对互联网公司的典型架构和技术有了比较多的了解，其中在服务化框架领域，互联网公司流行一种去中心化的服务框架，本章将从理论和实战的角度对这两种架构进行对比。
之前，有一部分人认为"去中心化"不是SOA架构，为此我们一起回顾下SOA的主要特性：
- 面向服务的分布式计算
- 服务间松散耦合
- 支持服务的组装
- 服务注册和自动发现
- 以服务契约方式定义服务交互方式
可以看到，SOA并没有定义出一定是基于ESB总线的方式，而在互联网行业中兴起的"去中心化"分布式服务框架同样遵循了以上对SOA架构的特征定义。所以接下来讨论的"中心化"和"去中心化"服务框架均是SOA的实现方式，并不是两套体系。
首先我想表达的观点是，这两套SOA的架构并没有优劣之分，很多互联网公司最终选择"去中心化"服务架构作为整个公司统一的服务框架并不代表"去中心化"服务框架是"中心化"服务框架的升级版，而基于这两套架构解决企业的根本诉求是完全不同的.
ESB模式的"中心化"服务架构的根本诉求
回顾2004年左右业界提出SOA理念的背景，正是大型软件公司已经发现，越来越多的企业在多年的IT建设过程中，逐渐构建了越来越多的IT系统，这些IT系统无不例外都是采用"烟囱式"系统建设模式而建立的，使得企业内的各种系统纷繁林立，这些系统有的是购买商用套件，有的是自主研发，有的是找外部的行业解决方案提供商基于需求定制开发，最终的结果就是各个系统所采用技术平台、框架、开发语言各异。
随着企业业务的发展，需要实现这些系统间交互时，SOA的架构相比通过系统间点对点直接互通的模式，很好的避免了因为服务提供者服务接口的变化需要调整此服务的服务调用者都进行修改的现象，而只需在ESB上进行一次调整，便实现了对服务接口变化带来影响的隔离。ESB架构降低了系统间的耦合，更方便、高效地实现了对新系统的集成，同时也在服务负载均衡、服务管控等方面提供了相比点对点模式更专业的能力。
所以当SOA理念一提出，得到了企业客户的一致青睐，希望通过SOA项目实现各系统间更有效的互联互通。在这样需求的驱动下，各大软件厂商纷纷推出了自己的SOA产品，无一例外均是使用了ESB方式。在ESB这样一个中心服务总线上，提供了诸如对各种技术接口（httpsocket、jms、jdbc等）的适配接入、数据格式转换、数据裁剪、服务请求路由等功能。核心目的是让企业客户能基于这些SOA的产品实现系统间的互联互通，同时提高开发集成效率，更快地实现SOA项目的落地。
所以，在这样一个需求背景下，ESB的方式成为这一时期SOA实现的主流，而这一种架构解决的根本诉求是实现易构系统之间的交互。
"去中心化"分布式服务架构解决的问题
互联网行业中发源的"去中心化"服务框架是由互联网业务的特性决定的，因为用户群体是整个互联网公众，所以系统架构设计人员首先要解决的事系统扩展性问题，然后才是更快地进行业务响应、更好地支持业务创新等。一个互联网平台的业务发展的再好，一旦有更多的用户访问后，这个平台如果没法再进行扩展的话，这将给平台带来灾难性的后果。这就是为什么今天几乎所有互联网公司均基于"去中心化"分布式服务框架建设系统，其根本原因就在于扩展性是首要的。
所以"去中心化"分布式服务框架除了对于SOA特性的实现和满足外，相比"中心化"服务架构最重要的不同就是服务提供者和服务调用者之间在进行服务交互时无需通过任何服务路由中介，避免因为"中心点"带来平台能力难以扩展问题，以及潜在的"雪崩"影响。而对于不同技术接口的支持、数据格式转换、服务动态路由等功能就没有在"去中心化"的平台中有所体现，更多情况是依靠服务应用的编写来满足这样的需求。
也有人提出这样的疑问，"去中心化"的服务交互方式很像IT技术发展早期通过系统间"点对点"打通的方式实现不同系统间的集成，ESB的出现很好的解决了这种系统集成带来的各种弊端，新的"去中心化"服务框架在某种程度上是否是一种倒退？其实忽略了"去中心化"服务框架一般是运行在企业内部网络，基于统一的技术接口和标准、网络协议、规范进行交互，已使服务的交互效率最高，又因为是以服务契约先行的方式进行了服务接口功能的约定，在某种程度上很好的保障了服务接口和稳定性，所以大大降低了服务接口和稳定性，所以大大降低了因为服务接口发生变化给服务调用者带来的影响；同时"去中心化"服务框架中辅以多版本支持、负载均衡的支持，从本质上屏蔽掉了之前"点对点"模式下的各种系统稳定性问题。
那么为什么"中心化"服务框架不适合于互联网场景呢？接下来我们抛开两种架构所提供的平台功能，仅从当企业的业务进行了服务化之后，两种架构给业务带来的影响进行对比。
- 服务调用方式的不同带来业务的响应和扩展成本
传统ESB的服务调用方式是，每一次服务的调用者要向服务提供者进行服务交互请求时都必须通过中心的ESB来进行路由。
每一次服务交互的线路都需要5步，有4次网络通讯：
服务调用者-> ESB接受服务请求->服务提供者（服务处理） ->ESB返回结果->服务调用者接受服务返回
经过服务总线路由过的服务交互，共出现4次网络会话创建和数据传输，而"去中心化"服务架构中服务交互，一次服务的调用只有两次网络会话创建和数据传输，在网络上的开销整整减少了一半。
当整个平台或企业内的应用都是基于服务化架构建设的时候，一次网页上的点击请求就不会像之前那样，所有的代码逻辑都在一个应用实例中就能完全处理，而需要通过调用多个远程的服务来完成整个业务请求的处理。例如在京东页面点击立即下单按钮进行下单请求时，后段调用了200多个服务，也就是一次页面的请求产生了后段上百个不同服务器间的服务交互。如果是总线架构，每次请求逗逼直接交互的方式要多一倍的网络开销，那么我们就很难体验到毫秒级的创建订单。
从逻辑上看，所有服务调用都通过服务总线，服务总线的访问和计算压力都会非常大。所有的企业服务总线产品也都可采用集群部署的方式进行压力的分担，实现服务路由能力的线性扩展，因为一般企业服务总线包含的功能非常多，比如服务发现、注册、路由、协议转换、接口监听等功能，使得企业服务总线一般对服务器的要求都比较高，所以每一次企业服务总线的扩容升级都会带来在软件授权和硬件资源上不小的投入。
另一方面，企业所有的业务都是通过服务总线的方式，则服务调用量比较大，所需的网络带宽要求非常高，甚至会出现超过目前网络设备的能力范围，企业需要在网络上投入更大的成本。如果按如今大型互联网公司每天高达上千亿次的服务调用，采用服务总线的方式，那在网络设备上的资源投入将会是一个天文数字。
- 雪崩效应束缚了中心化服务框架的扩展能力
上面只是从用户体验、平台扩展性和网络成本来讨论"去中心化"相比于"中心化"服务框架的优势，但这海不是今天很多企业客户或互联网企业不选择"中心化"服务框架的最重要原因，根本原因则是"中心化"架构可能给平台带来灾难性的雪崩效应。
基于企业服务总线构建的服务体系，会成为企业服务调度的核心枢纽，当前很多企业还指示将企业服务总线用于企业内部系统间的互联，但随着互联网转型浪潮的到来，会有越来越多的业务是面向互联网公众的。简单说，不管是因为企业业务规模自身的发展还是外部环境的变化，一旦有更多的服务调用和交互的场景，传统企业服务总线的架构就暴露出"硬伤"。
更多的服务调用给企业服务总线带来了更多的服务路由压力，这时必然会采用集群部署的方式，对这些服务请求提供负载均衡和高可用性的保障。但是在这个表面看来万无一失的架构中，却隐藏着巨大的风险。
假设安服务访问的峰值估算出了所需的企业服务总线的集群数量约是10台。当达到访问峰值时，每个企业服务总线的负载将会达到80%以上。日常运行没问题，但是当突发交易峰值或有可能因为一个应用对某个服务产生了不规范调用或者是有问题的服务提供者造成服务所在的企业服务总线实例节点出现异常，就有可能是一台服务器故障。这就会导致服务路由压力落在了剩下的9台服务器上，这样每台机器分担的压力很有可能超过最大负载，导致其他机器出现连锁崩溃的概率大增，这时就不会一台台出问题，而是会一起被冲垮，整个企业服务总线集群全军覆没，这就是典型的雪崩。
而企业服务总线一旦遇到上面这样的集群瘫痪后，故障恢复是很麻烦，花费的时间也很漫长，让10台服务器全部重启起来，起码要花费半个小时以上。而"去中心化”的服务框架则可以避免因为个别问题波及整个平台的业务受影响，最多也就是部分服务出现问题，就算出现问题时也更容易定位问题和故障恢复。
总结
综上所述，正因为雪崩效应的隐患存在，在某种程度上其实是束缚了"中心化"服务框架的平台扩展能力，也就是行锁增加"中心"点企业服务总线的实例等节点数量，并不能线性扩展平台的服务能力。正因为如此，目前很多互联网公司都选择"去中心化"的服务框架作为平台分布式服务框架。目前主流的springcloud套件和dubbo+zk就是大家目前用的比较多的分布式服务框架，这篇文章详细的讲解了下ESB和分布式服务分别适用的场景和解决的问题，大家可以按照这样的标准去选择适合自己公司的服务框架。
