万台服务器“一人挑”的奥秘

在 2018 年春节期间，组件运维团队运维设备超过 4 万，单人运维设备超 2 万。在海量服务运维过程中我们面临了哪些挑战？

我们的组件运维团队的职责范畴：负责整个 SNG 接入和逻辑层业务的运营维护，有 1.8 万的域名，3000 个业务模块，4 万台设备，单人运维设备超过 2 万台，这么大的规模，我们面临五大挑战。

第一个挑战，中国幅员辽阔，横跨 5 个时区，有 30 多个省级单位，我们的机房是在上海、天津、深圳三地分布，上万个域名如何保证就近接入？

考大家一个题，江西离上海近还是离深圳近？ 答案是江西北面离上海近，南面离深圳近。

我们在招运维的时候，还要求运维上通天文、下通地理才能干好，这显然不靠谱。中国有三大运营商，电信、联通、移动，还有很多小的运营商。

中国有一个段子，世界上最远的距离不是天涯海角，而是你在电信、我在联通，相信大家做运维这个体验特别深刻，所以我们要尽量避免跨运营商。

第二个挑战，自从苹果启用 ATS 安全规范之后，域名支持 https 接入就成为标准了，https 证书是有有效期的，需要不断的扫描、续期、更新。

上万个域名的 https 接入如何高效统一维护，由运维完全搞定这个问题，是面临的第二个挑战。

第三个挑战，一个人运维服务器超过万台的时候，你会发现每天名下有几台设备宕机是一个常态。

像前面讲的，你不能在床上躺下了马上就起来，运维也是人干的活，我们如何保证宕机无需运维干预自动处理，而且还对业务无损。

第四个挑战，互联网中有一句话上线容易、维护难，互联网服务的运营维护周期比研发周期长，一个产品的研发周期，开发出来就几个月。

但是运营维护的时间往往是几年甚至超过十年，很容易进入长尾死而不僵的状态，所以对运维也有挑战。

第五个挑战，大规模的缩扩容。比如说在春节、元旦这些节假日用户都喜欢在 QQ 空间发感想、在 QQ 群里发祝福，社交网络还会借势推波助澜一把，在节假日的时候搞一些活动，QQ 红包更是每年都搞。

这样大家 happy 的节假日就变成我们运维的苦难日，因为涉及到大量设备上线、模块扩容，这是我们面对的第五个挑战，如何应对大规模的缩扩容。

本文从以下三个方面进行阐述如何应对挑战：

海量服务的基础架构

运维实践中总结的几个原则

支撑大型活动事件的实战技巧

海量服务的基础架构

我将从海量服务的基础架构、在运维过程中坚持的一些原则和支撑大型活动事件的技巧三个方面来分别阐述我们如何应对上述的挑战。

首先看一下腾讯 SNG 的基础架构。用户一个请求过来之后，任何一个访问首先是 DNS 查询，查询得到 TGW 和 STGW 的网关 IP。

这个 TGW 与业界开源的 LVS 和商用的 F5 是类似的东西。请求经过网关的负载均衡，到 Web 层服务器，然后到逻辑层、存储层，图中间的织云路由是内网的负载均衡系统。

我们的整个访问链路做到了三个基本点：

做到名字服务实现没有调不走的流量，这对运维是非常重要的。

容错做到没有不能宕机的设备，也就是没有不能死掉的设备。我们在网上看到一些段子，运维请法师来机房开光保佑不要宕机，其实求佛不如求己。

统一框架提升研发运维效率，保证服务的基本质量，对于运维有着很大的意义，后续我会重点阐述。

牛顿说，如果我看得比别人更远，是因为站在巨人的肩膀上。如果我们能够运维万台服务器，是因为我们站在巨人的肩膀上，踮起脚尖，做了一次一米八的眺望。

巨人的肩膀：GSLB

GSLB 是腾讯自研的 DNS 服务，通过识别 Local DNS 出口 IP 国家+省份+ISP 属性，然后给对应请求返回相应的 IP，实现就近接入。

北京、上海、天津每个地域有三大运营商+中小运营商出口 CAP，然后再加上香港，所有海外的通过香港接入的方式，根据运营商来进行调度。

这样一个是避免了跨运营商；二是做到运营商网络出口故障快速切换，依赖的就是 GSLB 的这两点：

GSLB 有一个强大的基础数据库，它有全面而精准的 IP 地址库，国家和运营商的信息准确率做到 100%，省份的信息准确率做到 98%。

我们通过亚洲网络中心和中国网络中心的数据、运营商路由数据等通过一些算法校验得到 IP 地址库的数据。

我们拥有各 IDC 机房对各地用户覆盖质量的实时数据，通过机房拨测和前端页面的一些 js 抽样上报得到这个数据。

巨人的肩膀：TGW

TGW 是腾讯的网关系统。2012 年之前腾讯也使用了 LVS tunnel 模式，但是腾讯的业务发展太迅猛了，特别是游戏很快面临一个问题，外网资源耗尽。