腾讯云首次披露自研业务上云历程（上）

传统行业转型的过程中，腾讯向来扮演的是数字化助手的角色，腾讯云作为帮助企业数字化转型的入口，也已经成为腾讯的“独角兽”业务。

然而伴随着云业务的增长，腾讯内部业务如何上云，对于外界来说一直是个秘密。近日，腾讯自研上云项目负责人周小军首次披露，腾讯如何把内部海量的自研业务搬上云端的故事。以下是他的分享内容。

大家好，我今天分享的核心内容有三个：

• 腾讯自研业务如何从私有云的模式搬迁到公有云；

• 如何把这些大体量的业务搬到云端；

• 如何拥抱云原生。

腾讯的业务量非常庞大，社交业务包括 QQ 和空间的体量有近二十万台服务器，分布在全国三地。要把如此庞大体积的业务搬到云上，可以称之为“把大象搬到云端”。

今天我就分四个方面向大家介绍腾讯自研业务上云的故事。第一是腾讯业务为什么要上公有云，第二个是业务上云的价值，第三个是如何上云，第四个是以 QQ 上云的案例分享业务上云的过程。

为什么要上云？

1. 腾讯业务的烟囱模式

2018 年以前，腾讯的业务线是类似烟囱一样的模式，每个业务事业群从逻辑层、数据层到后端的容器或虚机层，都是独立一套技术框架和技术体系。每个事业群之间的框架多数是不通用的，一个腾讯的员工从 IEG 转岗到微信事业群，发现他的开发框架可能都要重新熟悉。一个新人来到腾讯之后，面临那么多的服务框架，也不知道如何选择合适的框架着手。

甚至在腾讯的内部论坛上，经常有很多新人发帖问，我该选什么样的工具，我该选什么样的框架，这种情况就导致三种困惑：

• 第一个是很多工程师不断抱怨为什么腾讯内部有这么多名词，不同的工具、不同的框架、不同的平台、不同的数据库和不同的存储等等。

• 第二个是很多部门都开发和使用自己的一套东西，跟其他部门缺乏分享和协作。

• 第三个是开源文化氛围不强。很多部门的代码不开放，或者缺乏文档。我们知道成为一个优秀的组件，组件的文档、支持、社区都是非常重要的，没有这些支持的话，你很难把一个组件做到最优，但是在腾讯内部很多组件是缺少文档，支持力度不足，甚至出现很多无人维护的孤儿组件。

2. 两大开放战略并行

基于以上问题，为了技术体系革新，930 调整后，腾讯内部做了大变革，包括成立新的云事业群，公司内部成立“技术委员会”，启动“开源协同”和“自研业务上云”的两大战略方向。

首先，开源协同就是在腾讯内部，所有的开发团队代码都是开放的，腾讯内部有统一代码库，所有的团队及个人的代码都要在上面公开提交、公开发布。团队与团队协作更好，随时可以去创建个分支，或者提交更丰富的特性功能，形成公司内的开源代码文化，创建更好的工程师氛围。

其次是“自研业务上云”。基于公有云的研发模式，使用云上丰富的组件、丰富的服务，把内部的一些优秀的工具和组件上云，对外开放，在云上做服务。在客户的激励驱动下，不断迭代成为行业内的领先水平。

这是腾讯技术领域一个很大的变革。

上云的价值是什么？

第一是业务价值，业务的研发效率更高，从 0 到 1 开发一个新产品短短一周就能完成，微服务框架、数据库、容器资源、持续集成、持续交付、统一配置中心等等，云上都有现成的服务，研发团队不需要到处拼装各种组件和工具，可以更专注业务研发。

第二是工程师价值，工程师可以使用到整个业界最标准化的服务，基于公有云的研发模式，能够离开封闭的开发环境和组件，同时工程师还可以输出非常优秀的组件到云上成为服务，这也是大多数工程师的梦想。

第三是客户价值，可以给行业输出非常多的公有云的经验。截至 2019 年初，腾讯正式发布的对外开源项目将近 70 个，诸如腾讯云 T stack、蓝鲸智云 BlueKing CMDB、微信开源系列和 TARS 等，都是腾讯开源的典型案例。

如何上云？

1. 业务上云的三个阶段

腾讯自研业务上云也并不是一蹴而就的，而是有三个阶段：

• 第一阶段是从 2017 年开始直播类业务的上云。直播业务上云模式是一整套直播业务从自研机房搬迁到公有云机房，在腾讯云上提供服务，完成国内和海外几十个节点的建设，服务于自研的直播业务和外部客户。上云时打通了内部的运营管理系统和监控系统，同时支持跨云的管理。

