阿里8年资深技术专家谈企业级互联网架构的演进之路

沈询，阿里巴巴中间件&稳定性平台资深技术专家，在淘宝工做八年间，主要负责的产品有淘宝分布式数据库（TDDL/DRDS）、分布式消息系统(Notify/ONS)等，故对整个分布式的互联网架构比较了解。本文分享围绕阿里技术架构演进及过程当中遇到的问题与企业级信息系统架构的演进展开。

阿里技术架构演进及过程当中遇到的问题

2003 年，淘宝最初的架构建设是采用 PHP，实践发现系统抗压能力相对薄弱。由于淘宝是一个企业级系统，因此选择了当时很是重要的企业级技术 JavaBean。以后把整个 Web 的容器、EJB 等整套体系引入淘宝，雇用有经验的工程师一块儿作架构。淘宝在技术方面也走过很长的路，在架构建设过程当中，你们讨论最多的事情是如何划分模块。

随着技术的不断发展，到 2006 年，淘宝技术又从 EJB 过渡到 Spring，以下图：

目前，这个产品已经开源，最上层采用的是 JBoss、中间采用 Webx，以后是 Spring、OR-Mapping，底层用到是 Oracle 数据库。用 Search 作搜索引擎，是由于当时收购雅虎，把雅虎的搜索引擎挂接到淘宝。像这样采用分布式的存储方式在如今看来很常见。

当时，业务不断高速发展，一些问题随之逐渐暴露出来。这里主要分享工程维护、人员变更、数据孤岛、数据集能力不足等问题。

工程维护与人员变更

随着业务不断壮大，技术团队的工程也会愈来愈多，源代码加速膨胀。多个工程之间，源代码冲突严重同时由于工做没有边界致使相互协同的成本不可估量。

假设出现项目完成，核心人员离职的状况，项目维护也会成为问题，当新人入职以后，学习老代码的难度也可想而知。

数据孤岛

数据孤岛是各个公司很广泛的问题，在那个时期，天猫还叫淘宝商城，不是基于淘宝，而是彻底独立的一个组。

后期由于一些缘由，想要把两个体系合并，却由于各自独立的业务体系、用户 ID、数据存储格式等等差别致使操做困难。且数据自己质量不高，作统一分析也有难度。

数据库能力达到上限

当时用的是小型机+Oracle，CPU90% 以上，每一年宕机最少一次。这主要是由于有大量新业务写入，两周一次的频度，不断地有新 SQL 产出。

在新的 SQL 中，如出现一个慢 SQL，就会出现宕机。当时咱们用的小型机重启一次须要 20 分钟，切换到异地也是 20 分钟。

关于链接数问题，以下图：

当时后端 Oracle 的链接池有限，约 8000 个左右，一旦超过就会出现问题。由于超过数量，连接占的内存会很是大，且链接数单点风险系统很高。

阿里面对 DBA 相关问题的应对方法

综上所述，当时阿里 DBA 面临维护人员不少，团队职责不清、数据没法共享，团队各自为战、小型机数据库压力过大，链接数单点风险系统很高等问题。

好在阿里那时正处于增加期，因此这时经过招聘一些技术大牛来解决问题。

基于 EDAS 进行服务化改造

针对阿里 DBA 遇到的问题，从硅谷请来的技术人用服务化的方式试着解决。当时在中国只有用友作过服务化，且效果不是很好，没有借鉴，只能谨慎当心的本身往前走。

以下图，是阿里以服务化方式将系统专业分工的三个关键战役。

用户中心服务化

选择用户中心的第一个是作服务化，由于用户中心是最小集合，最简单清楚，还由于确实有业务需求，也是想要验证这条服务化的理念是否是正确。

服务化以前的用户中心，有六个不同的查询方法，看起来遍历的方式差很少，但可能某个参数不一样，由于数据来自不一样的团队。

服务化的原则是能不改不改，能简化简化，采用的传输方式是 HTTP。然而，这样作行不通，是由于除了服务化 HTTP，其余内容没有改变，就须要布设 Load Balance。

为了保证 Load Balance 尽量稳定，因此选择硬件 F5 来配置。把前端进入的用户流量打到 F5，额外在增长新 VIP 接口，请求经过 F5 转出去。

这里发现一个很严重的问题，就是每当用户登录一次，出现一个节点，跳转一次流量就要增长一倍。但 F5 是很贵的设备，将来若是全部都变成服务化，用 F5 就不可行。

千岛湖项目

配置 F5 负载均衡行不通，换了另外一种思路就是由集中的单点模式变成真正意义的分散模式。当时阿里把这样的方式叫软负载，作的是分散负载均衡的事情。

当作交易中心服务化时，必然要用事物相关的方式，来保证整个流程的稳定性、一致性，当时采用的是最终一致性的设计方法。以后，经过实践反复修改，优化，获得稳定的消息系统。

