淘宝网技术

2024年5月10日发(作者：)

高性能电子商务网站-淘宝网技术架构研究

2008年淘宝的交易额是1000亿规模，2009年的时候是2000亿规模，2010年淘宝

网的交易额4000亿规模，如何构建一个支撑这么大交易规模的高性能、并发的电子商务

平台网站呢？ 以下结合网络资料，研究一下淘宝网的技术架构变迁。

淘宝网从2003年开始建立的，从1.0到1.5的版本.2005年开始2.0的版本，2012

年4.0的版本上线。

马云的创业团队共10个人，马云以及他的秘书，8个里面有3个开发人员，三丰、多

龙(音)、虚竹，还有UED的二当家，三位运营人员，小宝、阿柯和破天，总经理是财神。

团队开始研发是2003年4月7日，一个月后的5月10日淘宝第一个版本上线。这段时

间，创业团队关在小区里面写代码，每天早上9点到晚上1、2点。

淘宝网第一个版本MALT架构，采用PHP+MySQL

首先花2000美金买了一个MALT架构网站，很精典的LAMP技术架构，刚开始的编

程语言和数据库是PHP+MySQL，然后配套开发后台管理系统。一开始部署在一台单机服

务器上，流量增长后，把发邮件功能部署在一台机器上，后来再增加机器出来。

2004年MySQL撑不住了，数据存储的引擎很大缺点会锁表，一读的话把表锁住了，

读的量一上来经常会锁掉，然后重启。MySQL撑不住了，开始考虑换Oracle，除了Oracle

强大之外还有一个原因是阿里巴巴那些年03、04年Oracle人才积累达到非常强大的水平。

那时Oracle给全球的研发人员发一个称号“ACE”，那时全球三百多位，那时中国十来位，

而阿里巴巴有三位。阿里巴巴在Oracle方面能力非常强大。

换了Oracle有一个问题，PHP跟Oracle很不搭的东西，PHP一个用户访问过来建立

一个连接切掉一个连接，而Oracle提供的连接数量非常有限的，因为有连接池的功能。怎

么用PHP来连接Oracle?我们就抄袭别人看，eBay用的太贵，没有用。找了一个日本的，

但是上了一个当，总重启。中间件也撑不住了。存储原来放在服务器本身的硬盘上，这个

硬盘的支撑能力比较薄弱，存储也撑不住了。

从PHP迁移到Java，有一个问题要解决，如何选择开发团队?请SUN的人做的，快

速重构这样一个系统。

把管会员用户信息的模块单独部署在某个集成上，然后替换掉。我们做一个

，而member下线，把其他的交易一个个替换掉，要不要再替换

回来呢?我们没有替换回来，直接在线上运行，，导致另外一家很

强大的互联网公司也是这么来做的。现在看到的是架构框架。阿里巴巴自己做了MVC框

架，控制层用了EJB，当时SUN的人鼓吹EJB很好。搜索引擎是为了减轻数据库的压力。

搜索引擎一开始是在服务器的本地硬盘上做，后来用NAS的存储。

一个是性能、一个是容量、一个是成本。为了这几个点进行优化。一开始用一个Oracle

数据库，大概推算一下，一个Oracle数据库容纳多少数据，支撑多少访问量，差不多到亿

的级别满了不够用了，淘宝绝对不是想承载一个亿的数据，所以进行了分库的处理。一个

Oracle切成两个数据库的存储。接着在Java做分库路由的控制。接着缓存，淘宝用缓存

几乎用到极致，淘宝商品详情全部在缓存里面取的，每天有几十亿的流量，数据库里面肯

定都接不住。

还用到了CDN，后面会有一个话题讲淘宝双十一，很重要的角色是CDN，淘宝双十

一已经达到了873G每秒，中国最大的CDN服务商，上市说明书里面支撑500多个G，

淘宝是873G。一开始Weblogic没交钱，后来要交钱，很贵，就开始用Jboss。SUN的

人走了后把EJB丢掉了。

进展到这个版本叫做2.1，有分库、加入CDN，做了一些架构方面的处理。再往后发

展会怎样呢?就像人一样，每一步不一样，当大到一定程度以后新的问题出来了。2.1版本

里面存储问题非常严重。最大的问题还是存储，永远不够，我们用了IOE之后，相当长一

段时间比较稳定，花那么多钱是有效果的。

挑战最大的不是数据库的存储，而是文件存储，见证TFS的诞生

淘宝上有很多图片文件，非常多。2010年的时候大概有280多亿的图片数量，现在

应该超过1000亿的图片数量。一开始用的低端的存储，低端不行用中端的，再用高端，

越来越贵，一扩容增加十几万的成本。再往上扩，集群网络不够用了，实在没地方扩展了