• 第二个阶段是沙箱云，这个阶段是在腾讯云上建立一个逻辑隔离的私有网络空间，利用腾讯云的 IaaS 服务，使用云的虚拟机、云的网络、云的机房来支撑自研业务的服务。不过这类模式只属于基础平台上云，并不是整体业务体系完整上云。

• 第三阶段，是在腾讯“930”变革之前， 2018 年 6 月我们就已经开始拥抱公有云，启动自研的整个业务从私有云迁到公有云，这是把整个业务连根拔起搬迁到云上。

上云之前，2017 年，我们所有 QQ 用户还在私有云上，到了 2018 年年底，就已经把一成半的 QQ 用户从华南区迁到广州云。到了 2019 年的 6 月，已经有三成的 QQ 用户在云上，每 6 个 QQ 用户就有 2 个是在云上。我们计划到 2019 年年底，QQ 实现华南、华东和华北三大区域的所有用户全部都迁到云上，实现完整的 QQ 公有云上服务。

2. 上云有哪些流程？

在上云的过程中，我们可以直观的感知到，跟之前烟囱式的架构不同，上云后像 IEG、PCG、WXG 等事业群等，都将在公有云上运行各自的业务。业务会使用公有云的 CLB、接入服务、服务框架，云 PaaS 服务，包括 Redis、MySQL、Kafka、ES、CBS、COS 等等，还有像 K8S 这些公有云上的原生服务。

为了实现这一点，我们做了一些改造，在每个区域的公有云和私有云机房之间拉了专线，实现了公有云私有网络到私有云机房的互通，保证业务能够来回迁移及访问内部服务能力。

根据业务体量不同，业务采用三种方式上云，有改造后上云，有边改造边上云，有先上云再改造。业务可以根据自己的人力资源和上云计划，选择对应的上云方式。

下图是整个业务团队在上云的过程中所做的几个流程：

• 第一是测试，包括公有云上的网络、存储、虚拟机、核心服务，以及单机性能、服务吞吐性能、存储读写性能、业务模块性能等等都经过测试。通过测试之后，我们和云团队一起优化了服务性能，对业务也相应做了改造适配。

• 第二是业务上云方案，包括安全方案、容量评估、服务迁移方案和数据迁移方案等。

• 第三是业务迁移，迁移包括接入层、逻辑层、数据层及文件存储等的迁移。

• 第四是混合云共存，业务会逐渐灰度迁移到云上，比如在线用户从 5%、10%、20%、30%到 100%等，是一个灰度迁移过程。在灰度过程中可以及早发现各种问题，逐一解决，避免大规模上量时出现灾难性后果。这个过程中就存在公有云和私有云的混合部署模式，就要重点关注专线使用容量，做好专线在业务高峰期的预案，以及业务跨混合云访问的服务延迟，及时做好用户在不同云之间调度的策略和方法。

• 最后是业务监控。上了云之后使用立体化的监控体系，度量服务调用质量、用户访问质量和服务可用率等，譬如跟踪用户在私有云和公有云的访问延迟有没有变差，不能变坏，运营质量有没有跟原来保持一致，甚至变得更好。

从测试、方案、迁移、混合到监控，这是我们上云团队所实施的上云迁移整体流程。

3. 企业上云方案

根据腾讯自研业务上云，团队所积累的经验之上，我们抽象出完整的上云方案，也十分符合很多企业上云的实际情况，方案分五个阶段：

• 第一阶段：规划。规划中要对业务系统化的梳理，包括业务评估、容量评估、业务架构、组织体系。组织体系是指上云后组织架构和职能的变化，包括运维职责的变化：例如不再有中间件的运维人员，研发流程的变化；研发、测试和生产环境如何在混合云甚至多云中共存；资源预核算的变化；以前是购买机架和服务器，现在是先充值再按量计费；故障处理流程的变化等。技术体系的组织都要准备跟着公有云转变。

• 第二阶段是方案规划和设计。要做好详细的迁移方案，风险预案，回滚预案，混合云预案，多云预案等，譬如上云过程中数据迁移有问题，出现丢数据，我该如何解决等等。

• 第三阶段是验证。这个是非常核心的阶段，上云前，要有预测试、预验证的过程。可以把一些核心模块，譬如高并发，或延迟非常敏感的模块，在云上做好充分的压测，并跟云服务团队一起优化解决各种问题。

