QQ 是如何完成 20 万台服务器全量上云的？

截止到目前，QQ 所有的业务都已经迁移到了腾讯云上。

2019 年 1 月 4 日，腾讯技术委员会正式成立，同时下设了两个项目组开源协同和自研上云。现在，作为腾讯自研上云的先行军，QQ 已经率先完成了全量上云。

QQ 业务场景有哪些特征？全量上云的整体节奏是什么样的？迁移上云的难度在哪里？关键过程有哪些？为了解开这些谜题，我们采访了参与 QQ 全量上云的多位技术专家。

QQ 的业务场景

突发 + 群发是最恐怖的场景。

QQ 是一个典型的社交产品，社交场景的主要特点就是会有裂变的情况，比如如果一个消息是发在群里的，虽然看起来只是一条消息，但从送达的角度来看，可能会翻百倍。另外，一条消息不是一次发送出去就完事了，有时还会互相转发，转发给另一个人，甚至是另一个群。由于 QQ 使用的是 UDP，所以即使是在匀速发包的情况下，也会比腾讯云上其它的大客户大 N 倍。

然而，这还不是最恐怖的是，腾讯云原生架构总经理肖世广表示：最恐怖的情况是，在突发的情况下，发生大规模转发的情况。即使是在云的场景下，也不可能准备如此多的资源，所以在上云的时候，我们做了很多方面的优化，例如计算、存储、网络等等，除了提升云性能，更重要的是要降低成本。

QQ 全量上云的整体节奏

2018 年 9 月 30 日是 QQ 上云的一个重要节点。

930调整之前，腾讯集团内部其实已经在做很多上云的尝试，部分服务也已经跑在云架构上了。930调整之后，腾讯内部做了很大的变革，不仅成立了新的云与智慧产业事业群，同时启动了开源协同和自研业务上云的两大战略方向。在此背景下，QQ 上云成为了势在必行且迫在眉睫的事情。

2017 年，所有 QQ 用户是在私有云上；
2018 年年底，15% 的 QQ 用户从华南区迁移到广州云；
2019 年 6 月，30% 的 QQ 用户迁移到公用云上；
现在，QQ 所有用户全部迁移到公用云上；

QQ 是如何完成 20 万台服务器全量上云的？

据了解，目前 QQ 的云中架构是三云一地，所有用户分布在华北、华东和华南三大区域，其中华南区域又分为广州云和深圳自研机房两大机房。每个区域都是完全独立的存储和业务逻辑服务，华南的整个用户都都可以调度到华北和华东区，业务可以随时在不同的云区域和自研区域之间来回调度。

上云的方式

由于之前 QQ 有些服务是在本地和私有云上，所以在上云过程中避免不了要做改造。据了解，QQ 上云的方式共有三种，分别是先改造后上云、边改造边上云，以及先上云再改造，其中第一种和第二种方式用的更多。

以容器为例，QQ 团队在 2016 年的时候就已经在尝试容器方面的实现，并积累了自动化、弹性伸缩等方面的能力。决定全量上云之后，在容器方面选择了使用腾讯的 TKE 引擎，并通过边上云边改造的方式做了很多优化：

在 TKE 弹性伸缩能力的基础上做了功能叠加，例如业务画像，根据业务的长期趋势和突发活动去做预测，通过算法预估容量在什么时间窗会达到多少水位，提前准备相应的容器资源扩容；
将业务特性与 TKE 相结合，例如原生 K8s 是不支持跨地域的，而 QQ 是三地分布，且上云之后还进一步区分了自研和云的机房属性，所以 TKE 中增加了跨地域的特性；
权限限制，QQ 业务对于权限的要求非常严格的，要求基于 IP 鉴权，而容器是很难去做基于 IP 的权限管理，所以 QQ 使用了固定 IP，每个容器都有自己的 IP，交付时注册到 CMDB 上，并完成鉴权等自动化交付流程。

上云的难度

QQ 上云的难度在哪里呢？

首先，QQ 业务是属于海量的用户互相访问的过程，既不可预测，也没法做一个良好规划。QQ 的访问中，有大量临时的 UDP（用户数据报协议）的访问会建立起来，会带来各方面对基础的虚拟化和网络、计算性能的挑战。

其次，是成本问题。腾讯内部对于成本是有极致要求的，但我们都知道虚拟机因为要做管理工作是一定会有损耗的，如何优化虚拟机性能就成为了一个挑战。

第三，QQ 是一款拥有二十年积累的产品，为了支撑业务，QQ 技术团队也在很多方面都做了创新和优化，如何将这些累积的技术与云上技术结合在一起呢？

除此之外，具体到实际的上云实施，将 QQ 服务搬迁到云上还面临着以下具体的挑战：

安全问题（内网环境可以受到自研环境保护，搬到云上之后更容易被恶意入侵）；
依赖问题（QQ 服务依赖关系复杂，无法一次性将全部服务搬迁到云机房）；
容灾问题（云上模块需要通过云机房到自研机房的专线进行通信，若专线发生故障，云机房可能成为孤岛）；
灰度问题：由于 QQ 是款即时通讯产品，用户对实时性的要求很高，如何合理灰度，做到用户对上云过程无感知也是一个问题；

