QQ全量上云，你想了解的技术细节都在这_上云对后台服务的要求-CSDN博客

本文链接：https://blog.csdn.net/shaneyuee/article/details/136781342

@[TOC]QQ全量上云，你想了解的技术细节都在这

一、引言

（这篇文章是2020年我在腾讯工作期间所写的对外分享的文章，文章曾获得pony和tony的点赞，原文发布在这里：https://mp.weixin.qq.com/s/tzw9FVZXGDulOcwb9DEQcA）

腾讯的业务体量非常庞大，在2019年，腾讯已拥有超过了100万台服务器，其中，社交业务包括QQ和空间的体量有近20万台服务器，且分布在全国三地。

把QQ这头大象搬到云上并非易事。作为腾讯最庞大、最悠久、最复杂的业务之一，QQ各系统间存在强耦合。上云过程中需要确保对用户零影响，其难度可想而知。

面对重重挑战，QQ是如何迎难而上的呢？本文即将从整体规划、方案执行、里程碑中的挑战等方面介绍其中的技术细节，希望能为大家提供借鉴。

二、整体规划

1.上云整体规划

QQ上云规划时进行了系统化的梳理，包括业务评估、容量评估、业务架构、组织体系（比如运维职责的变化、研发流程的变化、资源预核算的变化、故障处理流程的变化）。

最重要的是，QQ的技术体系跟着公有云进行了转变，确定迁移方案、迁移工具、风险预案、回滚预案、混合云预案、多云预案等。

以过程划分，QQ上云整体规划包含以下三个阶段。

(1) 基础设施上云，简单说就是把基于物理网络的自研IDC设备搬到云上，使用基于虚拟网络的云CVM来搭建。
(2) 微服务和容器化改造，支持自动扩缩容。
(3) 架构和存储升级，全面融入云生态。

其中，基础设施上云是最底层、最基础的第一步，本文将重点介绍。

2.基础设施上云规划

基础设施上云的规划分为两个阶段。

(1) 完成所有核心功能模块在云上的搭建，并调度1000万在线用户到云上。
(2) 完成整体基础设施上云，并做好云上的三地调度演习。

在计划推行的过程中，腾讯内部多个技术团队精诚合作，共同应对复杂挑战。然而，随着QQ逐步放量上云，面向海量服务的挑战才刚刚开始。

三、执行方案

QQ上云方案执行前，有预测试、预验证的过程。一些核心模块（譬如高并发，或延迟非常敏感的模块）在云上经过了充分压测。真正迁移后，还有更多挑战需要灵活应对。

3.1 QQ后台服务搬迁上云主要挑战

QQ后台服务搬迁到云上部署，有这几类主要挑战：

3.1.1 安全问题

腾讯云提供的官网VPC可以通过配置反向代理被外网访问，相比受自研环境保护的内网环境，缺乏自我保护的能力，搬到云上貌似更容易被恶意入侵。

3.1.2 依赖问题

QQ后台服务依赖关系复杂，无法一次性将全部服务都迁到云机房。统计后发现，QQ后端主要的核心模块平均依赖40+个后端模块。其中很多是外部的模块，比如安全、架平存储，这些模块云上支持的时间未定，前期只能先穿越到自研IDC访问。

3.1.3 容灾问题

部署到云上的模块，需要通过云机房到自研机房的专线进行通信，若专线发生故障，可能导致云机房成为孤岛。一开始云机房只在广州部署，无法做到云环境内部多地容灾而后云自研云机房。

3.1.4 灰度问题

QQ即时通讯的特点，决定了用户对QQ的实时性要求很高，怎样合理灰度，做到用户对上云过程零感知，是一座需要跨越的大山。

3.2 面临挑战，如何解决

3.2.1 应对安全问题

结合云上的安全产品，以及原来自研的安全服务和安全策略，腾讯有一套混合云的安全通用体系。

首先在公有云的大网里，划出独立的私有网络VPC-X

即有外部访问的模块（如QQ接入层SSO、内网接入层OIDB等），可以部署在普通的VPC中，而核心业务需要做外部隔离部署。为此，QQ运维和腾讯云一起建设了没有外网环境的VPC-X专用云环境，并通过策略打通了普通VPC和VPC-X之间必要的访问路径，拒绝其他访问。

