去哪儿 (qunar)
DESCRIPTION
去哪儿 (qunar.com). David Wu. “去哪儿”简介. 中国领先的旅游媒体 2005 年 5 月上线 最大的旅游搜索引擎 机票,酒店,知道,博客,打折,签证,度假,景点 开始提供手机服务. 增长趋势. 数字. 35M 月访问用户 每天 60M 动态请求,峰值 1700+/sec 每天消息系统承载 30M 消息,峰值 1000/sec 每天 18M 次数据获取、网页解析 30G memcached data, 264M 次访问,峰值 7000/sec 5 0% 的数据能够在 3 s 内得到服务, 80% 的数据能在 8s 内提供服务. 数字. - PowerPoint PPT PresentationTRANSCRIPT
去哪儿 (qunar.com)
David Wu
“去哪儿”简介• 中国领先的旅游媒体
• 2005年 5月上线• 最大的旅游搜索引擎
• 机票,酒店,知道,博客,打折,签证,度假,景点
• 开始提供手机服务
增长趋势Search
数字• 35M月访问用户• 每天 60M动态请求,峰值 1700+/sec• 每天消息系统承载 30M消息,峰值 1000/
sec• 每天 18M次数据获取、网页解析• 30G memcached data, 264M次访问,峰值
7000/sec• 50%的数据能够在 3s内得到服务, 80%的数据能在 8s内提供服务
数字• 过去两年我们搜索量增长了 28倍• 技术团队从 10个人增长到 60个人• 产品线从 2个增长到 6个• 各种系统从 5个增长到近 30个
技术部门的使命• 实现–实现产品–给产品的实现更多的可能性
• 用户体验–可用性–速度
• 成本– Capex(固定资产投资) /opex(运营费用)–开发效率
系统演进的动力• 来源–流量的增长–产品需求的复杂化
• 发现的途径–监控–变更和发布记录–实现当中发现的问题–项目管理中发现的开发效率问题
高可用性• 3个 9: 99.9%– 2592秒 /月 =43分钟 /月– 2小时 /季度
• 4个 9: 99.99%
– 259秒 /月 =4.3 分钟 /月– 12.9分钟 /季度
一个故障
特定事情发生 服务质量不可接受故障发生
注意到故障并开始修复
修复结束
网站故障来源• 故障的来源–各种变更–访问量增长 (capacity planning)–人为操作失误–硬件、软件异常
监控• 监控分为两大类–监• 及时发现失效点• 关联关系
–控• 控制,就要有预先的概念• 保留历史记录,对可能出现的问题进行预判和预先改进• 在故障处理的时候,检查历史记录,找出变更对应的时间
对关联关系的看法• 个人认为使用服务方负责监控服务的质量和可用性–识别重要关联关系–对关联服务有质量标准,譬如成功率,延时等–制定报警标准–根据实际情况修正相关标准
层次
用户
业务
系统
共享基础设施
操作系统
设备
Qunar的监控系统• What’s up– 监控服务器存活状态– 监控 URL 存活状态
• Cacti– 监控服务器各项资源的使用情况– 丰富的 plugin
• Squid/memcached/netapp
– 保存历史记录,观察流量和各项资源的使用的关系• 要求 ops每天都需要浏览 cacti,每周全面审核
Qunar监控• Hyperic– Java–开源– 丰富的 plugin–可用的报警机制– 所有的业务、系统相关指标都在 hyperic
• Smokeping– Monitor机房到各省各个运营商的链路质量
经验
实施的步骤• 先从用户体验和业务入
手• 设备监控
• 系统、基础设施• 操作系统
经验• 每次发布完,团队要对所有的监控指标和系统图形观察 30分钟以后才算结束发布
• ops团队每天早上会对关键应用的指标进行快速 review
• Ops团队每周会对监控指标做快速巡查• 90% 以上的故障能通过监控系统发现
Xen
• 虚拟化– 70% 以上的生产服务器跑在 Xen上– 迁移方便–部署、管理简单–更高的使用率,平均 cpu使用率从 15%->45%
• OVM/Xen–有基于 web的管理界面– 剪裁比较好, 300M
Hardware
• CPU– 2x4 core
• Ram– 32G or 16G
• Disk– 2x500G, Raid 0+1,有些有带电池写 cache的
raid 卡• NIC– 2x1G, 1 for ilo
Xen
• Example[[email protected] ~]$ ssh l-ovms8.ops.cn1 'sudo /usr/sbin/xm list'Name ID Mem VCPUs State Time(s)112_tw6_f_cn1 2 2200 4 r----- 3097120.3114_tw7_f_cn1 3 2200 4 -b---- 3099024.2116_mem1_f_cn1 1 1700 4 -b---- 267107.3118_sug1_f_cn1 10 1200 4 -b---- 58702.3430_twb2_f_cn1_ovms8 9 2200 4 r----- 2283516.6434_askdb1_ovms8 11 2200 4 -b---- 60466.4Domain-0 0 668 8 r----- 1661065.3
问题• 性能– RAM/Syscall(context switch)– I/O performance
• Disk performance• Network performance(not so important in web
environment)
• 管理– Network structure(vlan tagging)– VMM层– Vm 之间隔离
RAM/Syscall
• Unixbench score• Raw 503• Dom-0 397• Dom-U 317
Dhrystone 2
using r
egist
er va
riables
Double-Prec
ision W
hetstone
Execl
Thro
ughput
Pipe Thro
ughput
Pipe-base
d Context S
witching
Proces
s Crea
tion
Shell
Scrip
ts (1 co
ncurre
nt)
Shell
Scrip
ts (8 co
ncurre
nt)
Syste
m Call O
verh
ead
Syste
m Bench
marks In
dex Sc
ore0
500
1000
1500
2000
2500
RawDom-0Dom-U
Unixbench score
Raw Dom-0 Dom-U0
100
200
300
400
500
600
System Benchmarks Index Score
System Benchmarks Index Score
Disk performance(with write buffer)
Bonnie++
Char write Block write Char read Block read0
10
20
30
40
50
60
70
80
Raw(with wb)Dom-0(with wb)Dom-U(with wb)
Disk performance(without write buffer)
Char write Block write Char read Block read0
10
20
30
40
50
60
70
80
Raw(without wb)Dom-0(without wb)Dom-U(without wb)
Disk performance(Random seek)
Random Seek0
20
40
60
80
100
120
140
160
180
Raw(with wb)Raw(without wb)Dom-0(with wb)Dom-0(without wb)Dom-U(with wb)Dom-U(without wb)
Vlan tagging
• 一个物理主机上要支持在多个 vlan的虚拟机– 规模扩大,单个网段无法满足需求– 安全分区需求
Xen
• In the future– Share storage/Live migration– Device pass-through– VMDq/VT-d/SR-IOV– Network structure optimization– Upgrade to Xen 4.0 to improve the performance
JAVA开发的一些 Tips
• 善用 jdk的命令– Jps– Jstat– Jmap– Jstack– jhat
tips
• 内存– OOM– GC并不能杜绝内存泄露– 仔细计算内存的使用,内存是有限的,给内存的使用一个上限
– Jhat可以帮助你看到你的内存用在什么地方–内存池化
tips
• 线程–线程数量是有限的– 所以减少线程数量是非常重要的– 减少数量意味着要缩短线程的长度–线程池化,降低创建和销毁线程的开销
tips
• Cache和 timeout 是互联网永恒的主题• 数字,数字,数字• 监控对于工程师,相当于雷达对于战斗机• 还可以更简单吗??• 如果不知道未来,那就不要为未来做准备• 性能(速度)象海绵,挤一挤总会有的• 去掉一个部件远比增加一个部件功劳大• 并发安全是魔鬼
一点体会• 共享基础设施比代码重用更加重要• 保持状态是扩展性的天敌• 团队的背景很大程度决定了架构的采用• “最好” vs “最合适”• “解决现在的问题” vs “解决将来的问题”• 好的架构匹配好的运维• 任何一项技术 / 架构的引进都需要一个痛苦的过程