腾讯的业务体量非常庞大，在2019年，腾讯已拥有超过了100万台服务器，其中，社交业务包括QQ和空间的体量有近20万台服务器，且分布在全国三地。
把QQ这头大象搬到云上并非易事。作为腾讯最庞大、最悠久、最复杂的业务之一，QQ各系统间存在强耦合。上云过程中需要确保对用户零影响，其难度可想而知。
面对重重挑战，QQ是如何迎难而上的呢？本文即将从整体规划、方案执行、里程碑中的挑战等方面介绍其中的技术细节，希望能为大家提供借鉴。
一、整体规划
1.上云整体规划
QQ上云规划时进行了系统化的梳理，包括业务评估、容量评估、业务架构、组织体系（比如运维职责的变化、研发流程的变化、资源预核算的变化、故障处理流程的变化）。
最重要的是，QQ的技术体系跟着公有云进行了转变，确定迁移方案、迁移工具、风险预案、回滚预案、混合云预案、多云预案等。
以过程划分，QQ上云整体规划包含以下三个阶段。
(1)基础设施上云，简单说就是把基于物理网络的自研IDC设备搬到云上，使用基于虚拟网络的云CVM来搭建。
(2)微服务和容器化改造，支持自动扩缩容。
(3)架构和存储升级，全面融入云生态。
其中，基础设施上云是最底层、最基础的第一步，本文将重点介绍。
2.基础设施上云规划
基础设施上云的规划分为两个阶段。
(1)完成所有核心功能模块在云上的搭建，并调度1000万在线用户到云上。
(2)完成整体基础设施上云，并做好云上的三地调度演习。
在计划推行的过程中，腾讯内部多个技术团队精诚合作，共同应对复杂挑战。然而，随着QQ逐步放量上云，面向海量服务的挑战才刚刚开始。
二、方案执行
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服务。
三、里程碑中的挑战
基础设施上云，从用户量级的角度来考虑，主要有几个里程碑：
(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来搭建的，到了云环境，采用相同内存大小的虚拟机来搭建。运维在部署的时候，若把主备本应该分开部署的机器放到同一台实体机上了，这对业务来说简直是灾难。
最后，技术同事们协商确定，由运维来确保同个模块分配的机器不能处于同一台物理机上，实现方式是：在业务同一个集群下的配置组别，打散母机。
四、找对方法，加速上云
在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以前是包交付，现已大量使用容器交付方式。
在微服务这块（如SF2、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全量上云的过程中，很多问题边上云边解决。整个公有云的基础设施和服务已经被锤炼得更加成熟。
五、小结
QQ上云，好比开着火车换引擎。
现在，QQ已经把了华南、华东、华北三大区域的用户全都迁到了云上，实现完整的QQ公有云上服务。是的，“开着火车换引擎”，我们做到了！
这次自研上云的成功，一方面为腾讯云的进一步壮大打下坚实的基础，另一方面，也为QQ自身的技术重生埋下伏笔。
QQ的未来，从此刻开始改变。
关注腾讯开发者，专业的开发都关注了。
