文 | 周小军
来源 | 高效运维
摘要： 作者介绍周小军腾讯高级运维工程师，目前在腾讯社交负责社交业务海量NoSQL集群运维和团队管理。曾在天涯社区任运维副总监。对互联网网站架构、数据中心、云计算及自动化运维等领域有深入研究和理解，积累了十多年的经验
作者介绍

周小军
腾讯高级运维工程师，目前在腾讯社交负责社交业务海量NoSQL集群运维和团队管理。曾在天涯社区任运维副总监。对互联网网站架构、数据中心、云计算及自动化运维等领域有深入研究和理解，积累了十多年的IT运维管理经验。希望穷尽一生来深入钻研运维领域。
上篇全网大调度
8月12日23点30分，天津市滨海新区货柜码头发生集装箱连串爆炸。
占地8万平方米，服务器超过20万台的腾讯天津数据中心是腾讯在亚洲最大的数据中心，危险品仓库爆炸时，数据中心距离爆炸点仅仅1.5公里。
情况十分危急！数据中心随时有可能被迫停止运营！
事件发生后，第一时间排查了损伤，发现损伤包括冷机系统宕机，冷冻水管爆管，地下水发生严重水浸等问题，加之爆炸之后各种信息不明朗…
2亿QQ用户可能深受影响！这甚至影响很多公司的业务，因为QQ早已不是简单的聊天工具，而是商务洽谈之必备！
天津数据中心内含腾讯社交核心业务，包括QQ、空间、相册及音乐等业务。社交核心业务主要按深圳、天津和上海三地来分布部署，各支撑中国三大区域的用户访问。
其中天津数据中心是核心机房之一，承载我国北方所有用户流量，高峰期在线用户超过1亿。如果天津数据中心停运，将有30%以上的QQ用户服务受到影响。

所幸的事，类似于谷歌拥有的全球业务调配能力，腾讯社交网络经过长期的建设积累，具备了数据和业务在全国范围的云数据中心中转换迁移的能力。
经过24小时的技术应急大调度，QQ用户服务最终无感知地在线迁移到深圳和上海，完成中国互联网史上最大规模的用户调度。
在如此严峻的情况下，QQ运营继续保持全年4个9的可持续服务能力。
下面先简单介绍一下调度过程。
1、启动
社交核心业务的三地部署各具有一定的容量冗余，能保证一地灾难性故障时其他二地能支撑所有用户。
事件发生后，社交运营团队立即启动重大故障处理流程，成立突发事件应急团队，启用调度应急预案，做好天津用户调度回深圳和上海的准备：
应急团队按业务分配主、备负责人配合业务线来跟进实施，接入、逻辑和数据三个架构层各安排主备负责人协调。
由故障值班工程师负责在应急团队中协调和沟通。
最上层由大事件经理将汇总信息和实施过程实时同步给总监、业务、运维和QA等工作群组。
2、调度
13日团队开始以每千万为粒度将在线用户调度回深圳。
晚上22时是QQ在线用户峰值时间段，深圳一些服务模块的容量上涨到80%的水位，应急团队利用资源池里的服务器资源，边调度边扩容模块容量，把水位下调到可控范围之内。
对于没有资源扩容的模块，团队采用服务柔性的方式顺利过渡。如QQ采取的柔性为取消一些非关键服务：
如不加载联系人备注，不读取QQ漫游消息等。
通过在线扩容、服务柔性等策略，在线高峰期间用户访问核心服务顺畅，顺利地度过了流量洪峰，用户无感知。
下图为手机QQ天津地区在线用户曲线图：