基础设施向云上迁移

QQ 上云不能有额外的成本支出！

QQ 和空间业务的体量有近 20 万台服务器，因为不能有额外的成本支出，如果迁移上云，这些存量服务器要怎么办？虚拟机肯定有损耗，这方面的成本差距如何弥补呢？

腾讯运营管理部运营规划负责人陈铁钢表示：QQ 是一个运营时间比较长的业务，很多服务其实已经到了服役年限了，就自然裁撤了，少量的可用服务器置换给其它云下业务使用了。不只是 QQ 业务，腾讯所有业务上云都不是一下子把所有服务器从自研搬到云上，而是有一个上云的节奏，先用三年的时间把每年的增量业务搬到云上，而存量业务会随着服务器的寿命而陆续裁撤和消灭。

虚拟机与物理机之间的成本差距如何弥补呢？腾讯自研了服务器产品星星海。据了解，在 QQ 某个业务测试中，星星海服务器带来了 25% 的性能收益，达到了原来物理机都没有达到的性能。

上云过程没有额外的成本支持，上云之后的成本效益又体现在哪里呢？陈铁钢表示主要体现在三个方面：

从管理角度来看，过去，资源是分散在每个业务组中的，为了满足业务突发和裂变的情况，每个业务组都会留一些 buff。这就会造成一个问题，所有的 buff 加起来会很大，但分割到具体业务后又很小，既不能很好的支持业务扩展，从公司层面看又很浪费。如果把这些资源都整合在一起，通过错峰效应，所需 buff 的数量减少了，但却能满足各个业务增长的要求。
很多 QQ 之前自己做不好的业务，可以通过云原生技术来优化。例如调度，上云之后利用 Kubernetes 的统一调度能力，提高设备的利用率。
自研业务上云不是在公有云上划一块独立集群给自研业务用，而是完全融入整个公有云环境，改变了过去腾讯云和自研业务是两个完全割裂的资源体系的情况。资源打通之后，当业务出现激增时，可以通过公有云的弹性能力快速扩展。

基础设施上云的节奏

如果从用户量级的角度来看，QQ 基础设施上云的节奏可以划分为两大阶段 500 万在线和 1000 万在线，同时，QQ 在这两个阶段遇到的问题也会不同。

500 万在线是速度和质量的平衡，这个阶段需要重点关注可行性。

丢包问题，丢包只是表象，其背后隐藏的是各种环境的适配问题、稳定性问题、质量问题。这个阶段的丢包主要是网关问题和 VPC 缓存会话造成的；
获取 VIP 问题，QQ 调度系统依赖用户侧上报接入 IP 的可用性和耗时，来判断接入服务是否健康，并作出调度策略。而到了云环境中，由于目标 IP 填写的是所在虚拟机自身的内网 IP，调度系统在客户端不升级、不修改登录协议的情况下，无法获得 VIP；

1000 万在线就要开始迎接海量的挑战，这个阶段云设施的基础能力已经验证没有问题，但网络质量、时延的问题需要重点关注。

丢包仍是一个需要关注的问题，只是这个阶段的丢包原因会有所变化，大部分丢包可能是由虚拟机默认缓存区太小、物理母机缓冲区太小以及 VPC 会话数限制太小造成的；
批量死机，一台云主机死机可能会造成其他机器的死机。比较好的解决方法是同个模块分配的机器不能处于同一台物理机上；

数据库和组件迁移

数据迁移是上云的重头戏，QQ 数据从私有云迁移到公有云主要是通过以下三种方式：

冷迁移方式，先将数据全备，然后将数据迁移到云上 Redis 集群，数据迁移完之后，开始做新增数据的追加。适合于私有组件数据迁移到公有云的场景，例如腾讯内部的自研数据库，如 QQ 的 Grocery KV 存储。
使用 DTS 工具将数据迁移到云上，适合于开源组件迁移到公有云的场景，例如自研组件、开源组件、以及基于开源组件二次开发的组件。
私有组件直接上云，由于云上可能没有某些组件，且业务也没有将私有组件改造成云的标准服务，所以只能在云上直接部署一套组件集群，通过同步中心或主备等方式将数据迁移到云上。

下面我们以 MySQL 为例来看看 QQ 数据迁移具体是如何做的。

QQ 是如何完成 20 万台服务器全量上云的？

MySQL 是使用腾讯云 DTS 迁移工作从自研 IDC 迁移到云上的。MySQL 是主从模式，通过内部 DNS 类名字服务来寻址，先分配业务一个实例名称，然后通过 DNS 拿到这个实例的 IP 端口，再去访问具体的实例。DTS 将自研 IDC 的数据迁移到云上的 MySQL 之后，开发团队只需在云上切换服务就可以完成数据实例的迁移。

另外，通过主备模式也可以将 MySQL 迁移到云上。在自研机房有数据库服务器的主和备，在云机房部署几台备机，通过主备同步的方式，把所有数据都同步到云机房，然后将云机房的某台备机切换成主机，将自研的主机降级为备机，完成数据库迁移。