淘宝技术架构

• 稳定性：稳定深入入人人心心，各个系统关键指标的监测和报警、简
化系统、系统自自身身的保护、同城容灾、异地机房、容量规划
• 提升性能：核心心业务系统性能提升2.X • 降低成本：CDN去硬件负载、去 • 数据存储检索升级和稳定 • 商品库、库存库热点解决、历史订单问题
IOE、搜索优化 Kingso
HBase、收藏夹 OB、 店铺内搜索KSearch、搜索 Dump中心心引入入 Hadoop 集群。。
迁移到 Oracle SQL Relay 连接池代理服务 RAC & SAN低端存储
• Oracle
Oracle
V1.X时代
• MySQL
撑不住了，换 ORACLE
• 中间件撑不住了怎么办？ • 数据存储撑不住了怎么办？ • 业务发展太快怎么办？
V2.0 2004.2 - 2005.3
• SQL
2000$
• LAMP典型架构 • Mysql
R/ad
复制 S2av/
R/ad/Wr1t/
MySQL Mast/r 复制
R/ad
一一主两从，读写分离
S2av/2
• pearDB数据访问层
V1.1 2004.1 - 2004.5
• 数据膨胀，锁表问题严重MyISAM • 主库大大量读，主库性能下降厉害 • Mysql • 引入入
支支持最终一一致 消息可靠 不保证顺序
Database Database Database
V3.0 核心心技术组件
: 1 4/ 3
/ 1
T P
/ 1 25
N S S
523
N
:
Notify - 最终一一致性
V3.0 核心心技术组件 - TDDL
• • • •
基于 Mysql binlog 支支持多种维度 支支持不同⺫目目标 行行复制方方案
HSF
http Search HAProxy + Squid Server 集群 (低功耗 Server) cache 未命中
①
LVS

③
源站
V3.0 系统结构
V3.0 系统结构
CDN Web应 用集群 易 评价 用户 商品 服务 消息 商品 ... ... 运行 状况 监测 和报 警系 统 TFS
•
淘宝是一一个交易⺴网网站，核心心要素：要素(人人/物/合同)、过程(付款)、交流
•
功能需求：交易服务化
•
淘宝是一一个很大大的交易⺴网网站
•
非非功能性需求：高高稳定性(高高数据安全、高高可用用)、高高容量&高高性能(高高 并发、高高存储、低响应时间)、低成本(硬件/人人力力)
•
淘宝是一一个高高速发展的很大大的交易⺴网网站
……
• 类⺫目目属性体系 • 分布式存储 TFS • 分布式缓存 Tair • 分布式搜索引擎
-a-1e
Fun-t2on 3 Fun-t2on 2 JBoss Fun-t2on JBoss JBoss B宝MVC JBoss B宝MVC B宝MVC Spr2ng B宝MVC Spr2ng Spr2ng Ibat2s Spr2ng Ibat2s Ibat2s OR-Mapp2ng
请求的处理过程
CDN 的处理过程
①
LB设备

Squid Server 集群
cache 未命中
③
源站
Hale Waihona Puke Baidu
V2.X 时代
分域名
①
①