上图可以观察到从13号晚上到14号凌晨，天津在线用户降到0的曲线下降趋势；以及14号下午回迁60%天津用户后的曲线上升。
整个过程不是仅仅从天津迁出到回迁这么简单，具体是这样的：
14日凌晨1时30分，天津所有用户全部调度、迁出完毕。
调度成功结束，此时天津数据中心在线用户数已为零。
14日上午，天津数据中心运维团队知会天津数据中心暂时可以稳定运营。
应急团队于是主动将深圳的1千万在线用户调度回天津，以缓解深圳数据中心的内网传输压力，并关闭之前开启的服务柔性开关，恢复全功能服务。
14日中午，天津数据中心预警解除，现场可控。
应急团队将大部分在线用户调度回天津，使得天津在线用户恢复到4千万的容量。
20日，天津爆炸现场解控，数据中心几处受损得到全部修复，基础设施恢复正常，警报解除。
应急团队将北方用户全部调度回天津，天津恢复回812之前的流量水平。
调度的几点挑战
QQ 2亿多在线峰值用户要实时全网调度，所面临的挑战是非常大的，主要有：
用户如何在体验无损的情况下调度到异地？
数据中心三地分布，用户在三地之间以秒间调度，必须保证不掉线、不丢数据，用户完全感知不到异地切换。因此必须要保证状态、消息、数据等做到三地的一致。
用户的状态数据、消息如何保证不丢失？
用户有各类状态，如在线、隐身、忙碌等，必须要实时同步到三地数据中心；用户消息包括C2C消息、群消息、离线消息等，要解决用户切换时消息不丢失的挑战。
用户的数据如何做到几地的全量一致性同步？
这里要解决以下问题，包括如何保证同步的可靠性、实时性；如何支撑大流量高效分发和灵活伸缩；如何应对频发网络抖动和异地专线延时；如何支持多地区互联和区域自治。
异地的服务容量（包括服务器容量、模块容量、业务容量和IDC容量等）能否支撑大量用户请求的涌入，异地容量不能支撑时如何处理用户请求？
容量峰值后如何快速缩容？
调度能做到多快，分钟级、小时级还是天级？
调度速度越快就越能具备快速反应能力，而目前QQ已经做到秒级的调度能力。
运营是否具备自动化的调度能力？
调度必须是一键式全自动化，一个工程师就能轻易实现全局的调度能力。
以上任何一个挑战解决不了的话，都必将影响调度的实现。
在下篇将讲述，我们是如何应对这些挑战的。本次亿级用户迁移背后的技术架构和运营，其中用到的核心技术是SET，本文先和大家做个预热。
关于 SET
SET，就像标准化的集装箱，是一个标准化的服务模块集群。它把原错综复杂的服务器内连接关系和功能耦合模糊掉，变成运营层面看到的一个个业务部署模块。
腾讯社交业务以SET的方式部署服务，每个SET集合了一个或一组服务模块，通过接口对外提供调用服务。SET对外输出二种容量：
一个从业务层面来看到的量，即一组服务器的处理能力，处理能力有两个量来描述，PCU容量（万人/在线）和存储容量（GB）；
另一个层面则直接来自于成本层面，即这一组服务器有多少台服务器和外/内网带宽。
SET间是无状态的，通过SET可以实现横向扩容能力。也就是说这些业务都支持部署最小化，当有需要时，可以不断增加SET数量来支持业务的流量，且SET之间无差异。
下篇大调度背后的技术架构
1、多地分布和异地容灾能力
QQ及业务服务以SET的标准化方式部署，以在线容量为标准划分SET，采用无热点的分布式部署，做法是把QQ号码通过基于unit的一致性分布算法划分成不同的Shard。
QQ SET内各层模块解耦，100多个核心模块分成接入中心、消息中心、状态中心和同步中心4个中心。中心内的模块根据物理分布情况灵活组合成流量内聚、号码无关、仅跟在线容量相关的集群。架构可以按照在线需求灵活扩容和伸缩，优化使用专线，实现异地分布。
以此为基础，QQ核心服务做了三地分布（深圳、天津和上海），单一地区服务故障时核心服务可迅速调度到另二个区域。

图：QQ三地分布架构图
QQ空间、音乐、相册等业务以三层标准架构的SET方式部署。QQ空间按照访问来源和功能的不同将SET划分为PC接入SET（Aset）、手机接入SET（Wset）和数据SET（Iset）。
这3类SET在设计架构时，就已经融入了三地分布（深圳、天津、上海）的容灾理念，通过GSLB和移动联通服务，将来源不同的用户分别均摊到三地，每地分布的SET都能提供空间最核心的社交服务处理能力。

图：QQ空间三地分布架构图
跨地域SET访问的流程如下图：
终端用户通过域名解析找到接入层
请求发到接入层
接入层通过内网名字服务查找逻辑层
接入层访问逻辑层
逻辑层通过内网名字服务查找数据层，并写入数据层
本地数据层SET同步到异地其它数据层SET

