行业案例：淘宝双11亿级流量五彩石架构演进.pdfVIP

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

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，其他内容没有改变，就需要布设LoadBalance。

为了保证LoadBalance尽可能稳定，所以选择硬件F5来配置。把