2亿QQ用户大调度背后的架构设计和高效运营（下）
作者介绍
周小军
腾讯高级运维工程师，目前在腾讯社交负责社交业务海量NoSQL集群运维和团队管理。曾在天涯社区任运维副总监。对互联网网站架构、数据中心、云计算及自动化运维等领域有深入研究和理解，积累了十多年的IT运维管理经验。希望穷尽一生来深入钻研运维领域。
说明
关于本文的背景及面临的挑战，请参考：
2亿QQ用户大调度背后的架构设计和高效运营（上）
大调度背后的技术架构
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和运营。
信息高效地在不同责任团队中上传下达，帮助了从上层到下层的决策和处理，使得调度处理及后续跟踪有序进行，保证大调度的顺利实施。