去哪儿 (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[david.wu@tools1.ops.cn1 ~]$ 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 “解决将来的问题”• 好的架构匹配好的运维• 任何一项技术 / 架构的引进都需要一个痛苦的过程