在这里插入图片描述
在此之上，使用网络防护以及网络安全的产品服务

云上有丰富的安全产品：主机上有主机防护，漏洞扫描；业务层有应用防护；运维有运维安全。QQ内部积累的一些安全方案，也已回馈到云上。

事实上，整个公有云的安全策略和私有云是一样的，没有什么根本性的差别。

3.2.2 应对依赖和容灾问题

上云过程要需要进行灰度迁移，而迁移过程会不可避免地造成自研机房和云机房的带宽穿越，为此，需提前评估自研机房到云机房所需的带宽。

假如使用城市方案，专线带宽应该跟现有的三地部署方案对齐。QQ核心系统大概需要几十G的带宽。若采用IDC方案，QQ里面有很多业务使用有状态的寻址方式，把同城内的机房全部打散访问（类似一致性哈希）。因此，把广州云当做深圳的IDC后，广州云和深圳的专线穿越会增大。参考深圳内部的IDC穿越带宽，预计需要增加几十G的带宽。

为此，开发者们评估了自研到云机房的带宽：支持QQ几大核心系统（接入、消息、状态、资料、关系链、登录）所需要的带宽为N。而所有QQ基础功能都迁移到云上，则至少需要2N的带宽。考虑到容灾问题，实际上拉了两条专线互备（防止专线被挖断形成孤岛），即为QQ上云专门搭建4N 的带宽专线。

3.2.3 应对灰度问题

QQ后台的模块众多，一下子上云并不现实，为了确保服务切换的平滑稳定，需要考虑以下情况：

(1) 有问题时影响尽可能少的用户。
(2) 用户数据完好性：有问题时不能导致用户数据丢失或错乱。
(3) 机器维度回退：云上环境有问题时，可以随时禁用，全部切回自研环境。
(4) 用户维度回退：用户登录云IP有问题，能够自动切换到自研IP，不影响用户使用QQ。

为此，需从3个维度制定灰度的3条主线：

1) 用户维度

简单说，就是灰度的用户量级。主要考虑用最少用户量级来发现问题。

2) 后台模块维度

其实就是哪些模块先上，哪些模块后上。主要考虑哪些模块出问题对用户的影响最小。

基本思路是：

(1) 先上接入层，验证云上的链接能力；
(2) 再上逻辑层，逻辑层通过一定用户量级验证没问题；
(3) 再上数据层，确保用户数据一致性。

3) 后台Set维度

一个Set可以认为是一套闭环的系统，比如资料后台的一个Set，包含“接入层+资料逻辑层+资料数据层”。这个维度的灰度，可用来确定一套系统里需要多少机器上云。

对于纯逻辑层来说，每个模块上两台机器（两台是为了考虑故障容灾，只需确保有一台在工作），就可以构造一个闭环的set，但对于数据层来说，一个set需要的机器包含一份全量用户的数据拷贝。

从灰度的角度来说，逻辑层就是堆机器的过程，数据层是先上一份最小的数据拷贝，并且先只放开“读”服务，等到其他所有环境都验证可行，才切“写”服务到云上。

灰度过程

结合上面3个维度，总体的灰度过程是：

(1) 内部验证+接入层（验证三通接入、用户级和机器级调度能力）
(2) 0-100万用户+接入层灰度扩容（小规模验证，观察用户反馈）
(3) 100W+逻辑层灰度及扩容
(4) 100W～500W+数据层同步数据
(5) 500W+数据层读
(6) 500W～1000W+数据层写
(7) 1000W～5000W+广州云1亿在线演习
(8) 南京云+天津云+0～5000W
(9) 天津云/南京云+5000W～1亿
(10) 天津云/南京云/广州云新3地调度演习
(11) 天津/上海自研机房下架，保留深圳自研机房观察1年
(12) 深圳自研机房下架

灰度过程中，通过客户端服务质量、服务间调用延迟、全网拨测等监控指标判断业务是否有问题。另外，此时整个服务运营体系已经转变，QQ必须适应相应的调整：

