Detail 静态化 (淘宝动态系统的静态化改造实践) —— 淘宝君山

34
1 Detail 静静静 静静静静静 静静静静静静静静 —— 静静静静 1

description

Detail 静态化 (淘宝动态系统的静态化改造实践) —— 淘宝君山. 1. 花名:君山 真名:许令波 博客: http://xulingbo.net 微博: http://weibo.com/u/1855869382 简介: 2009 加入淘宝,一直在做 Detail 系统的性能优化方面 的工作,研究过 Cassandra 、开发过一个 sketch 模板 引擎、给 developerworks 投稿 , 出版 《 深入分析 Java Web 技术内幕 》 。 部门:交交易中心 - 导购 - 商品详情 所在团队:小凡、济城、大仁、常彬、旭天、君山. - PowerPoint PPT Presentation

Transcript of Detail 静态化 (淘宝动态系统的静态化改造实践) —— 淘宝君山

1

Detail 静态化(淘宝动态系统的静态化改造实践)

—— 淘宝君山

1

2

花名:君山真名:许令波博客: http://xulingbo.net微博: http://weibo.com/u/1855869382简介: 2009 加入淘宝,一直在做 Detail 系统的性能优化方面 的工作,研究过 Cassandra 、开发过一个 sketch 模板 引擎、给 developerworks 投稿 , 出版《深入分析Java Web 技术内幕》。部门:交交易中心 - 导购 - 商品详情所在团队:小凡、济城、大仁、常彬、旭天、君山

2

