【读书笔记二】《企业 IT 架构转型之道 - 阿里巴巴中台战略思想与架构实战》

第三章 分布式服务框架的选择



一、淘宝服务化历程



截止到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因为扛不住直接把所有实例拖死，最后不得不全部重启完再放开路由）。如果你幸运的话，重启就没事了；但是如果流量持续，刚才的噩梦还是存在重演的可能性，那这样的话这套模式的脆弱性就很明显了。



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



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