• 第四阶段是业务迁移。迁移就更复杂了，包括服务和数据怎么迁、怎么做好备份，迁移过程中对业务有没有影响，我们用云的通用迁移工具，还是我们自己开发的迁移工具。上云过程中，做好对灰度模块的观察，通过客户端服务质量，服务间调用延迟，全网拨测等监控指标观察业务有没有问题。

• 第五阶段是持续运营。整个服务运营体系都变了，基础运维和公共运维团队变成由公有云的运维团队来支持。内部使用的开源监控工具，或者改造成支持公有云的资源监控，或者使用云上成熟的监控 SaaS 服务。CMDB 要支持多云管理。运营流程也发生很大的变化，服务 SLA 要跟公有云服务商一起制定。

4. 上云过程中的安全

当然，上云的过程中，安全是不可或缺且关键的一环，腾讯是一个非常注重安全的公司，特别是用户数据安全。我们在上云安全这块做了很多安全方案。自研内部、企业内部我们有一整套自研的安全体系。上云后，我们结合云上的一些安全产品，以及原来自研的安全服务和安全策略，制定混合云的安全通用体系。

首先在公有云的大网里，我们会划出一个独立的私有网络 VPC，业务分别去部署。之上有网络防护以及网络安全的产品服务。主机上有主机防护，漏洞扫描等。业务层有应用防护，运维有运维安全，云上有丰富的产品可以去使用。然后我们也打造了一些内部积累的安全方案，并回馈到云上。形成了公有云安全产品和自研安全产品两者相互匹配融合的上云案例解决方案。

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

5. 数据库的迁移模式

在上云过程中，也必然会遭遇到一些比较大的挑战，比如数据的迁移。在私有云到公有云的数据搬迁模式中，我们有四种模式给业务选择。

首先是私有组件数据迁移到公有云的模式。腾讯内部有很多自研的数据库，像 QQ 的 Grocery KV 存储使用的是内部私有协议，云上没有对应服务。业务需要将数据从私有组件迁移到 Redis。

我们采取冷迁移的方式，先将数据全备，然后把数据导到云上 Redis 集群，导完后开始做新增数据追加。怎么追加呢？我们用数据同步中心来实现。后面会有同步中心实现的架构。数据同步完之后，我们通知业务可以切割，留一个业务低峰期时间，比如晚上凌晨 2 点，花 1 分钟把数据路由服务从自研 IDC 切到公有云 Redis 集群上。

第二、三种模式可以统称为开源组件到公有云。我们内部有一些业务，在开源组件之上做二次开发，譬如基于单机 Redis 实现自研分布式 Redis 集群。这些基于自研或开源组件的数据迁移到公有云上对应的数据服务，可通过 DTS 迁移工具来实现。

这个非常简单，也是业界非常通用的做法，我们直接用云上的 DTS 来做自助迁移。这个工具甚至不需要运维操作，开发团队自己在 DTS 窗口上输入几个参数，点个搬迁按纽后就可以自助搬迁。搬迁完成后自助切换或自动切换。

第四种模式是私有组件直接上云。因为有一些组件云上没有，业务也没有资源将私有组件改造成云的标准服务，这个时候业务就将组件集群直接在云上部署一套，数据通过同步中心或主备备等方式搬迁到公有云上。

比如说我在深圳的自研有一台主两台备，那么我再把备 3、备 4 放到广州云，数据同时同步到私有云的两个备和公有云的两个备机模式。所有的主备数据完全同步完成之后，我们再把公有云的备变成主，自研云的主变成备，就相当于是做了切换。

6. 云管平台

还有一点非常核心的就是云管平台。之前内部的配置系统、监控系统、CMDB 等等，都是基于私有云的管理模式。业务上云之后，我们很多运营系统要改造成支持混合云，支持多云的管理模式。譬如业务模块会有 50 个实例在腾讯云上，30 个实例在海外亚马逊云上，30 个实例在内部私有云里，那么我们的 CMDB 必须要支持多云的资源管理。从图中可以看到，底下是我们的整个业务线，下面这些帐号体系、预核算、企业安全、监控等等其他的应用工具或平台，都要改造以适应混合云模式。就拿帐号体系来说，内部员工以公有云的帐号登录云官网来购买、使用和运营公有云上的资源。但内部如何把帐号所使用的资源成本核算到对应的业务，员工离职或转岗后资源怎么回收或转移，如何把帐号绑定给企业组织架构，云官网帐号登陆如何与内部 OA 鉴权等，都是必须要考虑和解决的问题。