淘宝腾飞:浴火重生的巨人

开发 前端
例如缓存、CDN等优化手段;运转状况监测、功能降级、资源劣化、流控等可用性手段,自建机房、硬件组装等成本控制手段。 因此,构建一个互联网网站确实是不容易的,技术含量十足,当然,经营一家超市也不简单。

开发平台

2006年年底:阿里巴巴提出了Work at Alibaba的战略,二十多个人就被拉到湖畔花园马云的公寓里开始一个叫阿里软件的公司创业。当时对于Work at Alibaba有一个朦朦胧胧的感觉,就是要为中小企业提供一个工作平台,但是工作平台又需要是一个开放的平台,因为卖家的需求是长尾的。当时火热的Salesforce给了阿里人一些启示,那就是做一个支持二次开发的工作平台,半开放式地满足各种卖家的长尾管理需求。此时,软件市场上就开始培养起uizao的一批TP(淘宝开放合作伙伴)。迄今为止,很多非常成功的TP就是从那个时候开始进入淘宝卖家市场的。

但经过一年的平台建设,发现开发者非常难利用平台做二次开发,只有阿里软件内部的团队构建了三个不同的CRM软件。这时候淘宝来了一个业界的技术牛人王文彬(菲青),这位淘宝新近的***架构师找到阿里软件的平台架构团队,谈到了当时业界还非常新颖的一种技术平台——开放平台。

例如缓存、CDN等优化手段;运转状况监测、功能降级、资源劣化、流控等可用性手段,自建机房、硬件组装等成本控制手段。 因此,构建一个互联网网站确实是不容易的,技术含量十足,当 然,经营一家超市也不简单。  

高性能服务框架HSF

从超市的运维可以抽象出系统设计的一些思路,服务拆分之 后,如何取得我需要的服务?在“电视机”上,把每个集群能提供 的服务显示出来。你不需要关心哪个人为你服务,当你有需要的时 候,请先看头顶的电视机,它告诉你哪个服务在哪个区域。当你直 接去这个区域的时候,系统会给你找到一个最快速的服务通道。

这就是HSF的设计思想,服务的提供者启动时通过HSF框架 向ConfigServer(类似超市的电视机)注册服务信息(接口、版 本、超时时间、序列化方式等),这样ConfigServer上面就定义 了所有可供调用的服务(同一个服务也可能有不同的版本);服 务调用者启动的时候向ConfigServer注册对哪些服务感兴趣(接 口、版本),当服务提供者的信息变化时,ConfigServer向相应 的感兴趣的服务调用者推送新的服务信息列表;调用者在调用时 则根据服务信息的列表直接访问相应的服务提供者,而无须经过 ConfigServer。我们注意到ConfigServer并不会把服务提供者的IP地 址推送给服务的调用者,HSF框架会根据负载状况来选择具体的 服务器,返回结果给调用者,这不仅统一了服务调用的方式,也 实现了“软负载均衡”。平时ConfigServer通过和服务提供者的心 跳来感应服务提供者的存活状态。

在HSF的支持下,服务集群对调用者来说是“统一”的,服 务之间是“隔离”的,这保证了服务的扩展性和应用的统一性。 再加上HSF本身能提供的“软负载均衡;,服务层对应用层来说 就是一片“私有云”了。

HSF框架以SAR包的方式部署到Jboss、Jetty或Tomcat下,在应 用启动的时候,HSF(High-Speed; Service Framework,在开发团 队内部有一些人称HSF为;好舒服;)服务随之启动。HSF旨在为 淘宝的应用提供一个分布式的服务框架,HSF从分布式应用层面 以及统一的发布/调用方式层面为大家提供支持,从而可以很容易 地开发分布式的应用以及提供或使用公用功能模块,而不用考虑 分布式领域中的各种细节技术,例如,远程通讯、性能损耗、调 用的透明化、同步/异步调用方式的实现等问题。