图：手机QQ的一键式调度表单
QQ空间等核心模块服务均为SET多地分布的架构，SET间数据无差异，在故障发生的场景，能够轻松的实现跨地域调度，保障业务质量的稳定可靠。
2、快速的调度能力
SET之上是用户或服务间的调度能力，调度分外网调度和内网调度。
外网调度有三种方式：基于域名解析的GSLB域名调度；QQ的IP调度和APP的WNS（内部代号维纳斯）调度。
内网服务间调度通过L5和CMLB内网名字服务实现。
1）GSLB全局域名解析服务
GSLB是腾讯的DNS域名解析服务，可根据用户IP识别出用户归属地，继而实现针对不同来源的用户返回不同的IP功能。QQ空间的PC用户调度便是依赖GSLB的调度能力实现。

2）QQ IP调度
QQ具备精确到机架的最优调度能力。用户请求经过实时计算获得最优的访问位置，包括城市、IDC、网络模块和服务器IP。
通过秒级的IP配置下发，用户可立即重定向到指定的访问机房。
3）WNS
维纳斯（WNS，Wireless Network Service），又名移动连通服务，是一个为APP提供高连通、高可靠、强安全的网络连接通道的服务；它利用海量运维数据不断持续优化调度算法，实现用户就近接入。
移动端的接入使用WNS的服务，无需域名解析，直接利用WNS的IP跑马逻辑寻求最优的接入方式，移动用户可以通过WNS服务主动触发用户重连，继而控制用户调度所需接入的新IP。
4）L5/CMLB
L5和CMLB是内部服务模块寻址和负载均衡的自研组件。
L5（Load Balancer，5代指Level5，即99.999%的可用性）是一套兼具负载均衡和过载保护的容错系统，本质上是一个集名字服务、负载均衡、故障容错和过载保护的路由决策系统。服务模块间通过L5来寻址，譬如接入SET A通过L5来选择逻辑SET B，逻辑SET B通过L5选择数据SET C。
L5的基本工作原理可以抽象为基于机器初始配置信息，通过自适应算法，以两个关键指标（请求成功率和请求延时）为依据，周期性计算出每个被调机器的权重，再使用高效的配额算法分配各个主调机器的访问路由，主调机器上的业务进程通过API来取得这些路由，调用结束时通过API来反馈路由的好与坏。
5）一键式调度能力
一个工程师从织云（内部自动化运维系统的代号）上通过一键式操作就可以完成全网和内网调度过程。调度平滑，用户无感知，千万级用户调度可以在30分钟内实现。
3、数据多地同步能力
异地容灾除了计算资源的分布，更大的挑战是存储资源的分布。QQ有三种方式实现数据多地同步，分别是：
QQ状态同步，QQ DB数据的主备同步和QQ空间DB数据的同步中心。
1）QQ状态同步
QQ在各个区域都是全量数据存储。但用户登录时根据来源区域而调度到不同区域的IDC。用户登录到不同区域的状态信息要在数秒内全量同步到所有区域的状态中心，状态数据包括离在线等基本状态、登陆终端等用户信息等。
同步要克服多地同写、本地数据可靠、延迟丢包、数据一致等困难，挑战是非常大的。
架构通过同步系统解决状态信息同步。同步系统除通过本地的同步代理存储本地双份数据外，还负责三地状态数据同步。它会从接入中心内收集在线登录用户的状态信息，按照Shard组织单元汇总这些状态信息，经数据去重后，同步给需要这些状态信息的其他系统：
同步队列和断点续传保证短时中断不丢数据；
多级SEQ/时戳机制保证数据延时、数据源故障等异常下的数据一致；
TCP同步流容忍延时丢包，减小TCP拥塞算法的影响，并具备多级流量控制、业务粒度的过载保护。
本地的全量DR还会将状态全量数据落地，以保证数据的高可靠性。