Denali 集群
tcp/ip bio
TDBM TFS
Denali 集群
jdbc
Oracle
主站请求处理
①
Denali 集群
Alipay http Search
Fu2cti32 4 Fu2cti32 3 Fu2cti32 A4ache A4ache Fu2cti32 1 A4ache 13d_4h44 13d_4h44 A4ache 13d_4h44 4ear DB 4ear DB 13d_4h44 4ear DB SQL Relay SQL Relay 4ear DB SQL Relay SQL Relay
V3.0 核心心技术组件 - TDDL
核心心功能:数据访问路由、数据的多向非非对称复制、数据存储的自自由扩展
V3.0 核心心技术组件 - TAIR
V3.0 核心心技术组件 - TFS
V4.0 下一一代架构
• 技术支支撑淘宝的时代：1.x • 技术改变淘宝的时代：4.x • 3.x
- 3.x
时代应用用架构和数据架构等基本固化
Relay 死锁问题严重 Java, 模块逐步替换
• PHP迁移到 • MVC
框架 WebX
Funct4on 4 Funct4on 3 W1blo24c Funct4on 2 W1blo24c Funct4on W1blo24c 淘宝MVC 淘宝MVC W1blo24c EJB 淘宝MVC EJB 淘宝MVC OR-M-pp4n2 OR-M-pp4n2 EJB EJB OR-M-pp4n2 OR-M-pp4n2 Read/Write S1-rc3 Or-cl1 dump Nod1 Nod1 2 …… Nod1 n
V3.0 应用用透明伸缩
•
会话处理很重要
• • • •
粘性 Session Session 复制 集中式 Session 不用用 Session
•
统一一的登录认证和帐号体系
V3.0 应用用透明伸缩
应用用拆分、服务化
V3.0 应用用透明伸缩 - 隔离
V3.0 应用用透明伸缩
APP APP APP APP APP APP
V3.0 改变
• 开始思考淘宝的本质 • 开始尝试从被动支支撑转换为主
动支支撑
• 从使用用技术开始大大幅过渡到创
造技术
• 服务化、稳定性、降低成本
V3.0 淘宝是什么
WebServer
AppServer
D Server
淘宝是一一个⺴网网站么，⺴网网站的本质是什么？
V3.0 淘宝是什么⺴网网站
V3.0 核心心技术组件
业务 码 Webx 容器 HSF Notify 业务 码 容器 TDDL TDDL DB DB TDDL ConfigServer Diamond
V3.0 核心心技术组件 - HSF
HSF - 分布式服务调用用框架，软负载、容灾、协议统一一
V3.0 核心心技术组件 - NOTIFY
•
非非功能性需求：低维护成本
V3.0 处理策略
• • •
高高稳定性：备份、隔离 高高容量、高高性能：人人多力力量大大、分割、异步 成本：提高高效率、自自动化
How？
HOW？
• • • • •
隔离肯定会变得复杂，怎么解决？ 备份会增加成本 分割和异步，怎么解决交易的事务性问题？ 怎么做到自自动化和稳定性的平衡？ 怎么快速支支撑业务发展的同时进行行变革革？
CDN Denali集群
系统结构图
DB
页面片 缓存集群
TFS
NAS
Search
Alipay
V2.X时代最大大问题
• 主要业务都在一一个系统里里
Denali
• 打包部署一一次，半小小时，部署失败，半天过去了 • 100多个开发维护同一一个系统，混乱中纠结 • 数据都在一一个数据库中，扩展困难 • 访问量增加，不停加机器，连接池又又不够用用 • 数据量增加，不断升级数据库机器，已到极限 • 预言言帝说：不做任何改变的化，淘宝将于08年6月月挂掉
V3.0 数据透明伸缩
业务处理 淘宝数据层 路由处理 数据复制 ……
…… …… 业务1 …… …… 3 4 5
核心 业务 数据
……
业务1 ……
业务 ……
•
容量和性能的扩展
• •
• •
路由：透明化 复制：空间换时间
按功能垂直分割 按规则水水平分割
V3.0 可用用性
• • •
同城分流 异地容灾 N+1原则
•
V3.0 2007.12 - 2012.1
•
应用用透明伸缩
• • • •
Session 框架 高高性能服务框架 HSF 消息系统 Notify 业务中心心和业务服务化
服 /消息
• • • •
数据透明伸缩: TDDL 稳定性:容灾 成本优化:自自动化、数据迁移到 Mysql 技术创造时期，大大批框架和底层系统
• 下一一代架构：自自动化、智能化、数据化、容器化
V4.0 下一一代架构
• 应用用架构
-> 运维架构
页面片段缓存集群 业务 逻辑 集群 易 评价 用户
数据缓存集群 易 评价 用户 商品
数据层 ... 搜索
V3.0时代过程中的问题
• 糟糕的稳定性，宕机、大大流
量冲击、系统崩溃。。。
• 改变过程中遇到的各种问题 • 复杂的依赖关系 • 很多历史遗留坑 • 天灾人人祸 • 混杂的业务
V3.X时代持续发展结果
业务
边缘业务 可切换
机房一
机房二 数据同步
异地 机 房
V3.0 请求处理过程
Tair
①

