“淘宝技术这十年”

架构

时势造英雄

起因
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

性能 容量 成本的进化

数据库扩展
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：
　
　
4 自主研发的系统可在软件和硬件多个层次不断的优化。

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

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

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

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

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

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

淘宝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 地位等价。

浴火重生

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

服务化

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

中间件

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

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

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

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

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