怎么办?

2006年的时候，淘宝网决定开发一个分布式的文件存储系统，非常幸运的是2007

年初的时候，在硅谷一家伟大的公司公布了一篇论文，GFS的存储体系，论文公布出来之

后，两周之内淘宝出来一套淘宝网的文件存储系统，叫TFS，事情神奇的不是谷歌雪中送

炭，神奇的是也有一家也开发了TFS。淘宝和谷歌有一些不一样的，谷歌存放文件名索引

的东西反而成为瓶颈，扩容能力有限制，因为文件名有意义。但是淘宝文件名不需要有什

么意义。因为淘宝上面存储的图片取名字没有意义的。还有交易快照，原来淘宝拍下商品

记下ID号，跟原来商品关联的，原来的商品不能修改，修改交易出问题了，那时存储有限。

后来存储方面有TFS了，交易弄下来之后，把商品拍一个快照出来，作为文件存储下来，

每一笔交易包含图片、信息号。原来商品的图片不敢太大，淘宝灰蒙蒙的压缩非常严重，

而现在可以很大的图片。

还有一个故事是性能的问题。刚才说到缓存，一开始淘宝网用页面端的缓存，把页面

分成几个片断，商品页面上有卖家的信息，不会变的，作为一个文件存储在硬盘上去，这

是页面端ESI的缓存。后来发现数据也必须十月缓存，商家的信息每个商品都要用，数据

库里取每一天是几百亿取数据的访问量，这么多的访问量如果不用缓存是撑不住的。淘宝

自己研究了KV的缓存系统，淘宝网自己写了一个缓存系统，淘宝商品详情可以放进去。

比如说验证码，每天生成一万个验证码进去，用户随机取。用数据库的缓存memcached

出来了，参照了它的方案，有了内存的方案叫Tair，是自己缓存系统，为什么淘宝不用

memcached的东西，因为淘宝要用这些东西的时候太早了，还没有任何人给我们，只好

自己创造，走自主研发的道路。

TFS和Tair借鉴开源，淘宝图片不需要文件名，源数据量是比较小的，容量理论上讲

比GFS还大一些。不需要文件名就不需要文件夹的结构，查找文件的时候算法很简单了。

所以效率理论上来说，也是高于GFS的。

现在看到的是2.2版本的系统，上面的架构是一样的，下面做了一些分布式的存储、

缓存、数据库。搜索引擎做了扩展，原来多机器上放一份数据，后来放了多份数据，搜索

引擎做了备份扩展。这个阶段称之为2.2的版本。

淘宝网迎来了第二个危机

这样的系统，有了缓存、数据库的分库，又有了搜索引擎，这些东西支撑能力很强，

自己做了分布式的缓存、存储，接下来问题会出在哪里?流量还是一直往上涨，原来估数据

存储3到5年，2.0确实撑到3到5年，再下来出现很难解决的问题，例如Oracle的连接

数已经到了极限了，再加机器加不了了。原来有一万台机器，上面再加应用加不了了，因

为Oracle的连接池支撑不了了。还有人的问题，发展了五六年，工程师几百人，几百工程

师维护同样一套代码，做过的话，大家会深有体会，改一段代码不知道在哪改，可能代码

只有一行，但是找到它需要两天。有一些菜鸟过来，只能写一些代码，发布一些商品，各

种参数都有，原来方法里面三个参数，再过来一个人加一个参数，再过来加一个参数，过

来十个，就十个了。后面的人怎么维护?很多代码宕到本机，看代码到底在哪里?命名方式

不一样，找到一个很合适的地方，写很合适的代码，加一个参数应该不会影响别人，但很

费时间。系统的可维护性非常差。

还有一个压力是新业务，要做新业务怎么办?07、08年淘宝网对新的业务进行冲击，

那时做了淘宝的机票系统，机票系统不需要发布商品，去哪儿的几位很清楚，商品完全不

一样，需要第三方买它的数据，需要做一个还是怎样?我是机票系统的项目经理，做了很正

确的决定，另外起一个系统，获取机票信息、创建订单甚至评价还要有，各种各样的功能

都要有。系统很奇怪，有淘宝网用户的东西，想用主张评价不行，自己做一个评价。交易

的过程跟淘宝不一样，查看我已买到的东西跟主站合不到一块，另外一张皮出来了。在做

彩票、保险其他各种各样的东西，起了一个系统出来，有一半的主站完成，但是不敢放在

主站里面，放在里面添乱的。主站已经乱七八糟了，再加一个就完蛋了。这个时间问题很

严重，称之为第二个危机。

接下来大家怎么克服这个问题?

