Qunar 是如何解决 IDC 网络故障自愈问题的

苗宏涛

2010年加入Qunar，目前负责技术保障部运维管理工作，先后带领团队完成DNS系统，负载均衡系统和运维自动化体系，分布式存储系统的规划和建设工作。

1、背景介绍

我在2010年加入 Qunar 的时候，Qunar 的 IDC 规模还比较小，服务器也只有几百台。随着公司的发展，业务对服务器的需求也越来越大，随之 Qunar 的 IDC 规模也逐渐壮大起来。如果将所有服务器放到一个 IDC 中，虽然管理会简单一些，但是带来的风险也是不可避免的。单个机房出现故障的风险还是存在的，比如电力、网络、空调，都可能影响到业务的正常运行，尤其是网络。大家都知道，一般 IDC 都会有很多个用户，而现在的互联网用户经常会受到攻击烦扰。另一个方面，每个 IDC 的上连运营商的接入方法也是差别的，这又会造成运营商与 IDC，运营商本身网络的抖动给我们的服务带来了不稳定性。为了分担风险，我们实施了多机房部署方案，搭建 Qunar 的骨干网，解决了机房间流量互通和链路冗余问题。

多机房部署方案，解决了单个 IDC 扩容问题，同时提供了多个出口提供服务。但是当遇到单个机房出问题的时候，部分服务还是会受到影响。原有的处理方式：运维同学接收到报警，然后迅速打开笔记本，连接 vpn（进入内网），检查监控影响，做出判断，切流量。整个过程对于一个运维老手，做出迅速判断，至少也要10分钟以上了，10分钟对于像我们这种电商损失就比较大了。同时，运维同学还要保证无论走到天涯海角，都要背着本本，随时做好要战斗的准备。

为了解决这些问题，Qunar 运维自主研发一套故障自愈系统，解决了机房网络的上行和下行两个链路的问题。

2、用户访问-下行

用户访问 Qunar 的产品主要是通过两种方式：客户端和 pc 端访问，但无论是通过哪种访问，都是基于 DNS 系统访问的。由于我们有多几个机房，所以我们在每个机房部署了一套负责均衡系统。

简单介绍下 Qunar 的负载均衡系统。我们原有的系统也主要是以 Nginx 类为作为负载均衡系统，早期的模式也是通过 heartbeat+nginx 模式，如下图：

随着业务的发展，单个 Nginx 成为了瓶颈。后期，我们引入了 ECMP 模式。Nginx 的横向扩展变得非常简单了。

后期，我们还引入了 Openresty 企业版。大家都知道，Nginx 每次加载配置，都需要 reload。而这个过程，会关闭原有的 worker，启动新 worker。这个过程，就会造成部分用户访问失败。而 Openresty 可以做到配置热加载，整个过程对用户无感。同时 Nginx 修改是一个串行的过程，下一次修改还要等这一次的修改完成。随着集群的数量增加，一次配置修改的时间也随之越来越长。Openresty Edge 正好解决了这个问题，它不仅可以对 upstream 进行热加载，同时对其他配置也可以做到热加载。另外，Openresty 还实现了分区管理，使我们串行的工作变成并行而且互补影响，使 OPS 的生产力大大的提高了。

通过这几次负载均衡系统的改造，我们避免了一个集群单节点的故障。但是，单个机房故障点还是存在的。针对用户访问问题，我们主要通过 DNS 解析解决。Qunar 已经开源了 DNSDB 系统，大家可以进入下面的网站了解和学习：

github https://github.com/qunarcorp/open_dnsdb

通过 DNSDB 系统，Qunar 运维就实现一键切换成百上千个域名。DNSDB 系统不仅可以通过 web 操作，并且提供 API 接口。正是有了 API，使我们的自动切换有了可能。我们每个机房都有对全国链路的监控：

上面这个图是每个机房全国网络的监控汇总。单个机房内，实现30秒内对全国100多个节点的检测任务。通过 watcher 监控平台，当监控阈值报警时，触发 DNSDB API 接口完成对 DNS 域名地址切换。我们设置阈值连续4个点有2个点报警再触发切换。这个也是一个经验值，可以有效的避免了监控系统的误报问题。当监控连续20分钟显示ok ，触发 DNSDB 系统恢复原有配置。通过这种方式，我们彻底解决了单个机房的网络故障。并且，通过自动故障恢复机制，也避免了由于人为疏忽，造成流量长期不恢复而增加了带宽成本。Qunar 的 DNS 系统也提供view 和 EDNS 等功能，也为 OPS 调节带宽和改善用户访问质量提供了有力的支持。

3、访问第三方业务-上行

虽然通过 DNS 系统我们避免了用户访问 Qunar 的问题，但是，我们的业务还有访问第三方合作等合作网站的需求。当单个机房出现问题的时候，尤其是 IDC 与上连运营商之间出现问题的时候，我们的业务就没有办法切换到其他出口了。

为此，OPS 和 Qunar TC组一起实现了一个 IDC 代理模式。IDC 代理解决方案，同样包含三个部分：代理模块部分、qconfig 配置代理部分和监控部分。结构如下：

代理模块，我们选择了使用 squid 作为代理模块。开始我们选择过 ATS 作为代理模块，性能对比 squid 有优势，并且可以利用上多核。但是，测试中发现到一个问题。当一个网站有多个 IP 解析时，如果有一个 IP 出现访问失败，ATS 将不再会去重试第二个 IP，直接返回502网关失败。而 squid 在第一个 IP 失败后，会重试第二个IP。所以我们最终选择了 squid 所作我们代理服务器。为了最大压榨服务器的性能，我们使用了 squid 的多线程模式。我们的一个测试环境：32核的服务器，squid 使用超线程模式，在压测过程，CPU load 跑满的情况，qps 可以达到50KQPS。在代理集群，我们同样使用了 ECMP 模式，使整个集群扩缩容都变得非常简单。

有了代理模块，我们还希望能够让业务在单机房故障时，代理能够自动切换，做到对业务透明。由于我们大部分服务是 java 服务，就请 TC 团队帮助开发了一个http 模块。业务在引入这个模块后，就可以通过我们 qconfig 配置代理模块。

在业务侧，通过 qconfig，业务可以设置集中模式：

开关。通过开关控制是否使用代理。
配置白名单。只有配置了的域名才会走代理。

在运维侧，设置模式会比业务侧多几个组合：

黑名单。配置了黑名单的域名，将不允许走运维的代理。比如，我们会把自己的域名过滤，这样不会造成资源的浪费。
代理规则：可以采取域名、域名+机房、机房和默认规则。通过这些规则的设置，OPS 就可以做到对流量的控制了。

有了代理模块和 qconfig，我们还需要监控系统的配合。这一块，我们复用了在前面介绍的监控系统部分。当出现单个机房故障，我们的程序会调用 qconfig，触发代理规则修改，从而把流量快速切换到其他机房。整个过程，对业务是透明的，服务保持连续。

有了这两套系统，运维同学在休息日的时候，终于不那么紧张了。我希望能够带领运维同学们，继续完善我们的运维系统，让更多的系统能够实现故障自愈，让同学们有更多的时间去研究更先进的技术，有更多的假日时间陪伴家人。