一、淘宝服务化历程

截止到 2007 年，淘宝已经拥有超过 500 人的技术团队规模，整个淘宝网站是一个几百兆字节的 WAR 包，功能模块超过 200 个。几百人维护一个 WAR 包的模式,带来了以下几个主要问题：

1. 项目团队间协同成本高,业务响应越来越慢。

2. 应用复杂度已超出人的认知负载。各种业务互相交错，已经没有一个人能完全清楚每个功能或流程的细节，毕竟人的认知负载是有极限的；

3. 错误难于隔离。因为淘宝平台是一个 WAR 包，其核心功能和非核心功能的代码都运行在同一个环境（同一个 JVM)中，任何一个小的问题都可能引发全局问题；

4. 数据库连接能力很难扩展；峰值期间数据库连接数超过 5000 个，已经非常接近官网理论极限，这样的状态下数据库肯定是紧绷而不稳定的（如下图）；

5. 应用扩展成本高；在业务高峰期，发现只有某几个功能模块（如订单、库存等模块）才出现高负载情况，但因为整个淘宝平台是一个单体 war 包，所以无法针对高负载的几个功能模块进行单独扩容，导致扩容成本较高。

以上提到的几个问题促使了淘宝从 2007 年开始整个技术体系架构往自主可控、创新变革的方向迈进。解决以上问题的根本就在于业务的拆分,而当时业界已经盛行的 SOA 理念和方法则是有效解决以上问题的不二选择。所以淘宝在 2007 年 10 月开始了一系列的基于 SOA 理念新一代服务化框架研发以及采用业务模块逐步迁移的方式进行应用架构的改造工作。

首先淘宝从现有应用中选择了用户相关的功能作为试点，剥离出了用户服务中心，主要出发点是用户的业务逻辑相对独立和简单且服务功能的复用率最高，最后于 2008 年初成功上线。接着，千岛湖”项目成功将“交易中心”和“类目中心”从现有平台中进行了剥离和改造,“五彩石”项目则将剩下的“商品中心”、“店铺中心”等核心业务功能模块进行了全部的改造。在短短 14 个月内，应用部署形态上由之前一个几百兆字节大小的 WAR 包部署模式改造成为上百个 WAR 包独立部署的服务化架构。这次改造被阿里巴巴同事称为“给飞行中的飞机换发动机”，也为后来的共享服务体系的建设打下了扎实的技术和理论基础。

伴随着服务化改造，上述提到的 5 个问题也得到较好的解决：

1. 降低不同模块开发团队间的协同成本,业务响应更迅捷；

2. 大大降低系统间的耦合度以及整体复杂度各个开发团队可专注于各自的业务模块；

3. 避免了个别模块的错误给整体带来的影响；

4. 业务拆分后解放了对单数据库集群连接数的能力依赖；

5. 做到针对性的业务能力扩容,减少不必要的资源浪费。

二、“中心化”与“去中心化”服务

这里先回顾一下 SOA 的主要特性:

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

• 服务间松散耦合。

• 支持服务的组装。

• 服务注册和自动发现。

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

首先，SOA 理念大概在 2004 年左右在业界提出。越来越多的企业在多年之前建立的 IT 系统无一不是采用“烟囱式”建设模式而建立的，这样使得企业内的各种系统纷繁林立，彼此孤立，系统间的对接交互基本是点对点，但是交互方式五花八门，从宏观上看就类似一张“蜘蛛网”。

当时很多厂商推出的 ESB 产品正是很好的解决了这个“蜘蛛网”问题，因为它通过把自己扮演成一个中心化的服务总线的方式实现了企业内部各种异构系统的互联互通。所以，在这样一个需求背景下，ESB 的方式成为这一时期 SOA 理念的实现方式。因为，在当时业界大环境下，企业或者业务的根本诉求是实现异构系统之间的互联互通。

但是后来随着互联网行业的发展，系统使用方从以前的 2B 慢慢变成 2C，那 2C 的用户量肯定要比 2B 要多得多。正式这样的用户群体量决定了系统架构要首要考了扩展性和稳定性。另外，“去中心化”分布式服务框架除了需要在满足 SOA 理念的基础上使得服务提供者和服务调用者之间在进行服务交互时无需通过任何服务路由中介，避免因为“中心点”带来平台能力难扩展问题，以及潜在的“雪崩”影响。

这里把“中心化”和“去中心化”这两种架构做个简单的描述比较。

首先，像传统的中心化 ESB（哪怕是集群模式），在客户端到服务端之间的每次调用都需要通过通过 ESB 进行 1）报文协议转换、2）请求和返回报文转发这样的一个过程。整个过程里面，ESB 需要产生 4 次会话。随着业务体量的扩大，可以预见 ESB 将会变成系统的潜在瓶颈。

接着，或者有人会说可以通过不断横向扩容 ESB 进行解决。先抛开扩容成本不说，好像貌似是讲得通的。但是要注意具体的上下文。当时是互联网时代，用户群是 2C。一旦用户流量上去了，这种模式的缺点就会显露出来。一开始你水平部署 10 台 ESB 确实可以正常稳定的顶住了常规流量访问（假设每台的预警水位为 80%，实际用户流量也是刚好 80%），但是如果某一刻某个实例不知为何崩掉了，只有 9 台支撑，每个实例的实际水位马上拉升到 90%。而且一般当水位去到较高位时，服务器的响应速率一般是会大幅降低，然后很快的直接就拖死了第二台、第三台。。。然后因为流量是不会减少的，你会突然发现重启几乎是不可能的事情。为什么？因为你重启一台直接就被扑过来的流量马上拖死。因此，你的做法一定是去掉路由，先把挂掉的实例全部启动起来，然后再开路由，但是在这个过程基本所有 10 台实例都已经被直接拖死了（在笔者的过往经验中也曾经体验过 ESB 因为扛不住直接把所有实例拖死，最后不得不全部重启完再放开路由）。如果你幸运的话，重启就没事了，但是如果流量持续，刚才的噩梦还是存在重演的可能性，那这样的话这套模式的脆弱性就很明显了。

反观“去中心化”。首先，“去中心化”他不会像“中心化”一样去充当一个“代理人”的角色。这种模式只是规定整体的系统们通过什么具体的协议进行交互，而且不参与两个系统间的交互当中。第一，通讯链路的节点少了，出问题的可能更少；第二，“去中心化”不负责路由转发、报文协议转化等功能，因而没有带来额外的网络开销。因此这种去中心网络还是大行其道，像 Redis Cluster 这种就是典型的去中心化 P2P 网络结构。

正正因为如此，当时的淘宝就选择使用“去中心化”的服务框架作为企业发布式服务框架。