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

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

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

如何把 QQ 的所有用户搬上云？

前面讲了业务上云的思路和方法，QQ 上云是走了这样一个经历。下图就是一张全国地图， QQ 业务有三大区域的数据中心，有华北自研，2015 年这里曾发生了一个很大的爆炸事件，当时我们还把天津的用户调回了华南和华东区域。上海有华东自研机房，深圳有华南自研机房，在香港还有一些海外的出口。三大区域各有三成多的 QQ 在线用户。

根据用户分布情况，QQ 上云时，在华东、华南、华北三地，在腾讯云建设的云机房上，我们创建了业务的公有云网络，然后把 QQ 业务从各地的自研机房往云上迁移。

QQ 上云中业务架构图分成了三大区域，分别是华北、华东、华南，而华南分成了广州云和深圳自研机房两大机房。目前是“三云一地”。每个区域都是完全独立的存储和业务逻辑服务。可以把华南的整个用户全部都调度到华北和华东区。业务随时将用户从不同的云区域和自研区域来回调度。

1. MySQL 数据搬迁

我们接着看下业务的 MySQL 数据搬迁案例，详细见下图，它有主—从的模式。我们没有通过 IP 和 PORT 来寻址，而是通过内部的 DNS 类名字服务来寻址。先分配业务一个实例的名称，然后通过 DNS 拿到这个实例的 IP 端口，再去访问具体的实例。从自研的 IDC 使用腾讯云 DTS 迁移工具，把数据导到云的 MySQL。数据自动导入完成后，开发团队只需要在云上切换服务就可以完成数据实例的迁移。这种适合一些数据体量不大的业务数据迁移。

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

2. 数据同步中心

还有更复杂的是数据同步中心。这种是适合业务量非常大，有全国多地分布的业务。服务模块写数据的时候，统一写到各地的接入代理，代理统一写一地，譬如深圳自研的写服务。

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

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

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

这种方式适合对延迟不敏感的业务，譬如社交业务的点赞、发表说说等。一般从深圳自研同步到上海和天津的时候延迟达到几十毫秒，延迟非常高，不适合金融行业等延时高敏感业务模式。

3. 混合云红包的架构

从 2014 年开始，每年春节腾讯都有春节红包活动，今年春节我们首次在公有云和私有云之间做了红包的两地混合。我们在广州云部署了与自研相同规模的红包服务模块，包括数据集群，在春节前演练及预热阶段，充分对广州云服务做了各种测试和验证，包括跨城专线延迟对业务的影响程度。

红包活动期间，用户在接入的时候根据用户的 ID 分片或用户来源，通过路由策略分流到广州云机房和深圳自研机房。春节期间，混合云扛住了整个红包活动的用户流量。验证了跨地域的混合云完全能支持亿级的业务大并发流量。当然我们也做了很多方案，比如万一公有云的红包模块没有扛住，我们怎么办？如果我们发现用户在云上有大量失败，我们就把用户在几分钟以内切回到深圳云，甚至把整个业务从云上切回本地，我们有信心去扛云机房的压力。

在上云过程中，QQ 研发自身也对业务进行了优化，积极拥抱变化，做了很多处服务的改造，以能够适应新一代的基础设施。

服务逻辑上，很多个业务直接使用云 PaaS 服务，如长消息、加群逻辑等用了云 Redis 存储服务。更多的服务迁移到 TKE 之上，一些内存存储服务，譬如资料、关系链等数据存储层做了链接数、数据副本扩展、混合云单元分布等架构层级的优化改造。

上云前后，上云团队对业务质量非常关注，不断对比二个云之间的可用率、客户访问质量、服务间调用延迟等质量数据。上云前后， 经过各个架构层的优化，业务质量数据最终保持私有云和公有云一致，保证了用户访问体验。

4. 云原生

上云不仅是为了上云，我们更多要拥抱业界开源生态。要用云上优秀成熟的产品和服务。在开发方法、业务交付、云原生服务等方面，业务上云前后已经是部分甚至全部拥抱云原生的体系。我们已经把 TAPD 研发管理工具、工蜂代码仓库，还有蓝盾、橘子 CI、QCI、coding 等集成为工具链，在云上打造了一个持续集成、持续部署的 DevOps 流水线闭环。

