Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo
淘宝技术专场 [email_address]
About  me 姓名 : 曾宪杰 花名 : 华黎 淘宝 - 产品技术 -Java 中间件团队 团队博客  http://rdc.taobao.com/team/jm/ Sina 微博  @ 曾宪杰 _ 华黎 Twitter @vanadies10
内容提要 淘宝网架构的变迁 基于 Java 技术的基础产品 业务中特色系统介绍
淘宝网的架构变迁
技术里程总览 V3  ( 2007.10-2009.11 ) 产品化的思维 做深,做精 服务导向的框架 应付多样化的业务 V4  ( 2009.8 - ) 系统化 智能化 专业化 V1.0  ( 2003.5 – 2004.5 ) 小而快的简单架构 V2.0  ( 2004.2 – 2008.3 ) 应付业务增长的层次化结构 开始有自己开发的软件技术
V1.0 :小而快   2003.5 – 2004.5
简介   2003 年非典时期 使用 LAMP 架构( Linux, Apache, MySql, Php) 业界流行的免费开源组合 使用改造过的一个商业软件 phpAuction ,以拍卖为主 简单的库表结构 用户,交易,列表,其他 简单的结构,但符合当时需求
V2.0 :多层次结构,开始做自己的软件   2004.2 – 2008.3
需求 业务发展快速 需要“较高”性能的架构(百万至千万用户级的架构) 团队并行开发 开始有小团队(几十人)做开发,开发效率必需考虑 系统的可伸缩 容易的扩容,增加机器
简介 应用中间件软件由 weblogic 迁移至 jboss 支持分库的数据访问框架 自主的淘宝分布式文件系统, TFS 自主的搜索引擎, iSearch 自主的缓存系统, TDBM Taobao 自己的 CDN CDN ( Content Delivery Network ),增进性能 因应业务的增多,用户的激增,架构也日趋多层化
问题  I 上百人维护一个代码百万行的核心工程 共享一个代码模块, Denali (虽然部署是分离的) 多个业务系统中的超过 1/3 的核心代码重复编写 V2 单一代码模块的设计( Denali ) 代码复杂难维护
问题  II 所有系统都要关心数据拆分规则 不必要的设计 数据库连接达到上限 (每个 Oracle 数据库大约提供 5000 个链接) 连接池是有限的资源 Oracle 数据库 太多的应用机器 有限的链接池 需要数据库连接
V3.0 :产品化思维及服务导向框架   2007.10-2009.11
需求 支撑大型团队,丰富业务的并行开发 软件模组化,中心化(用户,交易,商品,店铺,评价等),走向鬆耦合 基础软件产品化 独立团队开发,做深,做大 从盖独立别墅到建造高楼大厦! 支撑高速的业务增长 快速扩容 (几十亿 PV ,几千亿 GMV ,几万台机器) 提高可用性及管理性 走向 Always Available 对外开放
结构   数据和应用透明伸缩 非核心数据从 Oracle 迁移 MySQL 消息系统 服务框架和服务化 淘宝开放平台( TOP ) 运营支撑平台( TBoss ) 鬆耦合,服务导向的架构
V4.0 : 系统化、智能化、专业化   2009.8-
现状 系统化 把知识经验通过系统、平台进行沉淀,而不是总是人肉重复 智能化 从提供开关人工处理到系统自主决策 专业化 业务平台、技术平台的深耕 稳定性、性能的深入发展
技术里程回顾 V3  ( 2007.10-2009.11 ) 产品化的思维 做深,做精 服务导向的框架 应付多样化的业务 V4  ( 2009.8 - ) 系统化 智能化 专业化 V1.0  ( 2003.5 – 2004.5 ) 小而快的简单架构 V2.0  ( 2004.2 – 2008.3 ) 应付业务增长的层次化结构 开始有自己开发的软件技术
基于 Java 技术的基础产品
计算机组成 计算机硬件结构图  外存 内存 运算 器 控制 器 输入设备 输出设备 数据、程序  CPU 主机 数据、程序   数据、程序   冯 . 诺依曼型计算机
计算机系统的本质 数据处理 数据存储 数据访问
大型互联网 访问量很大? 数据量很大? 访问量和数据量需要都很大 核心是通过分布式系统解决前面提到的三个问题
网站结构示意图 LoadBalancer WebApp WebApp Service Service Cache 分布式存储 搜索 消息中间件 服务框架 CDN 数据层 DB 数据层 并行计算平台 DB DB(S) DB(S) 监控 运维平台
Web 框架 Webx 在阿里内部广泛使用的 MVC 框架 Turbine 风格 有很好的层次化、模块化,并且高度可扩展 基于 Webx 的无线应用自适应框架 Velocity 的编译优化
中间件 LoadBalancer WebApp WebApp Service Service Cache 分布式存储 搜索 消息中间件 服务框架 CDN 数据层 DB 数据层 并行计算平台 DB DB(S) DB(S) 监控 运维平台
服务框架 服务发布 服务查询 服务调用 服务治理
服务框架 07 年淘宝开始走向服务化 08 年初有多种 RPC 的方式 基于 SOCKET ,有多种不同实现 使用上不透明,成本高
服务框架 简单透明 ( 提供服务和使用服务 ) 支持软负载 灵活可控,方便扩展 稳定性支持
服务框架 调用者 服务提供者 调用者 服务提供者 服务注册查找中心
中间件 LoadBalancer WebApp WebApp Service Service Cache 分布式存储 搜索 消息中间件 服务框架 CDN 数据层 DB 数据层 并行计算平台 DB DB(S) DB(S) 监控 运维平台
消息中间件 Message-oriented middleware  ( MOM ) is software infrastructure focused on sending and receiving messages between distributed systems.   ---  from  wikipedia.org MOM 的优点 松耦合 异步处理
消息中间件 传统方式 使用消息中间件方式
消息中间件 业务系统完成一件事情后,需要其他系统进行处理的,通过定时程序来驱动 业务系统 Do something 业务 DB 定时程序 获取任务 Do action
消息中间件 Notify 是一个高性能、可靠、可扩展、可与发送端业务逻辑相结合、支持订阅者集群的消息中间件。 互联网时代的消息中间件 支持最终一致 消息可靠 支持订阅者集群
中间件 LoadBalancer WebApp WebApp Service Service Cache 分布式存储 搜索 消息中间件 服务框架 CDN 数据层 DB 数据层 并行计算平台 DB DB(S) DB(S) 监控 运维平台
数据层
数据层 User User1 User2 User1-M User2-M User2-S User1-S 分库分表 读写分离 数据库架构的演进
数据层 User1-M User2-M User2-S User1-S TAtomDataSource TGroupDataSource TDataSource 数据源的三层重构 业务可以灵活选择
数据层 SQL 解析,路由规则,数据合并 Client->DB 和 Client->Server->DB 模式 非对称数据复制 三层的数据源结构
LoadBalancer WebApp WebApp Service Service Cache 分布式存储 搜索 消息中间件 服务框架 CDN 数据层 DB 数据层 并行计算平台 DB DB(S) DB(S) 监控 运维平台
HBase 图来源于:  http://goo.gl/d1T3Q
HBase 基于 0.90.2 进行 扩展 运维页面; fix master 恢复时间过长的 bug ; fix backup master 不自动接管的 bug ; 避免 Region server 接到过大数据请求 OOM ; 完善 Table Balance ;
HBase etao : 100 台机器,目前已使用 60T ; 数据魔方: 10 台机器,目前已使用 500G+ ; 交易日志: 12 台机器,目前已使用 360G+ ; UDC : 8 台机器,目前已使用 600G+ ; 。。。。。。
LoadBalancer WebApp WebApp Service Service Cache 分布式存储 搜索 消息中间件 服务框架 CDN 数据层 DB 数据层 并行计算平台 DB DB(S) DB(S) 监控 运维平台
终搜架构
终搜特性列表 中心化的配置管理(非本地配置) 产品化 / 框架化,抽象物理模型(产品化,平台化) 多种 Dump 机制的支持,数据预处理机制 Taobao 化, HSF 、 ConfigServer 等淘宝自有技术的使用 Solr 外围扩展(不修改 Solr 代码,上层扩展) 支持实时搜索,实时时间 1s 内 产品化 / 框架化,抽象物理模型(产品化,平台化)
Hbase 应用在历史库的搜索上
LoadBalancer WebApp WebApp Service Service Cache 分布式存储 搜索 消息中间件 服务框架 CDN 数据层 DB 数据层 并行计算平台 DB DB(S) DB(S) 监控 运维平台
并行计算平台 基于 Hadoop 的云梯 1 系统 JobTracker 异步化 NameNode 优化 存储优化 小作业优化
并行计算平台 总容量 25.35PB,  利用率 55.2% 总共 1400+ 台机器 Master : 8CPU(HT) , 96GB 内存, SAS Raid Slave 节点异构 8CPU/8CPU(HT) 16G/24G 内存 1T x 12 / 2T x 6 / 1T x 6 SATA JBOD 12/20 slots 约 40000 道作业 / 天 ,  扫描数据:约 1.7PB/ 天 用户数 474 人 ,  用户组 38 个
并行计算平台 简化版的实现 方便部署、维护和管理 Master Worker Worker Worker
LoadBalancer WebApp WebApp Service Service Cache 分布式存储 搜索 消息中间件 服务框架 CDN 数据层 DB 数据层 并行计算平台 DB DB(S) DB(S) 监控 运维平台
CSP 业务架构
CSP 逻辑单元 逻辑单元 逻辑单元 逻辑单元 逻辑单元 收集 分析器 db 应用 系统 收集 分析器 db 收集 分析器 db 收集 分析器 db 收集 分析器 db 控制 服务 中心 应用 系统 应用 系统 应用 系统 应用 系统 应用 系统 应用 系统 应用 系统 应用 系统 应用 系统 应用 系统 应用 系统
CSP 的一些数据 平台化 15 台机器, 15 个库 APP 采用了逻辑单元的概念 ( 隔离 ) 采用 15 个逻辑单元对超过 200 多个系统进行监控 每日数据超过 5000 万 24 个系统进行容量规划 10 个系统进行依赖关系 6 个系统完成统一的保护开关部署
哈勃系统架构 整个系统分为“采集”,“分析报警”和“应用 ( 展现 )” 三个层次,实现了“采集”,“分析”,“报警”,“存储”和“展示”五大功能。
系统特点 超轻量级 HubAgent : HubAgent 是一个基于插件模式轻量级 HTTP 服务,可以通过增加插件的方式进行扩展,目前已提供“增量日志获取”,“外部程序(脚本)调用”,“进程 & 线程探测”,“端口探测”等多种服务。系统使用 Python 开发,不依赖第三方系统,可以安装在任何 linux 服务器上。 分布式的分析系统: . 分析系统使用 MapReduce 的编程模型,对大量的监控数据进行并行处理。系统将采用松耦合的 Master-Slave 模式, Master 处于被动状态,只负责任务的生成和合并,不需要关心任务分派。系统设计更加简单、灵活,通过增加 Slave 即可得到水平扩展能力。 Cassandra 数据存储: 系统使用 Cassandra 来实现大量监控数据的分布式存储, Cassandra 具有模式灵活,扩展性强,具有多维数据结构,支持范围查询等特点。而它“写入快,读取慢”的特性也恰好符合监控系统“写多读少”的特点,非常适合做监控数据的存储系统。
哈勃运行状况 应用情况 目前以接入包括主站和广告在内的 339  应用,配置了超过 1500 个任务和 3000 多张监控报表。能为应用的集群指标提供 30 天的明细数据,单机提供 7 天的明细数据;每小时的统计数据保存 1 年和每天的统计数据永久保存。 系统情况: HubAgent 已经安装超过 3500 台,基本覆盖了主站的应用服务器。 目前有 1 台 Master 服务器和 7 台 Slave 服务器用于数据分析。  master 的流量在 5Mbps , Slave 合计的平均网络流量 60Mbps (峰值 120Mbps ),平均每天处理约 4T 的原始数据。 目前有 5 台 Cassandra 服务器, 350G 左右的数据存储量,每天的数据增量在 25G 左右;保存了超过 18 万个监控指标。
LoadBalancer WebApp WebApp Service Service Cache 分布式存储 搜索 消息中间件 服务框架 CDN 数据层 DB 数据层 并行计算平台 DB DB(S) DB(S) 监控 运维平台
运维平台 部署 发布 监控 管理
LoadBalancer WebApp WebApp Service Service Cache 分布式存储 搜索 消息中间件 服务框架 CDN 数据层 DB 数据层 并行计算平台 DB DB(S) DB(S) 监控 运维平台
业务中特色系统介绍
SNS Feed 分发系统
整体结构 14 台 Consumer,  高峰支撑 1500W Feed 的分发 ,  下可线性扩展 10 台 Provider,  日均处理 3.5 亿次接口调用 ,  其中 Feed 查询接口为 1 亿 6 台 EntityCache,  主数据区占用 100G,  命中率在 90% 以上 12 台 IndexCache,  已使用 60G,  可保证不发生淘汰
核心流程
技术特点 Feed 查询 & 分发隔离 ,  分发核心处理异步化 Feed 查询和分发由不同的系统处理 ,  无强依赖 ,  主要通过 Cache 进行数据交换 分发主处理通过消息队列异步化 ,  提升对峰值的承受力 只分发 Feed 基本信息到关系用户 Feed 实体全局共享 ,  减少冗余带来的存储消耗 为用户建立独立的 FeedIndex,  存储分发到的 Feed 基本信息 按用户关系圈的大小选择不同的分发模式 关系圈小的采用推模式分发 ,  避免大量归并带来的查询 & 带宽瓶颈 关系圈大的热门用户采用拉模式 ,  避免由于需要推送的用户数过大造成系统消耗和延时 缓存和备份 针对热门用户总量不大 ,  信息读写比大的特点采用本地缓存 ,  提升性能 & 减少 IO 对用户 FeedIndex 采用专门集群存储 ,  从容量上保证其高命中率 利用 Cassandra 高写入特性进行 FeedIndex 准实时备份
商品排查系统
前端 Hadoop SST 查询 Zookeeper/DB 调度 处理中心 商品中心 生命周期 DFSProxy SST 排查 Job SSTBuildJob LifecycleMerge IVM-IFDL Common-Join MR-Job 数据源 生成指标 数据源 数据源 TimeTunnel  &&  XData  &&  淘宝数据集市  @ DW&BI 生命周期数据 实时监控 整体结构
运行状况 全量 每天从 30+ 数据源中加载 300GB 压缩或未压缩的数据,整理出 200+ 指标,对在线的 8E 商品做全量扫描,按照需求抓取出十万到百万级的商品做相应处理 实时 每天从千万数量级的调用中拦截处于与全量抓取的近似数量级具有潜在问题的行为,并作相应处理 生命周期 每天从各个数据源接收约 1.2E 条数据,保存 90 天共约 100E 记录数并提供实时检索,存储量为 2TB*3(replications)
CTU 系统
CTU 系统
运行状况 应用情况 目前运行接近 900 个 UDR 规则 (3000 个条件 /9000 个表达式 ) , 300 个 GDA 脚本规则 ; 日处理数据量 2 亿埋点 +2.5 亿 IM+20 亿 acookie 部署实时 BI 模型 5 个 系统情况: 应用流程监控点 100 个 , 基本覆盖 UGC 应用。 目前有 55 台分析服务器。
PMC 系统
整体结构
技术特点 流程虚拟机 流程执行事件化 Cache 流程数据 Groovy 动态调用 HSF 独立调度器,可分布式执行节点调用 图形化流程设计器
运行状况 Login 流程每天 3kw+ 淘宝营销报名流程每天 2w+ 汇金订购流程每天 10w+ 支付宝运营支撑审批流程每天 2w+ 后台审批流程每天上千笔
SHINE
整体架构 一个 Shine 的应用由服务自己的领域服务加上 Shine 平台上的资源构成。 Shine 平台负责页面的渲染,权限控制,调用服务等。
特点介绍 展现层的完整解决方案 开放灵活的组件系统 在线动态修改,发布 强大的在线 IDE 支持与各种类型的服务整合 HSF Spring Http 内建页面权限管理 应用版本化和备份工具支持
运行状况 应用数量 30 个,包括物流宝 ,  线下渠道 , PMC 流程引擎 ,  CTU, Hecla 等 页数数量超过 400 ,脚本数量 800 左右 客户包括淘宝客服,淘宝小二,卖家,合作伙伴
TOP
系统层次
系统部署
运行状况 2011 年 6 月 27 日 服务总访问: 11.1 亿 /day 服务有效访问: 10.24 亿 /day 成功访问: 9.82 亿 /day 上行数据流量: 1.2 T/day 独立用户数: 155w 业务平均处理时间  32ms 平台平均处理时间  5ms 有调用量的服务: 397 , 112 ( > 10w/day ), 18 ( >1000w ) 服务提供者系统错误率: 3‰ 开放平台系统错误率: 0.001‰ 有服务调用应用总数: 3.7 w 服务访问: 11600 (> 1w/day) , 57 (> 100w/day) , 10( > 1000w/day)
技术创新点 系统透明化 分布式分析器:抽象统计模型  +  反向任务调度  + MapReduce 控制台: Beta 发布  +  图形化监控  +  组合条件告警 ISV Monitor :监控外部 ISV 可用性,支持应用降级 服务速度及稳定性优化 LazyParser :自解析数据流,按需载入数据,节省机器资源和带宽 Pipe 化:业务降级,异步化处理基础 服务隔离: Web 请求异步化  +  业务权重线程池 Http 长连接推送:低消耗消息和内容外部推送 富客户端:多级缓存  +  布隆过滤器  + DB  实现数据层统一接口管理 黑名单及流控:多维度服务访问规则设置  +  实时数据分析结果 服务发布自动化 SDK 多语言自动生成及 Wiki 文档自动化生成 REST 服务与内部服务自动转化:支持复杂参数校验,参数映射,结果高效反序列化
淘数据
存储层 权限管理 基础平台 业务系统 统一访问门户( https://dw.taobao.ali.com ) 系统日志 WIKI MYSQL ( M/S ) 入口 应用层 框架层 UI Framework (YUI, TDC Common js framework) Web && business Framework (velocity 、 webx 、 spring) DB Persistent Framework (ibatis 、 hive 、 sshjdbc) HSF TFS SERVER TDC WEB Server Cluster ( 2 节点) dwsam ( 单节点 ) Apache + Jboss + Lucene 云梯 FTP JDBC SSH IDATA HSF XML ORACLE ( 4 节点) JDBC 全文搜索 自定义查询系统 报表系统 KPI 管理系统 数据质量监控系统 页面点击 卖家云图 路径分析 活动直播间 Redis ( M/S ) Jedis mstrweb IS1 IS2 BO web
运行状况 各类报表数量: 2342 个 专题分析子系统: 8 个 页面点击 page 数: 1218 个 15P 原始数据,日增 30T
广告实时结算系统
 
Thanks !

More Related Content

Java@taobao

  • 2. About me 姓名 : 曾宪杰 花名 : 华黎 淘宝 - 产品技术 -Java 中间件团队 团队博客 http://rdc.taobao.com/team/jm/ Sina 微博 @ 曾宪杰 _ 华黎 Twitter @vanadies10
  • 3. 内容提要 淘宝网架构的变迁 基于 Java 技术的基础产品 业务中特色系统介绍
  • 5. 技术里程总览 V3 ( 2007.10-2009.11 ) 产品化的思维 做深,做精 服务导向的框架 应付多样化的业务 V4 ( 2009.8 - ) 系统化 智能化 专业化 V1.0 ( 2003.5 – 2004.5 ) 小而快的简单架构 V2.0 ( 2004.2 – 2008.3 ) 应付业务增长的层次化结构 开始有自己开发的软件技术
  • 6. V1.0 :小而快 2003.5 – 2004.5
  • 7. 简介 2003 年非典时期 使用 LAMP 架构( Linux, Apache, MySql, Php) 业界流行的免费开源组合 使用改造过的一个商业软件 phpAuction ,以拍卖为主 简单的库表结构 用户,交易,列表,其他 简单的结构,但符合当时需求
  • 9. 需求 业务发展快速 需要“较高”性能的架构(百万至千万用户级的架构) 团队并行开发 开始有小团队(几十人)做开发,开发效率必需考虑 系统的可伸缩 容易的扩容,增加机器
  • 10. 简介 应用中间件软件由 weblogic 迁移至 jboss 支持分库的数据访问框架 自主的淘宝分布式文件系统, TFS 自主的搜索引擎, iSearch 自主的缓存系统, TDBM Taobao 自己的 CDN CDN ( Content Delivery Network ),增进性能 因应业务的增多,用户的激增,架构也日趋多层化
  • 11. 问题 I 上百人维护一个代码百万行的核心工程 共享一个代码模块, Denali (虽然部署是分离的) 多个业务系统中的超过 1/3 的核心代码重复编写 V2 单一代码模块的设计( Denali ) 代码复杂难维护
  • 12. 问题 II 所有系统都要关心数据拆分规则 不必要的设计 数据库连接达到上限 (每个 Oracle 数据库大约提供 5000 个链接) 连接池是有限的资源 Oracle 数据库 太多的应用机器 有限的链接池 需要数据库连接
  • 14. 需求 支撑大型团队,丰富业务的并行开发 软件模组化,中心化(用户,交易,商品,店铺,评价等),走向鬆耦合 基础软件产品化 独立团队开发,做深,做大 从盖独立别墅到建造高楼大厦! 支撑高速的业务增长 快速扩容 (几十亿 PV ,几千亿 GMV ,几万台机器) 提高可用性及管理性 走向 Always Available 对外开放
  • 15. 结构 数据和应用透明伸缩 非核心数据从 Oracle 迁移 MySQL 消息系统 服务框架和服务化 淘宝开放平台( TOP ) 运营支撑平台( TBoss ) 鬆耦合,服务导向的架构
  • 17. 现状 系统化 把知识经验通过系统、平台进行沉淀,而不是总是人肉重复 智能化 从提供开关人工处理到系统自主决策 专业化 业务平台、技术平台的深耕 稳定性、性能的深入发展
  • 18. 技术里程回顾 V3 ( 2007.10-2009.11 ) 产品化的思维 做深,做精 服务导向的框架 应付多样化的业务 V4 ( 2009.8 - ) 系统化 智能化 专业化 V1.0 ( 2003.5 – 2004.5 ) 小而快的简单架构 V2.0 ( 2004.2 – 2008.3 ) 应付业务增长的层次化结构 开始有自己开发的软件技术
  • 20. 计算机组成 计算机硬件结构图 外存 内存 运算 器 控制 器 输入设备 输出设备 数据、程序 CPU 主机 数据、程序 数据、程序 冯 . 诺依曼型计算机
  • 22. 大型互联网 访问量很大? 数据量很大? 访问量和数据量需要都很大 核心是通过分布式系统解决前面提到的三个问题
  • 23. 网站结构示意图 LoadBalancer WebApp WebApp Service Service Cache 分布式存储 搜索 消息中间件 服务框架 CDN 数据层 DB 数据层 并行计算平台 DB DB(S) DB(S) 监控 运维平台
  • 24. Web 框架 Webx 在阿里内部广泛使用的 MVC 框架 Turbine 风格 有很好的层次化、模块化,并且高度可扩展 基于 Webx 的无线应用自适应框架 Velocity 的编译优化
  • 25. 中间件 LoadBalancer WebApp WebApp Service Service Cache 分布式存储 搜索 消息中间件 服务框架 CDN 数据层 DB 数据层 并行计算平台 DB DB(S) DB(S) 监控 运维平台
  • 26. 服务框架 服务发布 服务查询 服务调用 服务治理
  • 27. 服务框架 07 年淘宝开始走向服务化 08 年初有多种 RPC 的方式 基于 SOCKET ,有多种不同实现 使用上不透明,成本高
  • 28. 服务框架 简单透明 ( 提供服务和使用服务 ) 支持软负载 灵活可控,方便扩展 稳定性支持
  • 29. 服务框架 调用者 服务提供者 调用者 服务提供者 服务注册查找中心
  • 30. 中间件 LoadBalancer WebApp WebApp Service Service Cache 分布式存储 搜索 消息中间件 服务框架 CDN 数据层 DB 数据层 并行计算平台 DB DB(S) DB(S) 监控 运维平台
  • 31. 消息中间件 Message-oriented middleware  ( MOM ) is software infrastructure focused on sending and receiving messages between distributed systems. --- from wikipedia.org MOM 的优点 松耦合 异步处理
  • 35. 中间件 LoadBalancer WebApp WebApp Service Service Cache 分布式存储 搜索 消息中间件 服务框架 CDN 数据层 DB 数据层 并行计算平台 DB DB(S) DB(S) 监控 运维平台
  • 37. 数据层 User User1 User2 User1-M User2-M User2-S User1-S 分库分表 读写分离 数据库架构的演进
  • 38. 数据层 User1-M User2-M User2-S User1-S TAtomDataSource TGroupDataSource TDataSource 数据源的三层重构 业务可以灵活选择
  • 39. 数据层 SQL 解析,路由规则,数据合并 Client->DB 和 Client->Server->DB 模式 非对称数据复制 三层的数据源结构
  • 40. LoadBalancer WebApp WebApp Service Service Cache 分布式存储 搜索 消息中间件 服务框架 CDN 数据层 DB 数据层 并行计算平台 DB DB(S) DB(S) 监控 运维平台
  • 41. HBase 图来源于: http://goo.gl/d1T3Q
  • 42. HBase 基于 0.90.2 进行 扩展 运维页面; fix master 恢复时间过长的 bug ; fix backup master 不自动接管的 bug ; 避免 Region server 接到过大数据请求 OOM ; 完善 Table Balance ;
  • 43. HBase etao : 100 台机器,目前已使用 60T ; 数据魔方: 10 台机器,目前已使用 500G+ ; 交易日志: 12 台机器,目前已使用 360G+ ; UDC : 8 台机器,目前已使用 600G+ ; 。。。。。。
  • 44. LoadBalancer WebApp WebApp Service Service Cache 分布式存储 搜索 消息中间件 服务框架 CDN 数据层 DB 数据层 并行计算平台 DB DB(S) DB(S) 监控 运维平台
  • 46. 终搜特性列表 中心化的配置管理(非本地配置) 产品化 / 框架化,抽象物理模型(产品化,平台化) 多种 Dump 机制的支持,数据预处理机制 Taobao 化, HSF 、 ConfigServer 等淘宝自有技术的使用 Solr 外围扩展(不修改 Solr 代码,上层扩展) 支持实时搜索,实时时间 1s 内 产品化 / 框架化,抽象物理模型(产品化,平台化)
  • 48. LoadBalancer WebApp WebApp Service Service Cache 分布式存储 搜索 消息中间件 服务框架 CDN 数据层 DB 数据层 并行计算平台 DB DB(S) DB(S) 监控 运维平台
  • 49. 并行计算平台 基于 Hadoop 的云梯 1 系统 JobTracker 异步化 NameNode 优化 存储优化 小作业优化
  • 50. 并行计算平台 总容量 25.35PB, 利用率 55.2% 总共 1400+ 台机器 Master : 8CPU(HT) , 96GB 内存, SAS Raid Slave 节点异构 8CPU/8CPU(HT) 16G/24G 内存 1T x 12 / 2T x 6 / 1T x 6 SATA JBOD 12/20 slots 约 40000 道作业 / 天 , 扫描数据:约 1.7PB/ 天 用户数 474 人 , 用户组 38 个
  • 52. LoadBalancer WebApp WebApp Service Service Cache 分布式存储 搜索 消息中间件 服务框架 CDN 数据层 DB 数据层 并行计算平台 DB DB(S) DB(S) 监控 运维平台
  • 54. CSP 逻辑单元 逻辑单元 逻辑单元 逻辑单元 逻辑单元 收集 分析器 db 应用 系统 收集 分析器 db 收集 分析器 db 收集 分析器 db 收集 分析器 db 控制 服务 中心 应用 系统 应用 系统 应用 系统 应用 系统 应用 系统 应用 系统 应用 系统 应用 系统 应用 系统 应用 系统 应用 系统
  • 55. CSP 的一些数据 平台化 15 台机器, 15 个库 APP 采用了逻辑单元的概念 ( 隔离 ) 采用 15 个逻辑单元对超过 200 多个系统进行监控 每日数据超过 5000 万 24 个系统进行容量规划 10 个系统进行依赖关系 6 个系统完成统一的保护开关部署
  • 56. 哈勃系统架构 整个系统分为“采集”,“分析报警”和“应用 ( 展现 )” 三个层次,实现了“采集”,“分析”,“报警”,“存储”和“展示”五大功能。
  • 57. 系统特点 超轻量级 HubAgent : HubAgent 是一个基于插件模式轻量级 HTTP 服务,可以通过增加插件的方式进行扩展,目前已提供“增量日志获取”,“外部程序(脚本)调用”,“进程 & 线程探测”,“端口探测”等多种服务。系统使用 Python 开发,不依赖第三方系统,可以安装在任何 linux 服务器上。 分布式的分析系统: . 分析系统使用 MapReduce 的编程模型,对大量的监控数据进行并行处理。系统将采用松耦合的 Master-Slave 模式, Master 处于被动状态,只负责任务的生成和合并,不需要关心任务分派。系统设计更加简单、灵活,通过增加 Slave 即可得到水平扩展能力。 Cassandra 数据存储: 系统使用 Cassandra 来实现大量监控数据的分布式存储, Cassandra 具有模式灵活,扩展性强,具有多维数据结构,支持范围查询等特点。而它“写入快,读取慢”的特性也恰好符合监控系统“写多读少”的特点,非常适合做监控数据的存储系统。
  • 58. 哈勃运行状况 应用情况 目前以接入包括主站和广告在内的 339 应用,配置了超过 1500 个任务和 3000 多张监控报表。能为应用的集群指标提供 30 天的明细数据,单机提供 7 天的明细数据;每小时的统计数据保存 1 年和每天的统计数据永久保存。 系统情况: HubAgent 已经安装超过 3500 台,基本覆盖了主站的应用服务器。 目前有 1 台 Master 服务器和 7 台 Slave 服务器用于数据分析。 master 的流量在 5Mbps , Slave 合计的平均网络流量 60Mbps (峰值 120Mbps ),平均每天处理约 4T 的原始数据。 目前有 5 台 Cassandra 服务器, 350G 左右的数据存储量,每天的数据增量在 25G 左右;保存了超过 18 万个监控指标。
  • 59. LoadBalancer WebApp WebApp Service Service Cache 分布式存储 搜索 消息中间件 服务框架 CDN 数据层 DB 数据层 并行计算平台 DB DB(S) DB(S) 监控 运维平台
  • 60. 运维平台 部署 发布 监控 管理
  • 61. LoadBalancer WebApp WebApp Service Service Cache 分布式存储 搜索 消息中间件 服务框架 CDN 数据层 DB 数据层 并行计算平台 DB DB(S) DB(S) 监控 运维平台
  • 64. 整体结构 14 台 Consumer, 高峰支撑 1500W Feed 的分发 , 下可线性扩展 10 台 Provider, 日均处理 3.5 亿次接口调用 , 其中 Feed 查询接口为 1 亿 6 台 EntityCache, 主数据区占用 100G, 命中率在 90% 以上 12 台 IndexCache, 已使用 60G, 可保证不发生淘汰
  • 66. 技术特点 Feed 查询 & 分发隔离 , 分发核心处理异步化 Feed 查询和分发由不同的系统处理 , 无强依赖 , 主要通过 Cache 进行数据交换 分发主处理通过消息队列异步化 , 提升对峰值的承受力 只分发 Feed 基本信息到关系用户 Feed 实体全局共享 , 减少冗余带来的存储消耗 为用户建立独立的 FeedIndex, 存储分发到的 Feed 基本信息 按用户关系圈的大小选择不同的分发模式 关系圈小的采用推模式分发 , 避免大量归并带来的查询 & 带宽瓶颈 关系圈大的热门用户采用拉模式 , 避免由于需要推送的用户数过大造成系统消耗和延时 缓存和备份 针对热门用户总量不大 , 信息读写比大的特点采用本地缓存 , 提升性能 & 减少 IO 对用户 FeedIndex 采用专门集群存储 , 从容量上保证其高命中率 利用 Cassandra 高写入特性进行 FeedIndex 准实时备份
  • 68. 前端 Hadoop SST 查询 Zookeeper/DB 调度 处理中心 商品中心 生命周期 DFSProxy SST 排查 Job SSTBuildJob LifecycleMerge IVM-IFDL Common-Join MR-Job 数据源 生成指标 数据源 数据源 TimeTunnel && XData && 淘宝数据集市 @ DW&BI 生命周期数据 实时监控 整体结构
  • 69. 运行状况 全量 每天从 30+ 数据源中加载 300GB 压缩或未压缩的数据,整理出 200+ 指标,对在线的 8E 商品做全量扫描,按照需求抓取出十万到百万级的商品做相应处理 实时 每天从千万数量级的调用中拦截处于与全量抓取的近似数量级具有潜在问题的行为,并作相应处理 生命周期 每天从各个数据源接收约 1.2E 条数据,保存 90 天共约 100E 记录数并提供实时检索,存储量为 2TB*3(replications)
  • 72. 运行状况 应用情况 目前运行接近 900 个 UDR 规则 (3000 个条件 /9000 个表达式 ) , 300 个 GDA 脚本规则 ; 日处理数据量 2 亿埋点 +2.5 亿 IM+20 亿 acookie 部署实时 BI 模型 5 个 系统情况: 应用流程监控点 100 个 , 基本覆盖 UGC 应用。 目前有 55 台分析服务器。
  • 75. 技术特点 流程虚拟机 流程执行事件化 Cache 流程数据 Groovy 动态调用 HSF 独立调度器,可分布式执行节点调用 图形化流程设计器
  • 76. 运行状况 Login 流程每天 3kw+ 淘宝营销报名流程每天 2w+ 汇金订购流程每天 10w+ 支付宝运营支撑审批流程每天 2w+ 后台审批流程每天上千笔
  • 77. SHINE
  • 78. 整体架构 一个 Shine 的应用由服务自己的领域服务加上 Shine 平台上的资源构成。 Shine 平台负责页面的渲染,权限控制,调用服务等。
  • 79. 特点介绍 展现层的完整解决方案 开放灵活的组件系统 在线动态修改,发布 强大的在线 IDE 支持与各种类型的服务整合 HSF Spring Http 内建页面权限管理 应用版本化和备份工具支持
  • 80. 运行状况 应用数量 30 个,包括物流宝 , 线下渠道 , PMC 流程引擎 , CTU, Hecla 等 页数数量超过 400 ,脚本数量 800 左右 客户包括淘宝客服,淘宝小二,卖家,合作伙伴
  • 81. TOP
  • 84. 运行状况 2011 年 6 月 27 日 服务总访问: 11.1 亿 /day 服务有效访问: 10.24 亿 /day 成功访问: 9.82 亿 /day 上行数据流量: 1.2 T/day 独立用户数: 155w 业务平均处理时间 32ms 平台平均处理时间 5ms 有调用量的服务: 397 , 112 ( > 10w/day ), 18 ( >1000w ) 服务提供者系统错误率: 3‰ 开放平台系统错误率: 0.001‰ 有服务调用应用总数: 3.7 w 服务访问: 11600 (> 1w/day) , 57 (> 100w/day) , 10( > 1000w/day)
  • 85. 技术创新点 系统透明化 分布式分析器:抽象统计模型 + 反向任务调度 + MapReduce 控制台: Beta 发布 + 图形化监控 + 组合条件告警 ISV Monitor :监控外部 ISV 可用性,支持应用降级 服务速度及稳定性优化 LazyParser :自解析数据流,按需载入数据,节省机器资源和带宽 Pipe 化:业务降级,异步化处理基础 服务隔离: Web 请求异步化 + 业务权重线程池 Http 长连接推送:低消耗消息和内容外部推送 富客户端:多级缓存 + 布隆过滤器 + DB 实现数据层统一接口管理 黑名单及流控:多维度服务访问规则设置 + 实时数据分析结果 服务发布自动化 SDK 多语言自动生成及 Wiki 文档自动化生成 REST 服务与内部服务自动转化:支持复杂参数校验,参数映射,结果高效反序列化
  • 87. 存储层 权限管理 基础平台 业务系统 统一访问门户( https://dw.taobao.ali.com ) 系统日志 WIKI MYSQL ( M/S ) 入口 应用层 框架层 UI Framework (YUI, TDC Common js framework) Web && business Framework (velocity 、 webx 、 spring) DB Persistent Framework (ibatis 、 hive 、 sshjdbc) HSF TFS SERVER TDC WEB Server Cluster ( 2 节点) dwsam ( 单节点 ) Apache + Jboss + Lucene 云梯 FTP JDBC SSH IDATA HSF XML ORACLE ( 4 节点) JDBC 全文搜索 自定义查询系统 报表系统 KPI 管理系统 数据质量监控系统 页面点击 卖家云图 路径分析 活动直播间 Redis ( M/S ) Jedis mstrweb IS1 IS2 BO web
  • 88. 运行状况 各类报表数量: 2342 个 专题分析子系统: 8 个 页面点击 page 数: 1218 个 15P 原始数据,日增 30T
  • 90.  

Editor's Notes

  1. 每日承载接近 200 亿次的调用
  2. 基于 BDB JE 的存储系统 消息中间件自己的存储系统
  3. 1. M×N 的部署结构 2. 配置的中心化管理 3. 运行时的服务动态调整(新增服务,修改机器角色等) 4. 数据 Dump 逻辑和索引构建逻辑的分离(解耦)
  4. 中心化的配置管理, ZK 发布配置文件 抽象出通用化模型,产品化 Dump 机制,分为 client Dump (应用方控制)和 Server Dump( 终搜控制 ) 支持三十多个业务系统
  5. 中心化的配置管理, ZK 发布配置文件 抽象出通用化模型,产品化 Dump 机制,分为 client Dump (应用方控制)和 Server Dump( 终搜控制 ) 支持三十多个业务系统
  6. 中心化的配置管理, ZK 发布配置文件 抽象出通用化模型,产品化 Dump 机制,分为 client Dump (应用方控制)和 Server Dump( 终搜控制 ) 支持三十多个业务系统
  7. 其实监控系统有个特点,就是被监控的系统他们的关系是完全独立的 由于该系统中没有出现需要集中式的数据,所以采用完全分布式方案 1 、充分利用 db 和应用的特性,将 db 也部署在 appserver 上 2 、收集 app 、 db 、被监控系统的关联完全控制服务中心控制
  8. Issue Feature Defination
  9. Counter-Terrorist Unit
  10. 功能模块
  11. 节点调度器,调度节点运行,节点就是人物