有了消息系统的研发经验，随后类目属性等中心也随之服务化，之因此叫千岛湖项目，是由于你们很辛苦，完成项目以后去千岛湖旅游。

五彩石项目

随着千岛湖项目完成，底层架构、中间件的稳定，以后要作的事情就是把庞大的系统所有一次性服务化。

恰逢此时，淘宝商城和淘宝须要合并，因此整个系统在那个时期进行了完全的拆分，也就是淘宝 3.0。

以后再也没有出现 4.0，一直采用服务化的架构方式。

基于 DRDS 进行数据库分布式改造

DRDS 建设初衷是但愿对 Oracle 进行数据解析，同步到 MySQL 中。当时你们以为 Oracle 很稳定，整个系统不会丢数据，因此要把 Oracle 放在主机。

但也发现一个问题，一是小型机比较贵重须要在后端加入大量 PC 机，进行读写分离。还有就是看似稳定的 Oracle，在 Linux 环境中表现不是很好，尤为是二者还在兼容上存在不少问题。

以下，是传统数据库向分布式数据库的转化图：

最终选择用分布式的 MySQL 架构来解决问题，借鉴 Facebook 技术团队开发的开源项目 Flashcache 机制，为 MySQL 加速，完成整个业务的部署。在 Linux 环境下，MySQL 比 Oracle 更加稳定、运维成本也相对较低。

如上是作服务化中心带来的好处，显而易见。通过一段时间的改造以后，技术架构发生了很大变化，以下图：

在整个技术架构的最底层是 EDAS、DRDS、ONS 等组成的基础应用架构。电商、物流、移动IM、地理信息、医疗等都有本身的能力且都把能力进行开放，造成了IT共享业务架构层，用来支撑上层的业务。一旦业务须要合做，下层的技术能够快速响应。

例如，淘宝和滴滴从谈合做到项目顺利完成，只用了不到五天的时间。当时是一个内网打车软件，用这个软件打车可实现经过公司帐户去叫车，省去贴发票环节。

这件事情，真正的凸显出，技术能够帮助业务解决一些问题。虽然淘宝可能再也没有 4.0 版本，但如今每套应用系统都是为了将来而准备。

企业级信息系统架构的演进

经过对阿里技术发展历程的总结，咱们发现这些通过实践得出来的技术架构对一部分企业能够起到借鉴的做用。因此规划成一个产品——企业级信息系统。

云计算时代，企业信息化演进不只仅是把 IT 系统搬到云上，而是让业务与信息系统深度融合，改变业务运营和创新模式。

以下图，是企业级信息系统的演进过程：

把业务云化，从虚拟机模式转变成基于分布式的互联网架构进行重构，重构后给企业带来的主要的价值是原来的一些效率问题得以解决。因此说，互联网架构平台是企业云上演进的使能平台。

以下图是企业级互联网架构平台对应的下层架构：

最底层是基础框架，主要涉及 EDAS、MQ 和 DRDS 三大产品：

• EDAS 主要职责是业务应用的编写和发布。

• MQ 是在异步解耦的过程当中，用来作消息的编辑和保证事物的一致性。

• 有大量的用户和数据后，由 DRDS 负责分散到各个应用中去。

三个产品加起来，从上到下，很好地支撑业务的编写、相互通讯以及下层数据的建设。

CSB（能力开放平台）的主要职责是将阿里的 negligible 对外开放运营、保证内部数据的安全性和开放性，同时和现有的系统打通，进入到系统中去。云化业务的能力部分，是和客户一块儿设计构建。整套系统到最后的核心关键点是成本、稳定和效率。阿里在业务高速增加的这十几年实践中，积累了不少这三方面的经验。但愿这些经验能够帮助一些企业少走弯路。

以下图，是企业级互联网架构的关键特征：

随着机器数量的增长，性能必定是线性增长、可靠性成指数型增加、运营成本要保持对数级上升。这些才是真正互联网架构的关键特征，若是系统不能很好的解决这些问题，它会是一个没法向上扩展的系统，那么就没法知足将来用户的增加须要。

写在最后

为何会有这些互联网系统？为何会有这些互联网架构的特征？很简单，由于阿里的软件和服务最终是为用户服务的，当用户成指数级增加时，系统没有很好的扩展性，就必定会死。

什么是企业级互联网？就是若是光凭借互联网模式往前走，成本、研发效率等都会成为问题。基于过往经验，从新认知思考后，但愿经过软件的方式让互联网业务写的更容易，更可以贴合企业高速增加的需求。

以上内容根据王晶昱老师在 WOTA2017 “云服务架构”专场的演讲内容整理。

2008 年加入淘宝后在中间件和稳定性平台工做至今。目前负责阿里分布式数据库，以前叫 TDDL，如今运用到阿里云上更名为 DRDS、阿里的分布式消息服务(Notify/MetaQ)，以及阿里企业级互联网架构平台的新产品研发工做。