淘宝网技术

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

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的人做的，快速重构这样一个系统。

把管会员用户信息的模块单独部署在某个集成上，然后替换掉。我们做一个https://www.360docs.net/doc/ea6516229.html,，而member下线，把其他的交易一个个替换掉，要不要再替换回来呢?我们没有替换回来，直接在线上运行，https://www.360docs.net/doc/ea6516229.html,，导致另外一家很强大的互联网公司也是这么来做的。现在看到的是架构框架。阿里巴巴自己做了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最早期的尝试，现在习惯了。

新业务和老业务无法融合，在已买到的宝贝，有机票、保险、彩票，隶属于不同的系统，合不掉一块。系统做服务化了，开始分成很多个应用，不同应用之间有一些调用关系，这是最初设计比较理想的调用关系。

数据库切成主要的系统，切了之后每个团队都想把系统再切，切了大概两三百个应用，他们之间的交易关系现在为止搞不清楚了，要用几个系统，没人搞得清楚。如果线画全，页面全是黑线了。在座各位做服务化切分的力度一定要把握好，不然最后会坑掉，一旦死掉一个，影响到哪个都不知道了。