“淘宝技术这十年”

“少时淘气,大时淘宝”
思维导图

时势造英雄

起因
eBay 易趣 在资本方面对仗,阿里想趁此崛起新项目
就要求能在短时间内做出一个 个人对个人的商品交易网站(C2C)
2003年4月7日-5月10日 一个月 淘宝技术团队采取购买方案

需求分析
自建|购入
:-:|:-
时间成本高,故不采用|要求比较低的维护成本;方便扩展和二次开发;轻量、简单

LAMP Linux+Apache+MySQL+PHP
优点:无须编译,发布快速;PHP语言功能强大,能做到从页面渲染到数据访问所有的事情,且用到的技术都是开源免费的

提供淘宝网站系统的官网:PHPAuction

购入后修改
增加后台管理功能、修改页面模板、页眉页脚加上自己站点简介;
数据库拆分:拆分成一个主库+连个从库,并且读写分离

数据库拆分优点
存储容量增加;备份提高数据安全性;读写分离提升读写效率

淘宝网”个人网站”即横空出世了

系统架构第一版

这个第一版系统中包含商品发布、管理、搜索、商品详情、出价购买、评价投诉、我的淘宝等功能
系统改进
背景:用户需求、流量增长、数据库资源增大
服务器:由一台变成了三台 Email + 运行数据库 + 运行WebApp
数据库搜索: like → isearch

问题短板
访问量和数据量的飞涨,数据库的性能缺陷突出:
1 当Master同步数据到Slave时,会引起Slave写,此时的Slave读操作都需要等待。
2 同时会发生Slave的主键冲突,经常导致同步停止,使得查询失败。

打怪升级

在前述的问题短板的情况下,阿里必须提出技术解决方案:

把MySQL换成Oracle
此处输入图片的描述

Oracle
优点:容量大、稳定、安全、性能高
人才条件:阿里有顶尖团队

更换数据库

访问方式 + SQL语法 + 连接池设计(关键)

存在的问题

连接池
连接池中放的是长连接,是进程级别的,在创建进程的时候,要独占一分部分内存空间,这部分连接数在固定内存的Oracle server上是有限的,任何一个请求只需要从连接池中取得一个连接即可,用完后释放,不需要频发地创建和断开连接,要知道连接的创建与断开开销是非常大的。
PHP语言
对数据库的访问很直接,每一个请求都需要一个连接。如果是长连接,应用故武器增多时,连接数就多了,就会把数据库拖挂;而如果是短连接,频繁得连接再断开 数据库性能会非常差

解决方案

开源的连接池代理服务 SQL Relay

遗留问题

SQL Relay死锁 只能靠重启服务解决

存储扩容

NAS 数据库存储设备(Network Appliance)+ Oracle RAC(Real Application Clusters,实时应用集群)实现负载均衡
NAS的NFS文件系统协议传输延迟很严重
改用了Dell和EMC合作的SAN低端存储
数据量的增大→存储结点的不断拆分↓RAC出现问题
购买小型机

支付手段创新-支付宝

安全交易、第三方托管、开发与银行网关对接功能

交流方式创新-淘宝旺旺

脱胎换骨 边换边跑

“好的架构图充满美感”。第二幅架构图显得头重脚轻,不是个稳定的版本,打怪的时候还是留下了祸根,SQL relay的问题无法解决,数据库必须使用oracle。

换开发语言 PHP → JAVA

JAVA
成熟的网站开发语言 比较良好的企业开发框架 开发经验人才多 后续维护成本比较低 有很多现成的连接池
Sun公司
创建java语言的开发公司,eBay的网站也经历过从C++到java的类似开发语言换骨,也是由Sun公司完成的。淘宝也请了Sun公司为淘宝主刀

要求

迁移过程中不停止服务,原系统的bugfix和功能改进不受影响。

方案

给业务分模块,一个一个模块地渐进式替换。如用户模块,老的member.taobao.com继续维护,不添加新功能,新的功能先在新的模块上开发,跟老的共用一个数据库,开发完毕之后放到不同的应用集群上,另开个域名 member1.taobao.com,同时替换老的功能,替换一个,把老的模块上的功能关闭一个,逐渐的把用户引导到 member1.taobao.com,等所有功能都替换完毕之后,关闭 member.taobao.com

小问题
二级域名member1.taobao.com应该是个过度状态,但却很难把member1切换回member,因为有些地方连接已经写死了

开发模式

Java MVC struts1.x
在多人协作方面有很多致命弱点,没有轻量框架作为基础,很难扩展
WebX
阿里巴巴 周悦虹 在 JAkarta Turbine 的基础上做了很多扩展 打造了一个阿里巴巴自己用的MVC框架 WebX。该框架易于扩展 方便组件化开发,页面模板支持 JSP 和 Velocity ,持久层支持ibatis 和 hibernate 等,控制层可以用EJB和Spring