Java Web 应用集群
tcp/ip nio
TFS Notify DB (Oracle) DB (MySQL) Alipay
随机 & 第七层路由
tddl jdbc
Java Center 应用集群
Sear-1 分布式存储
Ora-3e Ora-3e Ora-3e
Node
Node
Node 2
Node n
Ora-3e
Node 2 Read/Write …… Node Node 2
Node n Node n
V2.X 时代
CDN节点

①
主站
DNS Server（GSLB）
淘宝发展历程
V1.0 2003.5 - 2004.1
• 非非典时期，⻢马云住宅 • phpAuction
Fu4ct1o4 Fu4ct1o4 3 Fu4ct1o4 2 Apach/ Fu4ct1o4 Apach/ Apach/ 3od_php4 Apach/ 3od_php4 3od_php4 3od_php4 p/ar DB p/ar DB p/ar DB p/ar DB
服务 1
功能分组1
Node 1 Node
服务
功能分组
Node 1 Node
功能分组3
Node 1 Node
功能分组1
Node1
功能分组
Node1
Node
Node
……
Node n
……
Node n
……
Node n
……
Node n
……
Node n
统一一和隔离、负载均衡、私有云化
• • •
Notify - 消息中间件
Config Server
高高性能、可靠、可扩展
Notify Notify
可与发送端业务逻辑相 结合 支支持订阅者集群
Notify使 者 Subscriber
Notify Server Notify Server Notify Server
• • • •
Publisher
整体策略：三角角原则 CAP
效果 = 周⻓长 周⻓长和三个边⻓长为线性关系 成本 = 面面积 面面积和三个边⻓长成指数关系
成本
当边⻓长小小于某阀值 效果 = 最小小边⻓长度
关键点：最终一一致
• • •
基本可用用、软状态、最终一一致、ACID 分布式事务：放弃 ACID，选择 BASE 协同处理：放弃集中的紧耦合，异步消 息松耦合机制 数据存储：放弃成本高高昂的商用用集中存 储，选择可靠的分布式存储
• 支支持分库的数据框架DBRoute
cach-
Orac1Orac1-
Orac1Orac1-
dump
• 分布式缓存雏形，基于 • CDN
BDB
S-arch Read/Write N3dN3d…… 2
N3d2
⺴网网络的探索和初建
V2.2 2006.10 - 2007.12
• 从使用用技术开始创造技术
• 项⺫目目管理工工具 AntX • 引入入搜索引擎
ISearch
V2.1 2004.10 - 2007.1
……
• Weblogic • Weblogic • 抛弃
性能问题频现，成本高高 迁移至至 JBoss
EJB，引起 Spring
Fu2cti32 3 Fu2cti32 2 JB3ss Fu2cti32 JB3ss JB3ss 淘宝MVC JB3ss 淘宝MVC 淘宝MVC Spri2g 淘宝MVC Spri2g Spri2g OR-Mappi2g Spri2g OR-Mappi2g OR-Mappi2g OR-Mappi2g Read/Write
淘宝技术架构进化之路
龚银
ABOUT ME
大大家最关心心的问题
• 淘宝的前期技术发展历程 • 淘宝的当前技术体系 • 淘宝下一一代技术体系展望
What is
Architect?
架构， Architect
—— 好的架构是进化出来的，不是设计出来的！ —— 不同时期和不同环境有不同的最佳架构！ —— 存在即合理，合适的才是最好的！