从上图HSF的标志来看,它的速度是很快的。HSF是一个分 布式的标准Service方式的RPC(Remote Procedure Call Protocol, 远程过程调用协议)框架,Service的定义基于OSGI的方式,通 讯层采用TCP/IP协议。关于分布式的服务框架的理论基础,HSF 的作者毕玄写了一篇博文(http://www.blogjava.net/BlueDavy/ archive/2008/01/24/177533.html),有关基于OSGI的分布式服 务框架,也有一系列的博文(http://www.blogjava.net/BlueDavy/ archive/2008/01/14/175054.html)。

从下面这个HSF监控系统的截图中可以更直观地看到一些信 息,在两个集群中有两个服务器(其实有更多的,没有全部截图 下来)都提供com.taobao.item.service.SpuGroupService 这一服务, 版本号都是1.0.0,这个服务在ConfigServer上的注册信息中包含 超时时间、序列化方式。在后面那条信息中可看到,在展开的这  这个集群中服务有835台机器已订阅,这些订阅者有淘宝的服务器(cart是购物车功能的服务器),也有hitao(淘花网)的服务器。

 HSF系统目前每天承担了300亿次以上的服务调用。


 

一些读者可能会有一个疑问:既然淘宝的服务化是渐进式的,那么在HSF出现之前,系统之间的调用采用什么方式呢?

这个有点“五花八门”,例如,对于类目的调用方式是: Forest打包成一个JAR包,在应用启动的时候装载到内存中,仅 这一个JAR包所占用的内存就有800MB之多(因为淘宝的类目数 据太庞大了),对于当时一般只有2GB内存的开发机来说,加载 完类目信息后,机器运行速度就非常慢。对于用户信息(UIC) 来说,一开始的调用方式是用Hessian接口。还有一些系统是通过 WebService、Socket甚至是HTTP请求来相互调用的。每种调用方 式都涉及各种超时、信息的加解密、参数的定义等问题,由此可见,在没有HSF之前,系统之间的调用是错综复杂的。而随着系 统拆分得越来越多,必须由一个统一的中间层来处理这种问题, HSF正是在这种背景下诞生的。

#p#

分布式数据访问层TDDL

有了HSF和Notify的支持,在应用级别中,整个淘宝网的系统可以拆分了,还有一个制约系统规模的更重要的因素,就是数据 库,也必须拆分。

在第二部分中讲过,淘宝很早就对数据进行过分库的处理, 上层系统连接多个数据库,中间有一个叫做DBRoute的路由来对 数据进行统一访问。DBRoute对数据进行多库的操作、数据的整 合,让上层系统像操作一个数据库一样操作多个库。但是随着数 据量的增长,对于库表的分法有了更高的要求,例如,你的商品 数据到了百亿级别的时候,任何一个库都无法存放了,于是分成

2个、4个、8个、16个、32个……直到1024个、2048个。好,分成 这么多,数据能够存放了,那怎么查询它?这时候,数据查询的 中间件就要能够承担这个重任了,它对上层来说,必须像查询一 个数据库一样来查询数据,还要像查询一个数据库一样快(每条 查询在几毫秒内完成),TDDL就承担了这样一个工作。

另外,加上数据的备份、复制、主备切换等功能,这一套系 统都在TDDL中完成。在外面有些系统也用DAL(数据访问层) 这个概念来命名这个中间件。

TDDL实现了下面三个主要的特性:

  •  数据访问路由——将针对数据的读写请求发送到最合适的 地方;
  •  数据的多向非对称复制——一次写入,多点读取;
  •  数据存储的自由扩展——不再受限于单台机器的容量瓶颈 与速度瓶颈,平滑迁移。

下图展示了TDDL所处的位置。


下图展示了一个简单的分库分表数据查询策略。


下面是TDDL的主要开发者之一沈询讲述的“TDDL的前世今生”——数据层的发展历程。

CommonDAO的时代

数据切分并不算是一个很新的概念,当商品库切分为两个 时,就已经出现了名字叫做xingdian(笑,那时候行癫已经不写 代码了,但从代码的版本信息可以看到作者)的人写的Common DAO。CommonDAO的思路非常简单实用,因为淘宝主要在使用 ibatis作为访问数据库的DAO层,所以,CommonDAO的作用就是 对ibatis层做了一个很浅的封装,允许你通过商品字串ID的***个 字符来访问两台数据库中的一台。

比如,如果字符串ID的***个字符是0~7,那么走到数据库1去,如果是8~f,则走到数据库2去。同时,也允许用户直接给定 数据库的名字来访问数据库。

这应该是最早的数据层原型。

TDDL 1.0时代

后来,大家逐渐发现,如果按照业务的发展规模和速度,那么使用高端存储和小型机的Oracle存储的成本将难以控制,于是降低成本就成了必然。

如何能够在不影响业务正常发展的前提下,从一定程度上解决成本的问题呢?

“对一部分数据库使用MySQL”,DBA们的决策是这样,于是,分布式数据层的重担就落到了华黎的头上。

别看现在数据水平切分似乎已经成了基础知识。在2007年、2008年,如何设计它还真是让我们伤透了脑筋。

当时的我们,只知道eBay有一个数据层,却不知道如何设计和实现?

于是邀请了当时所有的业务负责人来畅想数据层的样子…… 得到了以下需求:

  •  对外统一一切数据访问;
  •  支持缓存、文件存储系统;
  •  能够在Oracle和MySQL之间自由切换;
  •  支持搜索引擎。

然后,我们自己的问题与现在大家所问的问题也是完全一样的。

如何实现分布式Join(连接)?——在跨节点以后,简单的Join会变成M×N台机器的合并,这个代价比原来的基于数据库的单机Join大太多了。

如何实现高速多维度查询?——就像SNS中的消息系统,A发 给B一个消息,那么A要看到的是我发给所有人的消息,而B要看 到的是所有人发给我的消息。这种多维度查询,如何能够做到高 效快捷呢?

#p#

如何实现分布式事务?——原始单机数据库中存在着大量的 事务操作,在分布式以后,分布式事务的代价远远大于单机事 务,那么这个矛盾也变得非常明显。

华黎带着我和念冰,坐在那里讨论了一个半月,还是没想出 来……于是决定先动起手来。名字是我起的——Taobao Distributed Data  l ayer(TDDL,后来有人对它取了个外号  :“头都大了”⊙﹏⊙b)

学习开源的Amoeba Proxy。 找到的目标应用是“收藏夹”,首先要做的两个关键的特性是:分库分表和异构数据库的数据复制。

开始本来希望和B2B的团队合作,因为我们觉得独立的Proxy 没有太大必要。而SQL解析器因为有淘宝特殊的需求,所以也需 要重写。

 可惜,***因为B2B的人搬到滨江去了,交流十分不畅,所以***只是做了拿来主义,没有对开源的Amoeba和当时的Cobar有所贡献。

回到淘宝,因为有东西可以借鉴,我们在一个多月的时间内 就完成了TDDL 1.0版本的工作。上线过程中虽然出了点小问题, 不过总体来说是比较成功的。

TDDL  2.0时代

随着使用TDDL的业务越来越多,对业务方来说,DBA对于使用MySQL以及数据切分也积累了比较多的经验,于是决定开始 动核心应用了。

“评价”是***个重要的应用,评价最重要的问题还是在于双向查询、评价、被评价。于是我们的异构数据源增量复制就派 上了用场。

然后是“商品”,我们在商品上投入了近半年的时间,失败很多,也成长得最快。

  •  容量规划做得不到位,机器到位后因压力过大,直接死掉,于是产生了数据库容量线上压力模拟测试。
  • 历史遗留问题,商品几乎是所有的业务都会使用的资源, 所以接口设计比较复杂。很多接口的调用在新架构上很难以低成本的方式实现。而推动业务改动,则需要大量的时
  • 间和成本。
  •  数据层代码被业务代码侵染,看起来似乎应该是数据层的 代码,但实际上又只有商品在使用。这种问题让数据层的依赖变得更加庞大,边缘代码变得更多,冲突更明显。

TDDL  3.0~TDDL  4.0时代

在商品之后,似乎所有的应用都可以使用类似的方式来解决 业务增长上量的问题。但正当我们志得意满的时候,却被“交 易”撞了一个满怀。

我一直很感谢交易线的所有同仁,他们是淘宝草根精神的典 型代表 —— 功能可以做得不那么“漂亮”,但必须减少中间环 节,真正做到了实用、干净、简洁。我们在向他们介绍产品的时 候,他们对我们的实现细节提出了非常多的质疑,他们认为整个 流程中只有规则、主备切换对他们是有意义的,而解析、合并则 是他们所不需要的功能。

“不需要的功能为什么要放到流程里?增加的复杂度会导致 更多的问题”。在当时,我感到很痛苦,因为我无法回答他们这 些质疑之声。

不过,也正是因为这些质疑,让我有了一个契机,重新审视自己所创造出来的产品。

我问自己:它能够给业务带来什么益处? 对此,我的回答是:

  • 规则引擎/切分规则可以用配置的方式帮助业务隔离具体的 数据库地址与用户的业务逻辑;
  •  单机主备切换;
  •  数据源简化和管理。

于是,我们就产生了TDDL 3.0版本。其主要的作用就是将代 码做了逻辑切分,将单机主备切换和数据源管理独立了出来。这 样,可以针对不同的业务需求,给予不同的逻辑分层。让每一个 业务都有适合自己的使用数据库的方式。

同时,我们开始做工具,Rtools/JADE 作为数据库运维平台的 组件被提了出来。在它的帮助下,我们发现能够极大地提升用户 在使用单机数据源和多机数据源时的效率。用户只需要在客户端 给定两个属性,就可以立刻开始使用。结果是用户反馈比以前好了很多。

这也坚定了我们开发工具的决心。

工具平台时代

在尝到工具平台的甜头以后,我们在工具组件上走得更远了。

首先被提出的是“愚公”数据迁移平台。该平台能够在多种 异构的数据库中进行数据的平滑移动,对业务影响很小,并且也 允许业务插入自己的业务逻辑。

这个东西主要能够帮助业务进行数据库自动扩容,自动缩 容,单机、多机数据迁移,在Oracle到MySQL数据迁移等场景中 都发挥了重要的作用。

然后,又以内部开源的方式提出了“精卫”数据增量复制 平台。这个平台基于数据库的通用数据分发组件,基于开源的Tungsten进行了大量Bug Fix和结构调优。在数据的一对多分发以 及异步通知给DW和搜索等场景中都发挥了重要的作用。

TDDL的现在

粗略统计下来,TDDL已经走过了4年的时间,满足了近700个 业务应用的使用需求。其中有交易商品评价用户等核心数据,也有不那么有名的中小型应用。量变产生质变,如何能够更好地帮 助这些业务以更低的成本更快地完成业务需求,将成为数据层未 来最重要的挑战。

 

责任编辑:陈四芳 来源: 51CTO
相关推荐

2013-12-24 16:30:38

初志科技统一存储

2010-05-11 09:50:10

OracleSunJava

2013-08-01 09:15:42

Xen Hypervi 虚拟化

2021-07-26 15:12:51

区块链比特币应用

2013-07-09 21:35:41

2010-03-30 20:52:50

2013-07-09 17:31:00

mySQLOracle

2012-05-22 22:35:23

Windows 8

2013-07-09 21:15:15

Java后台

2022-04-19 08:02:33

供应链企业数据分析

2013-07-09 17:18:52

LAMP架构网站建设

2018-01-10 08:53:23

2020-03-04 17:26:02

疫情零售无人零售

2012-05-22 17:25:14

Windows 8操作系统

2019-03-15 16:40:25

手机屏幕苹果

2011-04-21 13:49:29

dementionSQL

2018-06-25 08:00:18

Spring Clou架构数据中台

2011-12-26 20:18:57

移动应用

2012-12-12 16:12:58

KVMIBM
点赞
收藏

51CTO技术栈公众号