3.2　“中心化”与“去中心化”服务框架的对比

当年淘宝技术团队在进行架构改造设计时，就确定了目标：这次选择的架构路线必须能满足接下来至少10年内集团业务发展的要求，即10年内无需再进行这样“兴师动众”的底层架构改造。虽然淘宝在1年多的时间内很好地完成了这样一个任务，但集团投入的资源和成本其实是非常巨大的，甚至在特定的时间段内也停止了应用对前端业务新需求的响应。整个工程能够成功实施，除了解决技术上的难度和风险，还经过技术团队和业务团队的通力配合，更重要的是集团领导的全力支持。总而言之，这是一件非常艰巨、困难重重、充满风险的事情，这个过程是任何一家公司都不愿意再次经历的。

正因为大家都意识到这件事对于集团长远发展的重要意义，对于此次服务化改造平台的选择则尤为慎重。当时SOA的理念已经在业界非常风行，其中以传统软件厂商提出的以ESB（企业服务总线）实现SOA的方案为主流，这也是为什么几乎所有传统企业的客户都认为ESB是SOA理念的最佳实践，甚至是唯一的实现。这是一种“中心化”服务框架。

随着互联网架构和技术的普及，很多人都已经对互联网公司的典型架构和技术有了较多的了解，其中在服务化框架领域，互联网公司流行一种“去中心化”的服务框架，本章将从理论和实战的角度对这两种架构进行对比。

之前，有一部分人认为“去中心化”不是SOA架构，为此我们一起简单回顾一下SOA的主要特性：

·面向服务的分布式计算。

·服务间松散耦合。

·支持服务的组装。

·服务注册和自动发现。

·以服务契约方式定义服务交互方式。

可以看到，SOA并没有定义出一定是基于ESB总线的方式，而在互联网行业中兴起的“去中心化”分布式服务框架同样遵循了以上对SOA架构的特征定义。所以接下来讨论的“中心化”和“去中心化”服务框架均是SOA的实现，并不是两套体系。

首先我想表达的观点是，这两套SOA的架构并没有优劣之分，淘宝最终选择“去中心化”服务架构作为整个集团统一的服务框架并不代表着“去中心化”服务框架是“中心化”服务框架的升级版本，而基于这两套架构解决企业的根本诉求是完全不同的。

1）ESB模式的“中心化”服务架构的根本诉求。回顾2004年左右业界提出SOA理念的背景，正是大型软件公司已经发现，越来越多的企业在多年的IT建设过程中，逐渐构建了越来越多的IT系统，这些IT系统无不例外都是采用“烟囱式”系统建设模式而建立的，使得企业内的各种系统纷繁林立，这些系统有的是购买商用套件，有的是自主研发，有的是找外部的行业解决方案提供商基于需求定制开发，最终的结果就是各个系统所采用技术平台、框架、开发语言各异。

随着企业业务的发展，需要实现这些系统间交互时，SOA的架构相比通过系统间“点对点”直接互通的模式，很好地避免了因为服务提供者服务接口的变化需要调用此服务的服务调用者都进行修改的现象，而只需在ESB上进行一次调整，便实现了对服务接口变化带来影响的隔离。ESB架构降低了系统间的耦合，更方便、高效地实现了对新系统的集成，同时也在服务负载均衡、服务管控等方面提供了相比“点对点”模式更专业的能力。

所以当SOA的理念一提出，得到了企业客户的一致青睐，希望通过SOA项目实现各系统间更有效的互联互通。在这样需求的驱动下，各大软件厂商纷纷推出了自己的SOA产品，无一例外均是使用了ESB方式。在ESB这样一个中心服务总线上，提供了诸如对各种技术接口（HTTP、Socket、JMS、JDBC等）的适配接入、数据格式转换、数据裁剪、服务请求路由等功能。核心目的是让企业客户能基于这些SOA的产品实现系统间的互联互通，同时提高开发集成效率，更快地实现SOA项目的落地。

所以，在这样一个需求背景下，ESB的方式成为这一时期SOA实现的主流，而这一种架构解决的根本诉求是实现异构系统之间的交互。