这时大家想到可以做服务化的东西，接下来做的事情第一个就是服务化，淘宝商品内

幕信息，发商品要用、查找商品要用、搜索引擎要用、后台维护要用，每一份都有一个出

来，架构师说可以独立拿出来，把内幕的东西变成服务，最早不是通过服务来启用的，而

是通过一个加包来做，淘宝的数据非常大的。淘宝的用户信息前后台都要用，又拿出来做

成淘宝的UIC，淘宝用户信息中心，开始慢慢走服务化的道路。服务化不是一下子做出来

的，各种各样的都有。

再往后面做了应用透明伸缩和数据的透明伸缩。我们把商品的应用、交易的应用、评

价的应用、店铺的应用全部分割开来，之后可以切开，每个团队管一个应用，上面应用的

透明伸缩，下面是数据量在Oracle里面再切做分库、分表，把数据也做了透明伸缩。比如

说淘宝的数据在线二三十个亿，不在线四五十个亿，放在数据库里面切，切成很多份。把

应用和数据全部切这么多份，不是简单切就能成功的。切成这么多份联合起来运作怎么办?

需要中间加一些东西：中间件。数据切成2048个库存，应用程序只要在中间件取就行了。

应用之间互相调用的时候还需要实时调用的中间件。一个商品应用可能需要调用户的信息、

物流的信息、评价的信息，这些系统之间的调用该怎么调用呢?不用管哪台机器上调用，也

不用去哪个集群里面调用，去找中间件。淘宝开发了高速访问框架。能提供什么服务都注

册到框架上去，需要什么服务去框架里查找需要什么服务，不同时期的版本都在上面。取

服务的时候给你找负载最低的机器给你，这是中间件的系统。

说了数据的中间件和应用调用的中间件，还有一个是消息通用的中间件。刚才人人网

和腾讯微博都讲消息通知，也是很恐怖的事情。用户在银行里付款的时候，银行通知到淘

宝，会有一些问题，银行都是国企，系统不太好恭维，银行网关不保障系统能扣款成功，

扣款成功不保障给支付宝发消息，发消息了不保障能发到，发到了不保障不再发一条。

淘宝切分这么多之后面临这个问题，通知到用户系统、银行系统、旺旺、甚至通知到

警察系统。系统能发什么东西，注册下来系统需要什么消息就注册，一旦有消息拿过来就

行了。这是消息的中间件。中间件本身的流量比业务层的流量还要高一点，一个请求有很

多的消息、很多实时的调用。

Session的框架。用户在消息系统登陆了，交易系统怎么办?要解决Session的问题，

可以用集中式的Session的控制集群。

基于这些之后，各种模块都有了做一些开放平台，把数据开放出去给其他人调用。有

了这些模块可以做到上层业务的百花齐放。做了这些之后再做淘宝商城很方便。用户信息

有了、评价模块有了，还需要什么?只需要搭积木上面加一个皮。像聚划算、易淘都是很快

能开发出来的，就是基于底下这么多的服务，才能达到这样快速灵活的开发。这个系统架

构如PPT所示。UIC、Forest基础业务服务，往上一层TC、IC、SC，核心业务服务。再

往上业务系统，交易业务、商品业务这些系统。中间HSF实时调用，右边是Notify，左边

是TOP。

说了这么多，很多同学觉得是不是淘宝发展很顺呢?不是的，有很多弯路在里面，比如

说一开始的存储，NAS作为数据库的存储，数据协助的延迟非常严重，淘宝用了戴尔和EMC

合作的低端存储替换还不行，用终端替换还不行，直到最后被逼着使用了EMC的存储。

04、05年淘宝用Ajax，我们觉得很好，对用户来说就觉得很奇怪。新老业务的统一，

新业务和老的系统合不到一起很奇怪的问题。服务华的粒度是一个问题，切分很多服务，

到最后也被害了一下。

用Ajax的时候，做了一个这种页面，可以按Enter做多选，翻页可以用滚动条翻页，

有些新的技术。让卖家管理商品非常方便，但是卖家看到就傻掉了，不会用，这是Ajax最

早期的尝试，现在习惯了。

新业务和老业务无法融合，在已买到的宝贝，有机票、保险、彩票，隶属于不同的系

统，合不掉一块。系统做服务化了，开始分成很多个应用，不同应用之间有一些调用关系，

这是最初设计比较理想的调用关系。

数据库切成主要的系统，切了之后每个团队都想把系统再切，切了大概两三百个应用，

他们之间的交易关系现在为止搞不清楚了，要用几个系统，没人搞得清楚。如果线画全，

页面全是黑线了。在座各位做服务化切分的力度一定要把握好，不然最后会坑掉，一旦死

掉一个，影响到哪个都不知道了。