截止到目前,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 上云不只成为了外界衡量腾讯云能力的一个重要评判标准,同时也为产品矩阵中的其它业务上云提供了宝贵经验。
事实上,在采访中陈铁钢也透露出了微信的上云情况,“微信目前已经在灰度上云,且在按照自己的节奏逐步上云。”
评论