写点什么

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

  • 2020-02-04
  • 本文字数:3721 字

    阅读完需:约 12 分钟

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 的云中架构是“三云一地”,所有用户分布在华北、华东和华南三大区域,其中华南区域又分为广州云和深圳自研机房两大机房。每个区域都是完全独立的存储和业务逻辑服务,华南的整个用户都都可以调度到华北和华东区,业务可以随时在不同的云区域和自研区域之间来回调度。

上云的方式

由于之前 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 上云不只成为了外界衡量腾讯云能力的一个重要评判标准,同时也为产品矩阵中的其它业务上云提供了宝贵经验。


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


2020-02-04 13:035755
用户头像

发布了 497 篇内容, 共 325.2 次阅读, 收获喜欢 1921 次。

关注

评论

发布
暂无评论
发现更多内容

保姆级 tomcat 快速入门

田维常

tomcat源码解读

一文带你学会AQS和并发工具类的关系

比伯

Java 编程 架构 面试 计算机

超越身边80%的人,其实没有你想象的那么难

架构精进之路

认知提升 成长笔记 七日更 28天写作

案例研究之聊聊 QLExpress 源码 (七)

小诚信驿站

聊聊架构 规则引擎 28天写作 QLExpress源码 聊聊源码

Java并发编程实战(4)- 死锁

技术修行者

Java 并发编程 多线程 死锁

电商网站商品管理(二)多种搜索方式

escray

elasticsearch elastic 28天写作 死磕Elasticsearch 60天通过Elastic认证考试

一文带你学会AQS和并发工具类的关系

伯阳

AQS java 并发 ReentrantLock 多线程高并发 lock锁

9. 细节见真章,Formatter注册中心的设计很讨巧

YourBatman

Converter ConversionService Formatter

我们为什么打比方

石云升

28天写作 确认偏误 打比方

JavaScript02 - js的引入方式

Mr.Cactus

JavaScript

2021字节、华为、滴滴Java内部面试题(含答案),新鲜出炉!

比伯

Java 编程 架构 面试 程序人生

APICloud AVM多端开发 |《生鲜电商app开发》项目源码教程

YonBuilder低代码开发平台

大前端 移动开发 APP开发 APICloud

使用 kubectl-rabbitmq 部署和运维 K8S 上的 RabbitMQ 集群

郭旭东

RabbitMQ kubectl kubectl plugin

Python列表对象入门

赵开忠

28天写作

详解HDFS3.x新特性-纠删码

五分钟学大数据

hadoop hdfs

自动驾驶分级,小白能理解的那种(28天写作 Day8/28)

mtfelix

自动驾驶 28天写作

JavaScript03 - window对象的方法

Mr.Cactus

JavaScript

技术创新是PC市场发展基石,英特尔占据明显领先优势

E科讯

使用nodejs和express搭建http web服务

程序那些事

HTTP nodejs 异步IO 程序那些事 web服务

[5/28]产品运维保障体系的质量实践

L3C老司机

【得物技术】代码覆盖率原理与得物app实践

得物技术

测试 原理 代码 得物技术 覆盖率

区块链2021狂想曲:迎接以技术为名的春天

脑极体

也谈Python编码格式

ITCamel

Python 编码格式

Spring Boot 集成Thymeleaf模板引擎

武哥聊编程

Java springboot SpringBoot 2 thymeleaf 28天写作

IO和NIO的对比篇

Java架构师迁哥

JavaScript04 - JavaScript语法

Mr.Cactus

JavaScript

JavaScript05 - JavaScript数据类型

Mr.Cactus

JavaScript

在GitHub中向开源项目提交PR的过程

worry

GitHub pull request

为什么印度不会成为世界工厂?

JiangX

印度 28天写作 世界工厂

限时开放!阿里P8大师终于把这份微服务架构与实践第2版PDF分享出来了

Java 编程 程序员 微服务 架构师

JavaScript01 - 基础

Mr.Cactus

JavaScript

QQ 是如何完成20万台服务器全量上云的?_服务革新_田晓旭_InfoQ精选文章