Detail 系统( http://item.taobao.com )

3

Detail 系统是个什么样的系统—业务上

占有整个淘宝 90% 的 PV 超过 70% 的成交是从 Detail 页发起的 淘宝最重要的系统之一、是买家达成购买意向的关键路径 唯一详细商品展示信息的地方 卖家可以随意装修和编辑商品的描述

4

Detail 系统性能数据

淘宝访问量最高的系统 PV : 5 亿 / 每秒 1.8w UV : 3100 万(其中直接登录用户 1700 万)

淘宝单个应用占用最多机器的系统 300 台 vm

动态系统中性能最好的系统 最大 350QPS RT30ms

对外峰值带宽: 4.03Gbps 平均页面压缩前 108k 、压缩后 28k

5

面临的挑战

6

面临的挑战• 网站经常受到攻击• 双 11/ 双 12 的大型促销活动• 秒杀 / 活动等突发流量冲击• 各种爬虫频繁抓取数

7

Detail 系统的优化历程 前端优化

assets 合并 整合页面中 inline 的 js\css combo 合并 css 、 js 文件 BigRender (使用 textarea ,控制浏览器渲染节奏)

服务端优化 将 iframe 改为 jsonp 调用 建立异步系统 ( JS 触发加载) Velocity 模板优化( sketch 框架) 逐步去除 DB 依赖(各个 C 走 Tair 缓存)

网络优化 TCP 初始拥塞窗口优化 去除空格、 TAB 压缩字符串,减少页面大小

终极优化(静态化)8

主要内容

什么是静态化 为什么要静态化 系统改造方案选择 动态系统如何改造 要让页面与浏览者无关、与时间无关、与地域无关、页面内容如何动

静分离? 页面如何缓存 页面怎么缓存?用什么软件缓存?是在 HTTP层做缓存还是在应用层

做缓存? 如何失效 是整体失效还是局部失效?主动失效 or被动失效?失效策略如何选择,如何保持数据一致性

9

什么是静态化

一个页面的 URL固定,不同的 URL表示不同的内容,让返回的请求之和 URL相关

去掉页面中浏览者因素 去掉页面中的时间因素 去掉页面中地域因素 去除 Cookie 等私有数据

10

为什么要静态化

动态系统的 QPS 有瓶颈1. Java

• CPU运算( Java 字符串查找、替换、拼接、锁、压缩、解压缩等)

• 元数据获取的网络开销2. Web 服务器

• 模块过滤( atpanel pv 、 acookie打点、简繁转换)• 大 HTML(100K 以上 ) 的 Gzip 压缩

淘宝的突发流量1. 攻击2. 秒杀3. 双 11/ 双 12 ( 21w/QPS )

性能已经不能再得到大的提升了

11

当前的 Detail 架构面临的技术挑战

当前的 Detail 架构已经达到瓶颈 能使用缓存的地方已经使用了 服务端的 CPU瓶颈能优化的基本已经优化(模板、压缩)

Java 系统的性能瓶颈 不擅长处理大量连接( NIO事件驱动较弱) 网络数据传输较差(数据需要在内核和用户态直接切换) Servlet容器也有性能瓶颈

实际测试最多只能支撑 500QPS

12

Detail必须要有新的架构

改变缓存方式 直接缓存 Http

改变缓存的地方 直接基于Web 服务器换 屏蔽业务逻辑(值根据 URL )

基本原则 保证易维护性 没有单点 缓存足够大

13

Detail新架构方案选择

14

Jboss

Detail新结构Detail新结构LB(A10)|LVS

主动渲染(二期)

Nginx Nginx

Varnish Varnish

Jboss Jboss Jboss

现有渲染逻辑

Tair整页缓存

各个中心Cache

360台Jboss360台Jboss

动态页面静态化动态页面静态化

主动put

主动put

渲染渲染

HTML页面

一级Cache一级Cache

二级Cache二级Cache

90台90台

动态内容填充

方案选择的关键因素

15

是否一致性 Hash 分组? 是否使用 ESI? 是否使用物理机? 谁来压缩 ? 网卡选择

改造方案一 Nginx+Varnish 前置( 20台)

16

优点与 Java 应用隔离,方便 PE维护 大内存,缓存集中管理命令率高(性能提升=1/(1-命中率 ) )

缺点 内部交换网络成为瓶颈 CPU也会成为瓶颈( Gzip 压缩) 缓存服务器的网卡也会是瓶颈 机器少风险较大

改造方案二 Nginx+Varnish+Jboss ( vm )

优点没有网络瓶颈,不需要改造网络 机器增加,也没有网卡瓶颈 机器数增多故障风险减少

缺点 机器增加,缓存命中率下降 缓存分散,失效难度增加 · Varnish 和 Jboss都会争抢内存

改造方案三 Nginx+Varnish+Jboss( 实体 )

18

实体机和虚拟机对比 实体机是虚拟机的 3倍

中庸之美既没有网络瓶颈也能使用大内存 减少 Varnish 机器,提升命中率提升命中率,能减少 Gzip 压缩 减少 CC失效压力

临时方案(双 12 )让 Varnish 压缩,解除 CPU瓶颈(采用 Java 实现 Beacon打点)

采用 CSI 渲染动态数据(目前采用 Varnish 的 ESI填充动态数据)

系统的改造点(动态系统静态化)

URL 是否单一( get参数) 去点 post表单 Cookie不影响业务逻辑

19

系统的改造点(动态内容异步化)

URL固定( /item.htm?id=xxxx ) 去掉浏览者相关

Atpanel打点 用户 id 等 Cookie 信息

去掉时间相关定时上架 秒杀

去掉地域相关 运费模板

20

系统的改造点(动态内容格式化)

ViewData (浏览者相关的数据) ItemData (商品相关的数据)

21

缓存选择 Varnish

为什么没选择 Nginx Nginx 使用硬盘缓存 RT 和 Load 波动不稳定,不能发挥缓存优势

优点与其他缓存软件相比,直接在 Http层做缓存,不需要额外的协议解析,和复杂的逻辑

与其他 Http层软件相比, Varnish 性能更好,使用方便、维护简单

支持 ESI 有大型网站都在使用( Facebook 静态资源)

缺点 淘宝没有运维经验

22

322 436 690 390 377 260 163 126 110 96 83 480

50

100

150

200

250

300

350

Varnish_load Nginx_load Varnish_RT Nginx_RT

失效方案——结构

23

失效方案——方式

主动失效 Cc监控 修改 jbossctl , jboss 重启同时重启 varnish Vm 模板发布重启 Varnish

被动失效 Varnish设置缓存时间一小时 浏览器端设置 3 秒( lastModify ) 后台操作管理界面

24

失效方案——技术难点

每秒要失效的数据量大 IC 每秒 4000 , SC没有 50延时、去重、批量失效

要失效的 Varnish 多当前有 260 台,那么每秒要发送 104w/s 的请求( 20 台

CC )采用基于 Keepalive 的长连接(单台 6w/s 的 http请求)

CC 性能调优 Mina 内存泄露 多线程操作 load不稳定

Varnish 调优 修改 Error 的长连接机制 大内存写磁盘问题 Stat-out 问题

25

失效方案——失效 Varnish 缓存

Purge 走 Http协议,性能非常好不能做正则匹配,失效方式单一 改造了 Varnish 的 keeplive 机制

Ban 可以使用正则表达时匹配缓存的 key 性能差

26

Varnish 机器数与命中率的关系

提供缓存的机器数和每台机器的命中率有直接关系机器数与命中率关系

27

命中率与性能提升的关系

性能提升=1/(1-命中率 )命中率达到 50% ,则当前的性能为之前的 2倍命中率达到 90% ,当前性能为之前的 10倍命中率达到 99% ,性能为之前的 100倍缓存的最大性能受制约于缓存之后的性能

28

谁做压缩

29

• Jboss 做压缩– 内部流量可以减少– Java 压缩不能充分发挥多 CPU 的优势,性能较差– 加长 RT ,影响正常用户请求– 前端 Nginx不能做动态插入

• Varnish 做压缩– Varnish 到 Jboss会存在内部流量– Varnish 做 ESI解析时需要解压– 前端 Nginx不能做动态插入

• Nginx/Apache 做压缩– 增加内部网络流量– 可以做动态插入

静态化成果

30

• 一次实际攻击

• QPS 是平时的 20倍( 20w/s )

静态化成果

31

• Varnish命中率非常高• 响应时间下降• Load正常

静态化成果

32

• 这次攻击如果不是静态化, Detail肯定挂• TMD生效要一个小时• PE手工操作至少要 10 分钟• 如果按照 10 分钟计算,淘宝要损失多少money• 而这次攻击,我们可以淡定的去吃晚饭(:

感谢所有项目组成员

33

开发:小凡、大仁、常彬、君山、济城前端:渐飞、释然功能测试:红泪、雪倾、纯纯、鸾伽、周叶林性能测试:静枫、悟石Varnish&Nginx:文景、叔度精卫:齐昊、朔海、誓嘉、银时Tair:仇天、宗岱PE:普智、胜衣、空智scm:红巾SC:铁威、单通IC:杜琨、逐流

34