2）“去中心化”分布式服务架构解决的问题。互联网行业中发源的“去中心化”服务框架是由互联网业务的特性决定的，因为用户群体是整个互联网公众，所以系统架构设计人员首先要解决的是系统扩展性的问题，然后才是更快地进行业务响应、更好地支持业务创新等。一个互联网平台的业务发展得再好，一旦有更多的用户访问后，这个平台如果没法再进行扩展的话，这将给平台带来灾难性的后果。这就是为什么今天几乎所有互联网公司均基于“去中心化”分布式服务框架建设系统，其根本原因就在于扩展性是首要的。

所以“去中心化”分布式服务框架除了对于SOA特性的实现和满足外，相比“中心化”服务架构最重要的不同就是服务提供者和服务调用者之间在进行服务交互时无需通过任何服务路由中介，避免因为“中心点”带来平台能力难扩展问题，以及潜在的“雪崩”影响（这两点在后面会详细说明）。而对于不同技术接口的支持、数据格式转换、服务动态路由等功能就没有在“去中心化”的平台中有所体现，更多情况是依靠服务应用的编写来满足这样的需求。

也有人提出这样的疑问：“去中心化”的服务交互方式很像IT技术发展早期通过系统间“点对点”打通的方式实现不同系统间的集成，ESB的出现很好地解决了这种系统集成带来的各种弊端，新的“去中心化”服务框架在某种程度上是否是一种倒退？其实忽略了“去中心化”服务框架一般是运行在企业内部网络环境中（即不会出现跨内外网的服务交互），基于统一的技术接口标准、网络协议、规范进行交互，已使服务的交互效率最高，又因为是以服务契约先行的方式进行了服务接口功能的约定，在某种程度上很好地保障了服务接口和稳定性，所以大大降低了因为服务接口发生变化给服务调用者带来的影响；同时“去中心化”服务框架中辅以多版本支持、负载均衡的支持，从本质上屏蔽掉了之前“点对点”模式下的各种系统稳定性问题。更多关于“去中心化”服务框架的运行原理和主要特性将在下一节详细描述。

那么为什么“中心化”服务框架不适合于互联网场景呢？接下来我们抛开这两种架构所提供的平台功能，仅从当企业的业务进行了服务化之后，两种架构给业务带来的影响进行对比。

1.服务调用方式的不同带来业务的响应和扩展成本

传统ESB的服务调用方式是，每一次服务的调用者要向服务提供者进行服务交互请求时都必须通过中心的ESB来进行路由，如图3-3所示。

图3-3　传统企业服务总线下的服务交互方式

每一次服务交互的路线如下所示：

①服务调用者→②ESB（接受服务请求）→③服务提供者（服务处理）→④ESB（服务提供返回结果）→⑤服务调用者（服务返回）

经过服务总线路由过的服务交互，共出现4次网络会话创建和数据传输，而“去中心化”服务架构中服务交互，一次服务的调用只有两次网路会话创建和数据传输，在网络上的开销整整减少了一半，如图3-4所示。

图3-4　分布式服务架构中的服务交互方式

当整个平台或企业内的应用都是基于服务化架构建设的时候，一次网页上的点击请求就不会像之前那样，所有的代码逻辑都在一个应用实例中就能完全处理，而需要通过调用多个远程的服务来完成整个业务请求的处理。拿大家熟知的淘宝订单创建举例，在淘宝上点击“立即下单”或“结算”按钮进行下订单的请求时，后端调用了200多个服务，也就是一次页面的请求产生了后端上百台不同服务器间的服务交互。试想一下，如果是采用服务总线的方式，每次服务请求都比直接交互的方式有一倍的网络开销，那我们可能很难体验到平均在200～300毫秒就能看到订单创建成功的页面，如果用几秒，甚至更长时间创建订单，后果不堪设想。

从逻辑上看，所有服务调用都通过服务总线，服务总线的访问和计算压力都会非常大。所有的企业服务总线产品也都可采用集群部署的方式进行压力的分担，实现服务路由能力的线性扩展，因为一般企业服务总线包含的功能非常多，比如服务发现、注册、路由、协议转换、接口监听等功能，使得企业服务总线一般对服务器的要求都比较高，所以每一次企业服务总线的扩容升级都会带来在软件授权和硬件资源上的不小投入。

