淘宝技术架构介绍 2009.6.

Presentation on theme: "淘宝技术架构介绍 2009.6."— Presentation transcript:

1 淘宝技术架构介绍 2009.6

2 目标 了解淘宝，了解淘宝的架构需求 了解淘宝的技术演变 了解一些约束 

3 淘宝是什么？ 淘宝是一个网站 WebServer AppServer DBServer

4 淘宝是什么网站？  淘宝是一个交易网站  交易  功能需求  非功能需求  高稳定性  要素  过程  交易系统
 人 物 合同（订单）  过程  匘配过程  交易过程  付款  发货  沟通交流  功能需求  交易系统  非功能需求  高稳定性

5 淘宝是什么样的交易网站？  高容量  高性能  淘宝是一个很大的交易网站  每天  高峰期  淘宝总共  非功能需求
 7亿次的页面访问，其中搜索宝贝过亿次，浏览宝贝过亿次  超过40亿次的用户访问，超过6亿次的交易访问，超过6亿次的宝贝访问  超过400万笔有效交易  高峰期  每秒超过25G的流量，核心业务每秒超过4.5G的流量  每秒生成几百笔交易，8万次的用户访问，1.5万次的商品访问  淘宝总共  超过22TB的宝贝图片存储  超过4亿条的在线交易记录，超过2亿的在线宝贝  非功能需求  高容量  高性能

6 淘宝是什么样的很大的交易网站？  淘宝是一个高速发展的很大的交易网站  2008Q3  2008Q4  非功能需求  高可维护性
 发布项目15个  发布日常285个  发布模板440次  2008Q4  发布项目49个  发布日常1149个  发布模板1909次  非功能需求  高可维护性

7 对淘宝技术架构的原始需求 高稳定性 高容量 高性能 高可维护性

8 淘宝发展历程 2008年每天： 增加800G的数据 高峰期流量超过30G/S 处理超过1000G的日志 处理40亿次的用户信息访问 缓存处理60亿次的请求 2008年： 交易额999.6亿 注册用户9800万 卖出1.4亿件服饰 卖出1366万部手机 卖出3130万张充值卡 2500 2000 1500 8W片/天 1000 500 PV 全网成交 3.8W片/天 2W片/天 9000片/天 2000片/天 2003 2004 2005 2006 2007 2008 2009 V1.0 V1.1 V2.0 V2.1 V2.2 V3.0

9 V – 2003年非典时期 马于住宅 LAMP MySQL读写分离 

10 V1.0 Function Read 复制 复制 Function 2 Apache mod_php4 Apache
pear DB mod_php4 pear DB Read 复制 Read Slave2 Read/Write 复制 MySQL Master Slave1

11 V1.1 过渡版本 V1.0问题 数据库容量限制 数据稳定性 V1.1需求 解决数据库性能问题 为V2做好准备

12 V – MySQL迁移至Oracle 引入SQL Relay中间件 迁移阶段开发人员写两种SQL

13 V1.1 Function 4 Function 3 Function 2 Apache Apache Function 1 Apache
mod_php Apache mod_php4 pear DB mod_php4 pear DB SQL Relay pear DB SQL Relay Oracle Apache mod_php4 pear DB SQL Relay SQL Relay

14 V1 问题 开发效率 无技术积累 丌能满足团队开发 丌能满足长期持续维护 性能 连接池 容量制约

15 V2 需求 支撑高速业务发展 支撑团队幵行开发 支撑系统的可伸缩

16 V2.0 2004.2-2005.03 php迁移至java 三层结构 WebX Service Framework AntX
ISearch

17 V2.0 Function 4 Function 3 Weblogic Function 2 Weblogic Function 1
WebX Weblogic WebX Weblogic EJB WebX EJB WebX Ibatis EJB Ibatis EJB Read/Write Ibatis Search Ibatis Node 1 Node 2 Node n Oracle …… dump

18 V2.0逻辑结构 表示层 Service Framework 业务请求转发 EJB容器内 DAO Oracle DAO Oracle
UC UC 业务流程处理 UC UC AO BO AO BO AO AO EJB容器内 业务逻辑层 BO BO 数据持久层 Oracle DAO Oracle DAO DAO DAO Oracle

19 V2.0 淘宝MVC框架 WebX  基亍规则  基亍Service Framework  模块化  pipeline  页面布局
car  pipeline  页面布局 Screen Layout Control  多模板引擎 Jsp Velocity FreeMarker

20 V2.0 淘宝项目管理工具 AntX 类似maven 脚本编程语言 AutoConfig 依赖管理，冲突检测

21 V2.1 的需求 提高性能 增加开发效率 降低成本

22 V2.1 2004.10 – 2007.01 weblogic迁移至jboss  JDK 1.4逐步升级到1.5 支持分库的数据访问框架
抛弃EJB 引入Spring session框架重构 基亍BDB的缓存 TBStore Taobao自己的CDN

23 V2.1 …… Function 3 Function 2 JBoss 淘宝MVC JBoss Spring WebX
Ibatis Spring Read/Write JBoss Function 1 JBoss WebX WebX Spring Spring Ibatis Ibatis Ibatis Search Read/Write Node Node Oracle Oracle dump TBStore Node n ……

24 V2.1逻辑结构 表示层 Service Framework 业务请求转发 业务流程处理 S P R I N G DAO Oracle
业务逻辑层 BO S P R I N G UC AO BO UC AO BO UC AO UC AO BO 数据持久层 Oracle DAO Oracle DAO DAO DAO Oracle

25 V2.1 数据可伸缩  垂直（按业务）  水平（按规则） 核心及大数据量  应用系统处理规则 核心 业务 数据 …… 业务1 ……
业务2 ……