JAVA 脱胎换骨

性能 容量 成本的进化

数据库扩展
Oracle “分库分表”:把用户的信息按照ID来存放到两个数据库汇总DB1DB2,把商品信息和卖家信息放在两个对应的数据库里面,把商品类目等通用信息放在第三个库里面(DBcommon)。这么做的目的除了增加了数据库的容量之外,还有一个就是做容灾,万一一个数据库挂了,整个网站上还有一半的数据能操作。  
数据的合并、排序、分页
DBRoute,统一数据的合并、排序、分页,该框架一直延续在Oracle时段。
Spring
EJB → Spring 系统精简了代码
缓存 CDN(内容分发网络)
缓存初型:Berkeley DB缓存系统,该缓存系统性能比较弱,存放不太变动的只读信息。
CDN 起初采用China Cache 后改用自己开发的CDN

脱胎换骨架构图
此处输入图片的描述

去IOE (IBM小型机 Oracle EMC存储)

创新技术

“用钱能解决的问题 都不是问题” 业务推动创新 创新推动业务

淘宝文件系统TFS

商用存储系统的局限
1 没有对小文件存储和读取环境进行针对性优化
2 文件数量大 网络存储设备无法支撑
3 系统所连接服务器越来越多
4 商用存储系统扩容成本高,存在单点故障,容灾和安全性无法得到保障

商用系统和自主研发之间的经济效益对比
1 商用软件很难满足大规模系统的应用需求,无论存储还是CDN还是负载均衡,因为在厂商实验室端,很难实现如此大的数据规模测试。
2 研发过程中,将开源和自主开发相结合,会有更好的可控性,系统出问题了,完全可以从底层解决问题,系统扩展性也更高。
3 在一定规模效应基础上,研发的投入都是值得的。上图是一个自主研发和购买商用系统的投入产出比对比,实际上,在上图的交叉点左边,购买商用系统都是更加实际和经济性更好的选择,只有在规模超过交叉点的情况下,自主研发才能收到较好的经济效果。实际上,规模化达到如此程度的公司其实并不多,不过淘宝网已经远远超过了交叉点。

投入与规模关系图

TFS存储需求
  文件比较小;并发量高;读操作远大于写操作;访问随机;没有文件修改的操作;要求存储成本低;能容灾能备份。应对这种需求,显然要用分布式存储系统;由于文件大小比较统一,可以采用专有文件系统;并发量高,读写随机性强,需要更少的 IO 操作;考虑到成本和备份,需要用廉价的存储设备;考虑到容灾,需要能平滑扩容。
  参照GFS 产生的TFSv1.0:
  大专栏  “淘宝技术这十年”mark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="TFS 1.0"/>
 
4 自主研发的系统可在软件和硬件多个层次不断的优化。

在这个架构中:
  • 每个 Data Server 运行在一台普通的 Linux 主机上
  • 以 block 文件的形式存放数据文件(一般64M一个block )
  • block 存多份保证数据安全
  • 利用 ext3 文件系统存放数据文件
  • 磁盘 raid5 做数据冗余
  • 文件名内置元数据信息,用户自己保存TFS文件名与实际文件的对照关系 – 使得元数据量特别小。

淘宝 TFS 文件系统在核心设计上最大的取巧的地方就在,传统的集群系统里面元数据只有1份,通常由管理节点来管理,因而很容易成为瓶颈。而对于淘宝网的用户来说,图片文件究竟用什么名字来保存实际上用户并不关心,因此TFS在设计规划上考虑在图片的保存文件名上暗藏了一些元数据信息,例如图片的大小、时间、访问频次等等信息,包括所在的逻辑块号。而在元数据上,实际上保存的信息很少,因此元数据结构非常简单。仅仅只需要一个fileID,能够准确定位文件在什么地方。
由于大量的文件信息都隐藏在文件名中,整个系统完全抛弃了传统的目录树结构,因为目录树开销最大。拿掉后,整个集群的高可扩展性极大提高。实际上,这一设计理念和目前业界的“对象存储”较为类似,淘宝网 TFS 文件系统已经更新到 1.3 版本,

TFS1.3重点改善
心跳和同步性能、元数据存储在内存中,清理磁盘空间等
性能优化:

1
2
3
4
5
6
采用ext4文件系统 并且预分配文件 减少ext3等文件系统数据碎片带来的性能损耗;
单进程管理单块磁盘的方式,摒除RAID5机制
带有HA机制的重要控制节点,在安全稳定和性能复制度之间取得平衡
缩减元数据大小,将更多的元数据加载如内存,提升访问速度
跨级计啊和IDC负载均衡及冗余安全策略
完全平滑扩容