另外一点，企业所有的业务都是通过服务总线的方式，则服务调用量比较大，所需的网络带宽要求非常高，甚至会出现超过目前网络设备的能力范围，企业需要在网络上投入更大的成本。如果按如今淘宝每天达到几千亿次的服务调用，采用服务总线的方式，那在网络设备上的资源投入将会是一个天文数字。

2.“雪崩”效应束缚了“中心化”服务框架的扩展能力

上面只是从用户的体验、平台的扩展以及网络成本来讨论“去中心化”相比于“中心化”服务框架的优势，但这还不是今天很多企业客户或互联网企业不选择“中心化”服务框架的最重要原因，根本原因则是“中心化”架构可能给平台带来灾难性的“雪崩”效应。

基于企业服务总线构建的服务体系，会成为企业服务调度的核心枢纽，当前很多企业还只是将企业服务总线用于企业内部系统间的互联，但随着互联网转型浪潮的到来，会有越来越多的业务是面向互联网公众开放的，带来更多的服务调用和交互。简单说，不管是因为企业业务规模自身的发展还是外部环境的变化，一旦有更多的服务调用和交互的场景，传统企业服务总线的架构就暴露出“硬伤”。

更多的服务调用给企业服务总线带来了更多的服务路由压力，这时必然会采用集群部署的方式，对这些服务请求提供负载均衡和高可用性的保障。但是在这个表面看来万无一失的架构中，却隐藏着巨大的风险。

假设按服务访问的峰值（虽然在面向互联网的场景中，对于访问峰值其实是很难估算的，不经意间的某个事件可能带来意外的访问洪流）100估算出了所需的企业服务总线的集群数量是10台。当达到访问峰值时，每个企业服务总线的负载水位会达到80%。按照理论，日常运行中不会有太大的问题。但在现实世界中，当访问峰值来临时，有可能因为某一个应用对某个服务产生了不规范的服务调用，或有问题的服务提供造成服务所在的企业服务总线实例出现异常，也有可能是一台服务器的操作系统或硬件出现了故障，会导致10台企业服务总线的实例中有一台实例出现了问题，无法正常提供服务路由的能力。

此时，服务路由压力就落在了剩下的9台ESB服务器上，原本由出问题的那台服务器提供的服务路由职能就分摊到了剩下的9台上，每台的负载水位就超过88%，个别服务器可能更高（因为不能确保分摊的服务负载完全平均），在服务器处于高水位运行的时候，出现问题的概率会大增。

糟糕的事还是发生了，9台中的一台也因为不堪重负而“罢工”后，你会看到后面的8台服务器在访问峰值下就不是像之前一样一台一台出问题，而是在瞬间被访问洪流给冲垮，整个企业服务总线集群全军覆没。这就是典型的“雪崩”效应，因为一个小问题会给整个平台带来灾难性的后果。

而且企业服务总线架构一旦遇到上面所提到的“雪崩”事故后，故障恢复的时间和成本都非常高昂。因为传统的一台一台重启服务器已经不能进行故障的恢复，因为一旦服务启动起来，前端的访问洪流会立即再次压垮启动后的服务器，唯一正确的方式则是首先切断前端应用对企业服务总线的服务请求，让这10台服务器全部启动后，再开放服务请求，这样才能恢复系统的运行。但因为着急恢复系统，没有来得及定位之前造成开始服务实例出问题的根本原因，这样的系统恢复运行其实处于一个“脆弱”的状态，之前造成服务实例宕机的问题可能让“雪崩”事故再次上演。

而“去中心化”服务框架则可以避免因为个别问题波及整个平台的业务受影响，最多也只是部分服务出现问题，就算出现问题时也更容易定位问题和故障恢复。

综上所述，正因为“雪崩”效应的隐患存在，在某种程度上其实是束缚了“中心化”服务框架的平台扩展能力，也就是说，增加“中心”点企业服务总线实例的节点数量，并不能线性扩展平台的服务能力。正因为如此，当时的淘宝以及今天越来越多的企业最终选择“去中心化”服务框架作为企业或平台分布式服务框架。