(1) 基础运维和公共运维团队变成由公有云的运维团队来支持。
(2) 运营流程也发生很大的变化，服务SLA要跟公有云服务商一起制定。
(3) 监控工具的选择，或改造原有的监控工具，或者换用云上成熟的监控SaaS服务。

四、里程碑中的挑战

基础设施上云，从用户量级的角度来考虑，主要有几个里程碑：

(1) 500万是速度和质量的平衡。
(2) 1000万开始迎接海量的挑战。

这里分析下每个里程碑里会遇到的重点问题：

里程碑1：五百万在线

在0到500万在线的这个阶段，需要重点关注可行性的问题，即各个系统怎样做好充分的验证，才能确保在云环境里成功跑起来。

01 丢包问题

丢包问题一般只是表象，真实的丢包原因隐藏着各种环境的适配问题、稳定性问题、质量问题。在QQ上云的过程中，丢包问题频繁出现，是所有问题中最棘手的。

这里列举在这个阶段遇到的两个丢包case：

case 1：网关问题。

在资料后台的搭建过程中，曾发现UDP的丢包率较大，且可稳定复现在某些用户上。通过问题定位发现，发包和收包逻辑均正常，于是怀疑数据在链路上丢了。最终发现是物理网关的问题：只要是UDP分片，且IP头后面第三个第四个字节为3503（0D AF）就必然导致丢包，同时也发现这个问题只在第一代网关设备（VSG）出现。于是腾讯找到网关设备厂商协商，把一代网关升级为二代网关（NGW），解决了该问题。

case 2：VPC缓存会话问题。

这其实是上个问题的延续。在一代网关（VSG）升级到二代网关（NGW）的过程中，触发了VPC在宿主机SDN转发实现上的一个bug，导致UDP丢包。一开始腾讯云在切换路由时是先删后加，当VPC内有NAT网关的默认路由时，就会导致流量转发到NAT网关。当路由加回来时老会话不会更新路由，因此老会话中断，而新发起的会话能正常工作。刚好自研机房有几台机器访问OIDB的UDP四元组一直不变，会话就会一直不老化，导致业务一直异常。最后这个问题靠重启业务进程解决，后续腾讯云团队也修复了这个bug。

这个时候遇到的其他丢包case还包括“专线被挖断、机器故障、机器性能问题”等，不过大多不是大面积问题，其影响范围较小，相关技术负责人能及时地解决大部分问题。

02 获取VIP问题

QQ调度系统依赖用户侧上报接入IP的可用性和耗时，来判断接入服务是否健康，并做最优的调度策略。因此，调度系统需要知道用户实际链接的对外IP（从后台角度看是TGW对外提供的VIP）。在自研环境中，TGW把VIP通过IP层的目标IP传给QQ接入层SSO，SSO通过getsockname系统调用就可以获得外网用户看到的VIP。但到了云上环境，接入层使用CLB接入，CLB传给SSO的时候，目标IP填写的是SSO所在虚拟机自身的内网IP。因此，在客户端不做升级，不修改登录协议的情况下，调度系统无法获得VIP。

解决办法之一是客户端升级协议，但这样的话老用户无法上云，无法保证上云的进度。

另一个办法是修改CLB的实现，对齐TGW，把外网IP传给SSO。在多方技术团队的努力下，最终决定按此方案实现。不过因为CLB依赖TGW/GRE的实现，还需要TGW团队、TLinux内核团队的配合，并需要将全网腾讯云的机器进行内核升级，整个修复的周期比较长，预期是3个月。

但QQ上云的进度，不能因此推迟3个月，为此，开发者们制定了一个临时方案：通过配置文件，配置VIP到RIP（Realserver IP，虚拟机内网IP）的映射关系。这个方案要RIP与VIP一对一映射，但在现网环境中，RIP到VIP的映射关系是多对多的（为了降低TGW和SSO的相互依赖，保证SSO多通路负载均衡）。在上云初期SSO机器较少的时候，人工确保一对一映射是没问题的，但随着上云机器数和用户数增多，一对一映射将无法满足现网质量要求。