QQ全量上云的技术解析

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

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

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

1、总体规划

1.上云总体规划

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

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

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

(1)基础设施上云，简单说就是把基于物理网络的自研IDC设备搬到云上，使用基于虚拟网络的云CVM来搭建。

(2)微服务和容器化改造，支持自动扩缩容。

(3)架构和存储升级，全面融入云生态。

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

2.基础设施上云规划

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

(1)完成全部核心功能模块在云上的搭建，并调度1000万在线用户到云上。

(2)完成总体基础设施上云，并作好云上的三地调度演习。

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

2、方案执行

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

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

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

01 安全问题

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

02 依赖问题

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

03 容灾问题

部署到云上的模块，须要经过云机房到自研机房的专线进行通讯，若专线发生故障，可能致使云机房成为孤岛。一开始云机房只在广州部署，没法作到云环境内部多地容灾然后云自研云机房。

04 灰度问题

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

2.面临挑战，如何解决

01 应对安全问题

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

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

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

在此之上，使用网络防御以及网络安全的产品服务

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

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

02  应对依赖和容灾问题

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

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

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

03 应对灰度问题

QQ后台的模块众多，一会儿上云并不现实，为了确保服务切换的平滑稳定，须要考虑如下状况：

(1)有问题时影响尽量少的用户。

(2)用户数据无缺性：有问题时不能致使用户数据丢失或错乱。

(3)机器维度回退：云上环境有问题时，能够随时禁用，所有切回自研环境。

(4)用户维度回退：用户登陆云IP有问题，可以自动切换到自研IP，不影响用户使用QQ。

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

a/用户维度

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

b/后台模块维度

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

基本思路是：

(1)先上接入层，验证云上的连接能力；

(2)再上逻辑层，逻辑层经过必定用户量级验证没问题；

(3)再上数据层，确保用户数据一致性。 

c/后台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服务。

3、里程碑中的挑战

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