图片文件服务器
部署在TFS前端,用Apache实现,缩略图实时生成
1 避免后端图片服务器上存储的图片数量过多,大大节约了后台存储空间的需求
2 缩略图可实时生成,更加灵活
3 采用一级缓存和二级缓存,前面还有全局负载均衡的设置

淘宝网缓存策略:淘宝网在各个运营商中心点设有二级缓存,整体系统中心店设有一级缓存,加上全局负载均衡,传递到后端的TFS流量就已经非常均衡和分散了,对前端的响应性能也大大提升。淘宝大部分图片都尽量在缓存中命中,如果无法命中,则在本地服务器上查找手否存有原图,并根据原图生产缩略图,如果都没有命中,则考虑去后台TFS集群文件存储系统上调取。

1
2
3
4
5
6
7
8
9
10
11
12
13
st=>start: Start
op1=>operation: 缓存中查找
cond1=>condition: Yes or No?
op2=>operation: 本地服务器上查找
cond2=>condition: Yes or No?
sub3=>subroutine: 后台TFS集群文件查找
e=>end

st->op1->cond1
cond1(yes)->e
cond1(no)->op2(right)->cond2
cond2(yes)->e
cond2(no)->sub3->e

淘宝KV缓存系统Tair

TBStore 分布式算法实现
根据保存的Key关键字,对key进行Hash算法,取得Hash值,再对Hsah值与总Cache服务器数据取,找到服务器列表中下表为此值的Cache服务器。由Java Client API封装实现
TBstore优缺点
它是基于Berkeley DB缓存系统的,而Berkeley DB在数据量超过内存的时候,就要往磁盘上写数据了,所以,它是可以做持久化存储的。但是一旦往磁盘写入数据,作为缓存的性能就大幅度下降

UIC (User Information Center)缓存系统 TDBM
数据全部放在内存中,改进了TDBM的集群分布方式,在内存利用率和吞吐量方面又做了大幅度提升

TDBM TBStore 的数据接口和用途都十分相似,二者合并推出即
Key-Value缓存系统(Tair,Taobao Pair,Pair即Key-Value数据对)
1 Tair包括缓存和持久化两种存储功能。
2 分布式系统:由一个中心控制节点Config Server和一系列服务节点Data server组成。
3 Config Server负责管理所有的Data Server,维护其状态信息。Data server对外提供各种数据服务,并以心跳形式将吱声的状况汇报给Config Server。
4 Config server是控制点,而且是单点,目前采用一主一备来保证其可靠性。所有Data Server 地位等价。

Tair架构图

阿里自研大规模分布式缓存服务 Tair 模块详解

浴火重生

淘宝网的技术发展史(三)——分布式时代

服务化

catserver和hesper 类目属性 服务化
高内聚低耦合 业务的拆分和耦合

中间件

High-Speed Service Framework实时调用的中间件(淘宝的HSF,高性能服务框架)
分布式服务框架HSF
分析分布式服务框架
基于OSGi实现分布式服务框架历程
分布式消息中间件系统 一种是异步消息通知的中间件(淘宝的Notify)

分布式数据访问层TDDLTaobao data distribution layer

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

稳定 “火车模型”
集群:能否集群受限于应用在水平伸缩上的支撑程度,而集群的规模通常会受限于调度、数据库、机房等
分工:涉及的主要有按功能和数据库的不同拆分系统等,如何拆分以及拆分后如何交互是需要面临的两个挑战。
负载均衡 根据QoS分配资源

Session框架

session介绍 可详见 图解HTTP读书笔记
解决session共享问题:
1 硬件负载,将用户请求分发到特定服务器
2 Session 复制,就是将用户的Session复制到集群内所有的服务器

缺点
成本较高;性能差,当访问量增大时,带宽增大,机器数量增多,网络负担成指数型上升

Tbsession
1 Session客户端存储,将session信息存储到客户端浏览器的cookie中
2 实现服务端存储,减少cookie使用,增强用户信息安全性,避免流浪器对cookie数量和大小的限制
3 session配置统一管理起来,集中管理服务端session和客户端cookie的使用情况,对cookie的使用做有效的监管
4 支持动态更新,session的配置动态更新

开放平台

Hadoop Memcached??

服务路由(外部可以获取内部信息)

写一个搞笑的httpAgent

服务接口标准化(统一方式的获得各种标准化信息)

对象文本化(JSON XML)

授权(外部合法的获取内部信息)

OAuth协议

[参考链接]《淘宝技术这十年》读书笔记

猜你喜欢

转载自www.cnblogs.com/lijianming180/p/12099531.html