图：QQ状态同步架构图
2）QQ DB数据的主备同步
QQ DB采用内部研发的Grocery 分布式KV存储系统，采用类似MySQL的主从复制架构实现主备冗余和异地分布。Grocery支持一主多备，其中主服务器提供读写能力，备服务器提供只读能力。主备服务器可任意分布在同一IDC或不同区域。
譬如某最终一致性的业务场景中，一台主和一台备存储服务器部署在深圳，另2个备存储服务器分别部署到天津和上海。业务集中写深圳的主存储服务器，主存储服务器通过专线同步到天津和上海的备存储服务器。主服务器出现问题时由某地的备服务器提升为主服务器，并向业务提供写能力。
Grocery的主备同步通过sequence和流水保证主备数据的一致性。
3）同步中心
QQ空间采用内部研发的CKV分布式KV存储系统，通过同步中心实现多地同步。同步中心是一套消息队列服务，应用层先写数据到同步中心，各地区的同步读进程从队列服务里读取同步数据，并写入本地的数据SET，从而保证1秒以内的多地数据同步。

运营能力
1、织云自动化运维平台
织云是社交业务运维自动化平台，已经实现上千个业务模块的无人职守自动扩容，具有按业务搬迁能力，覆盖社交网络全部业务。
织云改变了传统的运维模式。以前的运维模式是以运维人员为中心，所有变更都需要运维登录到各运营系统(部署、发布、接入)、协调各种资源（开发、测试、设备管理员）来完成。
而织云是以配置为中心，运维只需要在织云管理好配置和流程，织云会根据配置将变更自动化。
以业务扩容为例，以前的运维模式是这样的：
运维需要到资源管理系统申领设备；
到包发布系统装包；
到配置中心发配置；
用自己的工具同步文件；
到各权限系统申请权限……。
织云将这一切操作自动化，一键触发，10分钟完成。
在这次庞大的“零感知”的迁移中，织云起了关键的核心作用。迁移的流程成功率和工具成功率达到99%以上，自动调度流程成功率也达到80%以上。
2、柔性服务和过载保护
由于成本的限制，不可能对所有服务都实现高度冗余。因此在某些非核心模块达到容量阈值或同城故障而无异地容灾时，通过配置开关来关闭非核心服务，牺牲一些业务逻辑来保证核心功能完整性及用户体验。
工程师织云上通过一键式下发配置来实现柔性策略。

每个服务上线前都具备过载保护机制。
如架构中的L5内网名字服务除提供寻址、容错功能外，还利用时间片内基于客户端请求质量延时和错误率统计来确定最高访问请求数的阈值。通过负载均衡和重试的频率控制，来防止处理不及时过载雪崩，限制处理最大的请求数过载雪崩。过载配置参数化，通过配置文件进行灵活调整。
某些服务模块在请求进入队列时打上时间戳，当队列达到最大数，或检查时间戳发现超时后会丢弃超出阈值的请求，保证系统不过载而导致服务不可靠。
3、快速伸缩能力
通过SET标准化部署和织云自动化平台，一个SET内的几百台服务器可在10分钟内完成自动化部署上线，实现操作系统安装、包安装、应用部署、自动测试、自动上线等一体化能力。
4、立体监控
运营团队建设了天网等集基础监控和业务监控能力在内的监控平台和核心视图，能够即时在PC端或移动端查看各业务、各架构层的容量水平，保证调度前后能够随时了解平台状态，提供了有效的预警机制和运营分析能力。
在监控数据和业务访问链条的基础上，监控平台通过DLP（业务生死线）第一时间感知业务异常，通过root分析能力在10分钟内准确定位业务异常的根源。
5、技术保障
运营团队通过日常业务链条压测和预演等方式来不断发现系统短板、优化运营能力和提升响应速度，定期和业务联合演练。
下图是PC QQ日常调度的预演邮件截图：

每个业务和组件环节都各有相关预案。重大故障有成熟的处理机制，由大故障经理、运营值班工程师和QA等角色组成，在遇到重大故障时根据影响范围启动相应的应急机制，按既定策略来和流程实施不同的应急措施，将结果即时同步给业务、开发、QA和运营。
信息高效地在不同责任团队中上传下达，帮助了从上层到下层的决策和处理，使得调度处理及后续跟踪有序进行，保证大调度的顺利实施。
结尾
腾讯在长时间的海量业务运营中积累了成熟的方法论，从上述文章中表现出来的有全网调度、有损服务、柔性可用、SET模型、立体监控、过载保护和大系统小做等方法论。
这些方法论和建设共同支撑了813大调度的成功实施。希望这些经验和实践能够为业界同仁借鉴所用，将中国互联网整体运营能力提上新的台阶。
end