(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机器较少的时候，人工确保一对一映射是没问题的，但随着上云机器数和用户数增多，一对一映射将没法知足现网质量要求。

里程碑2：一千万在线

从500万到1千万的阶段，云设施的基础能力已经验证没有问题，但网络质量、时延的问题更为凸显。

01 丢包问题

随着云上用户量的增加，不少新的问题被暴露出来，比较典型的仍是丢包问题。

这个时候遇到的丢包问题，大概有以下这几种状况：

(1)虚拟机默认缓冲区过小。

(2)物理母机缓冲区大小设置过小。

(3)VPC会话数限制过小，VPC在实现上会存储网络访问的五元组会话，QQ后台大量使用UDP，并且由于QQ体量比较大，五元组的数量很大，超过VPC的限制。

02 批量死机问题

这是群Server在部署的时候遇到的一个问题：3台机器一块儿死机，定位后发现是同一台云主机死机了。

在自研环境中，群Server是使用实体机M10来搭建的，到了云环境，采用相同内存大小的虚拟机来搭建。运维在部署的时候，若把主备本应该分开部署的机器放到同一台实体机上了，这对业务来讲简直是灾难。

最后，技术同事们协商肯定，由运维来确保同个模块分配的机器不能处于同一台物理机上，实现方式是：在业务同一个集群下的配置组别，打散母机。

4、找对方法，加速上云

在QQ上云过程的细节里，有不少方法能够选择，也离不开一些技术工具和平台的支持。这里从“数据库的迁移模式”、“MySQL数据搬迁”、“数据中心同步”、“云管平台”、“云原生”、“TKE引擎”这几个方面来进行简单介绍。

1.数据库的迁移模式

在私有云到公有云的数据搬迁模式中，QQ有三种模式能够选择。

(1)私有组件数据迁移到公有云

腾讯内部有不少自研的数据库，像QQ的Grocery KV存储使用的是内部私有协议，云上没有对应服务。业务须要将数据从私有组件迁移到Redis。

QQ采起了冷迁移的方式，先将数据全备，而后把数据导到云上Redis集群，导完后再作新增数据追加(用数据同步中心来实现)，数据同步完以后进行业务切割：留一个业务低峰期时间，好比晚上凌晨2点，花1分钟把数据路由服务从自研IDC切到公有云Redis集群上。

(2)开源组件到公有云

腾讯内部有一些业务是在开源组件之上作的二次开发(如基于单机Redis实现自研分布式Redis集群)。这些基于自研或开源组件的数据迁移到公有云上对应的数据服务，可经过DTS迁移工具来实现。

腾讯云上的DTS也能够来作自助迁移。这个工具甚至不须要运维操做，开发团队本身在DTS窗口上输入几个参数，点个搬迁按纽后便可自助搬迁。搬迁完成后还可自动切换。

(3)私有组件直接上云

有时云上暂无一些特定组件，业务也没有资源改造私有组件为云的标准服务，此时可将组件集群直接在云上部署一套，数据经过同步中心或主备备等方式搬迁到公有云上。

2.MySQL数据搬迁

QQ的MySQL数据搬迁分“主—从”和“主—备”两种模式。

主—从的模式

它经过内部的DNS类名字服务而非IP和PORT来寻址：先分配业务一个实例的名称，而后经过DNS拿到这个实例的IP端口，再去访问具体的实例。而后，从自研的IDC使用腾讯云DTS迁移工具，把数据导到云的MySQL。数据自动导入完成后，开发团队只须要在云上切换服务就能够完成数据实例的迁移。这种方式适合一些数据体量不大的业务数据迁移。

主—备的模式

即在深圳自研有数据库服务器的主和备，在云机房新部署几台备机。经过主备同步的方式，把全部数据都同步到云机房。而后将云机房的某台备机切换成主机，将自研的主机降级为备机。这样就切换为云机房主备，自研机房备的模式。

3.数据同步中心

更复杂的是数据同步中心。它适合业务量大，有全国多地分布且对延迟不敏感的业务，譬如QQ空间的点赞、发表说说等。它有以下特性：

服务模块写数据时，统一写到各地的接入代理，代理再统一写入一地；

写服务的转发存储会将新增记录同时写到各地自研或云机房，实现最终数据一致性；

用户就近读，好比华北的用户，就读华北云的这个数据存储集群，华南就读华南的数据存储集群；

经过同步中心的方式完成大规模数据的混合云同步。当要增长一个成都云区域，只需在当地增长一套同步服务。增长路由服务规则后，同步服务就会自动把数据同步到成都的云机房。

通常从深圳自研同步到上海和天津时延迟达几十毫秒，不适合金融行业等延时高敏感业务模式。

4.云管平台

以前腾讯内部的配置系统、监控系统、CMDB等都是基于私有云的管理模式。业务上云以后，它们要改形成支持混合云、多云的管理模式。譬如业务模块会有50个实例在腾讯云上，30个实例在海外云上，30个实例在内部私有云里，那么CMDB必需要支持多云的资源管理。

图中能够看到，账号体系、预核算、企业安全、监控等应用工具或平台，都要改造以适应混合云模式。以账号体系为例，QQ的开发者们以公有云的账号登陆云官网来购买、使用和运营公有云上的资源。但如何把账号所使用的资源成本核算到对应的业务，员工离职或转岗后资源怎么回收或转移，账号如何绑定给企业组织架构，云官网账号登录如何与内部OA鉴权等，都是必须提早解决的问题。

5.云原生

在开发方法、业务交付、云原生服务等方面，腾讯内部的TAPD研发管理工具、工蜂代码仓库、蓝盾、橘子CI、QCI、coding已集成为工具链，在云上打造了一个持续集成、持续部署的DevOps流水线闭环，QQ上云也收益于此。QQ之前是包交付，现已大量使用容器交付方式。

在微服务这块（如SF二、SPP、TAF等），QQ使用了大量的微服务框架，这些微服务框架还将进行迭代升级。

6.TKE引擎

K8S平台上，QQ用了腾讯的TKE引擎，这是一个跟K8S彻底兼容的引擎。一个用户在腾讯云上买了K8S服务，本身内部也部署了K8S集群。他们的容器能够随时、同时交付到腾讯云和他们自己的K8S集群，而不用作任何改动。经过容器交付，能够不用考虑环境依赖等问题。

经过将TKE跟QQ的业务特性适配，腾讯作出了一些更能知足业务场景的K8S应用功能：

(1)跨地域

QQ是三地分布，上云后又增长了自研和云的机房属性。原生K8S不支持跨地域的，所以腾讯的TKE引擎增长了跨地域的特性。

(2)弹性伸缩能力

TKE有基于CPU负载等基础容量的弹性伸缩能力。在TKE优秀的伸缩能力之上，腾讯还作了功能叠加。根据业务长期的趋势和业务突发活动，经过算法来预估容量在什么时间窗会达到多少水位，以准备相应的容器资源来提早几小时扩容，应对突发流量。

(3)权限限制

某些业务对权限是基于IP鉴权的。好比内部的业务模块访问MySQL时，要受权MySQL给这些IP放行。容器是很难去作这种基于IP的权限管理，QQ的作法是将容器固定IP，交付时注册到CMDB上，完成鉴权等自动化交付流程。

(4)开发工具

腾讯内部有不少CI/CD的优秀工具，开发团队能够在镜像仓库选到本身适合的工具，在CI、CD、CO都能保持本身的习惯。

(5)海量业务

在管理体系、安全、审计、服务监控、日志、告警等功能特性上，腾讯增长和优化了近百个特性，知足TKE与海量业务的结合。

从腾讯自研业务上云以及一些合做伙伴的案例，能够得出上云的五大趋势：

(1)全面拥抱DevOps，研发效率更高效；

(2)内部的优秀工具上云，让云能提供更好的服务；

(3)完全拥抱云原生，用云来知足业务快速迭代，资源弹性伸缩的需求；

(4)开发团队心态更加开放，主动与开源社区协同，贡献更多的功能特性；

(5)在QQ全量上云的过程当中，不少问题边上云边解决。整个公有云的基础设施和服务已经被锤炼得更加成熟。

5、小结

QQ上云，比如开着火车换引擎。

如今，QQ已经把了华南、华东、华北三大区域的用户全都迁到了云上，实现完整的QQ公有云上服务。是的，“开着火车换引擎”，咱们作到了！

此次自研上云的成功，一方面为腾讯云的进一步壮大打下坚实的基础，另外一方面，也为QQ自身的技术重生埋下伏笔。

QQ的将来，今后刻开始改变。

关注腾讯开发者，专业的开发都关注了。