1 / 33

去哪儿 (qunar)

去哪儿 (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 内提供服务. 数字.

cameron-sellers
Download Presentation

去哪儿 (qunar)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 去哪儿(qunar.com) David Wu

  2. “去哪儿”简介 • 中国领先的旅游媒体 • 2005年5月上线 • 最大的旅游搜索引擎 • 机票，酒店，知道，博客，打折，签证，度假，景点 • 开始提供手机服务

  3. 增长趋势

  4. 数字 • 35M月访问用户 • 每天60M动态请求，峰值1700+/sec • 每天消息系统承载30M消息，峰值1000/sec • 每天18M次数据获取、网页解析 • 30G memcacheddata, 264M次访问，峰值7000/sec • 50%的数据能够在3s内得到服务，80%的数据能在8s内提供服务

  5. 数字 • 过去两年我们搜索量增长了28倍 • 技术团队从10个人增长到60个人 • 产品线从2个增长到6个 • 各种系统从5个增长到近30个

  6. 技术部门的使命 • 实现 • 实现产品 • 给产品的实现更多的可能性 • 用户体验 • 可用性 • 速度 • 成本 • Capex（固定资产投资）/opex（运营费用） • 开发效率

  7. 系统演进的动力 • 来源 • 流量的增长 • 产品需求的复杂化 • 发现的途径 • 监控 • 变更和发布记录 • 实现当中发现的问题 • 项目管理中发现的开发效率问题

  8. 高可用性 • 3个9：99.9% • 2592秒/月=43分钟/月 • 2小时/季度 • 4个9：99.99% • 259秒/月=4.3分钟/月 • 12.9分钟/季度

  9. 一个故障 特定事情发生 服务质量 不可接受 故障发生 注意到故障 并开始修复 修复结束

  10. 网站故障来源 • 故障的来源 • 各种变更 • 访问量增长(capacity planning) • 人为操作失误 • 硬件、软件异常

  11. 监控 • 监控分为两大类 • 监 • 及时发现失效点 • 关联关系 • 控 • 控制，就要有预先的概念 • 保留历史记录，对可能出现的问题进行预判和预先改进 • 在故障处理的时候，检查历史记录，找出变更对应的时间

  12. 对关联关系的看法 • 个人认为使用服务方负责监控服务的质量和可用性 • 识别重要关联关系 • 对关联服务有质量标准，譬如成功率，延时等 • 制定报警标准 • 根据实际情况修正相关标准

  13. 层次

  14. Qunar的监控系统 • What’s up • 监控服务器存活状态 • 监控URL存活状态 • Cacti • 监控服务器各项资源的使用情况 • 丰富的plugin • Squid/memcached/netapp • 保存历史记录，观察流量和各项资源的使用的关系 • 要求ops每天都需要浏览cacti，每周全面审核

  15. Qunar监控 • Hyperic • Java • 开源 • 丰富的plugin • 可用的报警机制 • 所有的业务、系统相关指标都在hyperic • Smokeping • Monitor机房到各省各个运营商的链路质量

  16. 经验

  17. 经验 • 每次发布完，团队要对所有的监控指标和系统图形观察30分钟以后才算结束发布 • ops团队每天早上会对关键应用的指标进行快速review • Ops团队每周会对监控指标做快速巡查 • 90%以上的故障能通过监控系统发现

  18. Xen • 虚拟化 • 70%以上的生产服务器跑在Xen上 • 迁移方便 • 部署、管理简单 • 更高的使用率，平均cpu使用率从15%->45% • OVM/Xen • 有基于web的管理界面 • 剪裁比较好，300M

  19. Hardware • CPU • 2x4 core • Ram • 32G or 16G • Disk • 2x500G, Raid 0+1，有些有带电池写cache的raid卡 • NIC • 2x1G，1 for ilo

  20. 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.3 114_tw7_f_cn1 3 2200 4 -b---- 3099024.2 116_mem1_f_cn1 1 1700 4 -b---- 267107.3 118_sug1_f_cn1 10 1200 4 -b---- 58702.3 430_twb2_f_cn1_ovms8 9 2200 4 r----- 2283516.6 434_askdb1_ovms8 11 2200 4 -b---- 60466.4 Domain-0 0 668 8 r----- 1661065.3

  21. 问题 • 性能 • RAM/Syscall(context switch) • I/O performance • Disk performance • Network performance(not so important in web environment) • 管理 • Network structure(vlan tagging) • VMM层 • Vm之间隔离

  22. RAM/Syscall • Unixbench score • Raw 503 • Dom-0 397 • Dom-U 317

  23. Unixbench score

  24. Disk performance(with write buffer) Bonnie++

  25. Disk performance(without write buffer)

  26. Disk performance(Random seek)

  27. Vlan tagging • 一个物理主机上要支持在多个vlan的虚拟机 • 规模扩大，单个网段无法满足需求 • 安全分区需求

  28. 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

  29. JAVA开发的一些Tips • 善用jdk的命令 • Jps • Jstat • Jmap • Jstack • jhat

  30. tips • 内存 • OOM • GC并不能杜绝内存泄露 • 仔细计算内存的使用，内存是有限的，给内存的使用一个上限 • Jhat可以帮助你看到你的内存用在什么地方 • 内存池化

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

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

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

More Related