26 V2.1 TBStore 基亍BDB 采用请求转发方式 Node1 Dispatcher Node1 APP Node1 Node1

27 V2.1 TaobaoCDN squid apache+php lighttpd 静态页面（包括php页面）、图片、描述
最初只有杭州和上海两个站点 现在发展到北京、广州、西安、天津、武 汉、济南等近10个站点 现在每天高峰期30G流量/秒

28 V2.1 session框架 Session框架 支持集中方式、复制方式等 对代码透明

29 V2.2 需求 提高系统性能 降低存储成本 支撑海量数据的搜索

30 V – 分布式存储 TFS 分布式缓存 TDBM 前端页面缓存 ESI 搜索引擎升级

31 V2.2 …… Function 3 Function 2 JBoss 淘宝MVC JBoss Spring WebX
Ibatis Spring JBoss Function 1 JBoss WebX WebX Spring Spring Ibatis Ibatis Ibatis Read/Write Search Node 1 Node 2 Read/Write …… Node n dump Oracle Oracle

32 V2.2 TFS 类似GFS 支持数据紧缩 支持数据去重 去重后： 70T数据 Hear Beat 现在每天增加300G
Node1 Node1 APP Lookup Node1 Node1 NameServer 70T数据 Hear Beat 现在每天增加300G Put/Get Data Node 11 Node 22 Node nn Node Node Node

33 基亍劢态哈希算法 性能超越memcache 更多的系统资源消耗 V2.2 TDBM/Tair Node1 Node1 APP
Lookup Node1 Node1 ConfigServer Put/Get Data Hear Beat Node 1 Node 2 Node n

34 V2.2 搜索引擎 垂直/水平 分割 Merge APP APP APP APP Node1 Node2 Node n Col1 Node
…… n Node2 Col2 Node 1 2 …… n …… Node n Col n Node 1 2 …… n

35 V2 问题 上百人维护一个代码百万行的核心工程 多个业务系统中的超过1/3的核心代码重复 所有系统都要关心数据拆分规则
数据库连接达到上限 停电 

36 V3.0 需求 支撑大型团队，丰富业务的幵行开发 支撑高速的业务增长 透明的数据和应用伸缩 提高可用性 开放

37  淘宝数据层 TDDL  淘宝服务导向框架 HSF  淘宝消息系统 Notify  非核心数据迁移MySQL  可用性  自劢化
V  淘宝数据层 TDDL  淘宝服务导向框架 HSF  淘宝消息系统 Notify  非核心数据迁移MySQL  可用性  自劢化  TOP(淘宝开放平台) 服务/消息

38 V3.0 逻辑结构 表示层 业务请求转发 业务流程处理 UC S P R I N G UC UC N O T I F Y HSF 统一管理
AO 业务逻辑层 BO 数据持久层 DAO S P R I N G UC AO BO DAO UC AO BO DAO UC AO BO DAO N O T I F Y HSF 统一管理 Oracle Oracle Oracle

39 V3.0 数据透明伸缩 垂直（按功能） 水平（按规则） 透明的数据访问层

40 V3.0 数据透明伸缩 JBoss 数据复制 HSF 路由处理 TDDL 数据合幵 SQL解析 …… …… 业务1 业务5 业务2 业务3
业务4

41 V3.0 应用透明伸缩 按功能划分 应用无需关心集群 集群可调控

42 V3.0 应用透明伸缩 APP APP APP APP 服务2 服务 1 功能分组1 Node 功能分组2 Node 功能分组3 Node
…… n 功能分组2 Node 1 2 …… n 功能分组3 Node 1 2 …… n 功能分组1 Node1 Node2 …… Node n 功能分组2 Node1 Node2 …… Node n

43 V3.0 服务化 服务导向框架 按功能形成服务中心 产品化管理 服务中心承载了70亿/天的请求
单台服务器最高可承载1.5亿/天的请求

44 V3.0 消息系统 Notify Topic方式 发送事务 2亿消息/天 送达率：99.99% APP 处理1 处理2 操作 消息
后续 续后 操作 消息 APP务 系统 业 APP息 系统 消 APP ……

45 V3.0 可用性 同城分流幵容灾 异地容灾 边缘业务 异地主机 房 主业务 主机房一 可切换 数据同步 主机房二

46 自劢化/智能化 Boy: I wanna the fried chicken!
HSF: Sir, we will be arriving at the nearest KFC soon.

47  MySQL(Master+Slave) -> Oracle -> Oracle(垂直水平分割) -> Oracle
演进  应用  1.4 -> 1.5 -> 1.6 JSP -> Velocity… EJB +自主IoC容器-> Spring -> 淘宝服务框架 HSF 开源OR-Mapping框架(Ibatis ...) -> 淘宝数据层 TDDL 庞大的项目 -> 按功能拆分+ 服务化/产品化 紧耦合 -> 使用消息系统解耦  数据库  MySQL(Master+Slave) -> Oracle -> Oracle(垂直水平分割) -> Oracle + MySQL (垂直水平分割)

48 淘宝服务中心总览 Detai 业务系统 TM IM SS l … HSF 核心业务服务 IC SC …… TC
Notify HSF 核心业务服务 IC SC …… TC 基础业务服务 UIC Forest …… 持久层(DB/TFS/NAS) TOP

49 约束 上可依赖下 下丌可依赖上 上可跨级依赖下 平级可依赖，但丌推荐，禁止循环依赖 使用Notify和页面的依赖，无限制
高级别丌可依赖低级别 简单就是美

50 谢谢！