QQ的业务场景

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

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

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

QQ全量上云的整体节奏

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

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

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

据了解，目前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数据迁移具体是如何做的。

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

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

写在最后

从用户体验来看，QQ是否上云变化并不会太大，但是从QQ自身业务和技术架构来看，上云的益处众多，也更利于未来发展。如果从整个腾讯来看，QQ上云不只成为了外界衡量腾讯云能力的一个重要评判标准，同时也为产品矩阵中的其它业务上云提供了宝贵经验。

事实上，在采访中陈铁钢也透露出了微信的上云情况，“微信目前已经在灰度上云，且在按照自己的节奏逐步上云。”

创作场景

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