去哪儿平台技术

“ 去哪儿”

Wednesday, April 12, 2023

1

David Wu

一、“去哪儿” 介绍

二、监控系统

三、虚拟化在去哪儿的应用

四、 Java 开发的一些 tips

一、“去哪儿” 介绍

“ 去哪儿”简介

• 中国领先的旅游媒体

• 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

JAVA 开发的一些 Tips

• 善用 jdk 的命令– Jps– Jstat– Jmap– Jstack– jhat

tips

• 内存– OOM– GC 并不能杜绝内存泄露–仔细计算内存的使用，内存是有限的，给内存

的使用一个上限– Jhat 可以帮助你看到你的内存用在什么地方– 内存池化

tips

• 线程– 线程数量是有限的–所以减少线程数量是非常重要的–减少数量意味着要缩短线程的长度– 线程池化，降低创建和销毁线程的开销

tips

• Cache 和 timeout是互联网永恒的主题• 数字，数字，数字• 监控对于工程师，相当于雷达对于战斗机• 还可以更简单吗？？• 如果不知道未来，那就不要为未来做准备• 性能（速度）象海绵，挤一挤总会有的• 去掉一个部件远比增加一个部件功劳大• 并发安全是魔鬼

一点体会

• 共享基础设施比代码重用更加重要• 保持状态是扩展性的天敌• 团队的背景很大程度决定了架构的采用• “ 最好” vs “ 最合适”• “ 解决现在的问题” vs “ 解决将来的问题”• 好的架构匹配好的运维• 任何一项技术 /架构的引进都需要一个痛苦

的过程

邮箱 : [email protected]

电话 : 13701172202