目前在云上的交付，业务每周都有几百次的交付是通过容器来完成的，从以前的包交付变成容器交付。

在微服务这块，像 SF2、SPP、TAF 等，我们内部不同业务已经使用了很多微服务框架，并计划在公司内迭代升级更优秀的微服务框架。

5. TKE 引擎

K8S 平台上，我们用了腾讯的 TKE 引擎，这是一个跟 K8S 完全兼容的引擎。我几天前跟一个业界公司聊，他们在腾讯云、阿里云上买了 K8S 服务，自己内部也部署了 K8S 集群。他们的容器可以随时、同时交付到腾讯云、阿里云和他们本身的 K8S 集群，而不用做任何改动。通过容器交付，业务可以不用考虑环境依赖等问题，交付变得更敏捷和轻松。

我们基于 TKE 之上做了功能定制和优化。TKE 有基于 CPU 负载等基础容量的弹性伸缩能力。在 TKE 优秀的伸缩能力之上，我们还做了功能叠加，包括业务画像，就是根据业务长期的趋势和业务突发活动，去做趋势预测和活动预测，通过算法来预估容量在什么时间窗会达到多少水位，以准备相应的容器资源来提前几小时扩容，应对突发流量。

上云团队、业务研发跟云的 TKE 团队合作，我们把业务特性跟 TKE 相融合，来做出一个特性更加丰富、满足业务场景的 K8S 应用功能。譬如 QQ 是三地分布，特别是上云后又增加了自研和云的机房属性。原生 K8S 不支持跨地域的，因此我们做了跨地域的特性。

除此之外还有权限限制，业务对权限要求非常严格，是基于 IP 鉴权的。比如内部的业务模块访问 MySQL 时，要授权 MySQL 要给这些 IP 放行。容器是很难去做这种基于 IP 的权限管理，我们的容器都是用了固定 IP，每个容器都有自己的 IP，交付时注册到 CMDB 上，并完成鉴权等自动化交付流程。

内部的 CI/CD，我们有很多的优秀工具，让业务自行去选择使用，开发团队喜欢什么样的工具，从镜像仓库、到 CI、CD、CO 都能保持业务自己的习惯。还有包括管理体系、安全、审计、服务监控、日志、告警等功能特性，我们增加和优化了近百个特性，满足 TKE 与海量业务结合。

于是，我们总结了八类的 TKE 业务应用适配，从业务管理、网络、路由与服务发现、分批发布、权限控制、镜像仓库、网络存储到远程日志。

6. 蓝盾支持云上 DevOps 的范例

这是蓝盾支持云上 DevOps 的范例，能够实现计划、需求管理、设计、研发、构建、测试、部署、搭建、监控到运营等一整套工具闭环。

所以，从腾讯自研业务上云，再到一些合作伙伴的案例，对于上云的的趋势，我们总结了五点经验：

• 第一，彻底拥抱云原生，用云来满足业务快速迭代，资源弹性伸缩的需求。

• 第二，全面拥抱 DevOps，研发效率更高效。

• 第三，内部的优秀工具上云，给云提供更好的服务。

• 第四，整个开发团队心态更加开放、更加开源，主动与开源社区协同，贡献更多的功能特性。

• 第五，公有云经受了 QQ 海量流量的锤炼，我们在上云过程中，经历很多的经验教训，边上云边解决问题，边上云边优化，将整个公有云的基础设施和服务锤炼成更加成熟。

作者介绍：

周小军，腾讯云资深运维专家。加入腾讯以来先后负责腾讯社交事业群数据存储运维、接入架构运维、社交业务运维等运营工作。拥有十几年互联网 IT 运维经验，精通互联网海量业务规模技术架构、云计算基础架构、自动化运营系统、监控系统等领域。带领团队维护亚洲最大的数据库集群，以及春节 QQ 红包、天津大调度等海量规模业务的运营保障项目。所负责社交业务在线用户 3 亿 ，月活 8 亿，20 多万台服务器集群，全国三地三活数据中心。

本文转载自公众号云加社区（ID：QcloudCommunity）。

原文链接：

https://mp.weixin.qq.com/s/ao7BPrJfPJUVfrUis7UGKw