在之前，阿里中间件事业部主要是一个服务于阿里内各个BU，提供企业级高可用互联网应用架构支撑的平台型支撑部门。而最近这两年，我们开始逐渐的将我们的已经比较稳定和可靠的分布式系统架构以服务的形式对外提供。也因为这个契机，我接触了大量的客户和软件服务提供商。在接触的过程中，有一件事让我记忆特别深刻，这就是原来在很多传统企业内……

本文分享围绕阿里技术架构演进及过程中遇到的问题与企业级信息系统架构的演进展开。
阿里技术架构演进及过程中遇到的问题
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 “云服务架构”专场的演讲内容整理。