“王者荣耀”高并发背后的故事

1,636
原文链接: mp.weixin.qq.com
堪称中国最火爆的手机游戏“王者荣耀”,拥有亿级用户体量,千万级日活用户,如何快速、低成本地保障业务突发?本文从该问题出发,论述了问题对应的解决方案,并对其效果做出总结。 -- 黎斌 本文导航 ◈ 摘要00% ◈ 背景03% ◈ 一、挑战和问题21% ◈ 1、 业务特点和挑战22% ◈ 2、 目前存在的问题31% ◈ 二、解决方案43% ◈ 1、 突发池系统架构47% ◈ 2、技术优化66% ◈ 精准控制单机负载:负载过高会影响业务质量,需要对单机负载进行精准的控制。68% ◈ 限制磁盘大小:Docker 在 ext3/ext4 文件系统中无法对文件/目录级别进行磁盘大小限制。78% ◈ CPU绑定:默认是绑定所有 CPU,部分单 CPU 负载高会影响母机业务。84% ◈ 效果89% ◈ 总结92% 转载自 | https://linux.cn/go/nhbk  作者 | 腾讯云 / 黎斌

摘要

堪称中国最火爆的手机游戏“王者荣耀”,拥有亿级用户体量,千万级日活用户,如何快速、低成本地保障业务突发?本文从该问题出发,论述了问题对应的解决方案,并对其效果做出总结。

背景

“王者荣耀”是一款国民级手机游戏,用户体量巨大,而且一直保持着较高的更新频率。这种业务场景下,突发也变得非常频繁,然而业务体验是至关重要的,使用 CDN 必不可少。类似地,经常有带宽突发的场景,比如新闻爆点视频、大型直播活动、热门影视剧上线、热门游戏等应用发布。同时,由于家庭带宽和移动网络的快速升级,突发带宽量级越来越大,经常达到 Tb 级,甚至 10Tb 。如何快速、低成本地保障业务突发,成为 CDN 的一大挑战。

2007 年,腾讯自建 CDN[1] 启用,接入了第一个业务腾讯网。到现在 CDN 带宽量级,从最早的数十 Gb,发展到现在的数十 Tb;单业务的带宽也越来越大,大部分业务常量带宽在几百 Gb,部分突发业务达到了 10Tb。网络的快速升级,移动用户爆发式增长,以及视频类业务包括点播和直播的兴起,使得业务突发越来越频繁,突发带宽越来越高,对CDN的要求也越来越高。

自建 CDN 得益于腾讯业务的蓬勃发展,先后支持了游戏下载、流媒体视频加速、春节红包等腾讯内部业务;2014 年腾讯将 CDN 全面能力开放,成为 腾讯云 CDN[1] 产品,除承载内部业务外,也开始接入第三方客户,比如快手点播、斗鱼直播等。以上各种业务都有突发场景,也有很强的成本诉求,在如何低成本地保障业务突发,腾讯 CDN 积累了丰富的经验。接下来就挑战和问题、解决方案、效果三个方面来解析。

一、挑战和问题

下面将从业务特点开始,分析目前存在的挑战和问题。

1、 业务特点和挑战

CDN 多样化的场景,注定了突发业务充满挑战。突发业务具有体量大、场景多样化、 无规律等特点。

☉ 体量大:突发业务带宽大部分都超过 Tb,部分甚至达到了 10T ; ☉ 场景多样化:点播中的热剧和新闻爆点;直播中的 LOL/KPL/DOTA2 等游戏直播,NBA/世界杯等体育直播,演唱会等综艺直播;应用下载中的王者荣耀等游戏下载;静态网页加速中的红包活动、电商促销等; ☉ 无规律:部分突发活动无法预知,活动快要开始或已经开始了才知道,比如新闻爆点。

体量大,需要准备更多的资源;场景多样化,需要满足不同的资源需求;无规律性则对我们的扩容效率提了很高的要求。

2、 目前存在的问题

仅仅为了满足业务突发需求而储备大量的资源,成本太高,会造成资源极大的浪费。所以一般会通过复用资源来应对业务突发。但是直接复用资源,存在两个问题:

☉ 只能复用部分资源:CDN 业务,一般按业务类型来区分平台和资源使用,主要原因是不同业务类型对资源需求不同,比如点播类需要更多的存储;有较多 https 请求的静态页面类,则需要更多 CPU 资源。这种限制使得资源无法充分利用,加大了资源准备的难度。比如视频突发主要使用视频 Buffer,而下载类和网页类 Buffer 无法直接使用,这限制了 Buffer 的大小。即使复用同类型资源,因为涉及多个业务资源的协调,准备时间一般会超过两天,无法应对临时突发; ☉ 无法降低成本:另外针对部分突发业务,比如游戏应用下载,带宽高峰期在上午和中午,如果只使用本平台资源,会导致结算带宽明显上涨,从而增加成本。无法利用同其他业务错峰的特点来降低结算带宽。

二、解决方案

腾讯云 CDN 通过虚拟化复用现有资源,搭建全业务通用的突发池,所有平台共享 Buffer。 突发池中的设备为 Docker 虚拟机,虚拟机有不同的规格,只要业务有需求,都可以按需使用。突发池中的带宽储备达到了 10Tb,基本能满足所有业务突发需求 。任何业务有突发需求,配合自动化上架接口,可在 10 分钟完成 10Tb 突发池的扩容。

1、 突发池系统架构

突发池系统架构见图 1

图 1 突发池系统架构

☉ 突发池:在各平台物理机的上层,由 Docker 虚拟机组成的资源池,对 CPU/内存/磁盘等使用进行了限制,防止对物理机造成影响。原有业务依然部署在物理机上,不用调整。 ☉ 自动化部署和监控系统: 能根据业务实际需求,自动预测需求并扩容 。所有的突发需求,都能在 10 分钟内扩容完成。针对点播/下载业务,自动分发热点文件,降低回源带宽。 ☉ 调度系统:突发业务的突发性和体量大两个特点,使得相比域名调度系统,直通车更占优势。直通车调度更灵活,生效时间快,能达到分钟级。

虚拟机和物理机部署了上报 Agent,业务信息和服务器负载每分钟都会上报到监控系统。监控系统会根据历史带宽预测一个值,并与当前带宽比较,如果当前带宽超过预测值的 50%,则认为有突发。根据带宽上涨的比例,系统会自动从突发池中扩容相应数据的设备。针对提前准备的突发活动,运维可以指定带宽需求量,之后系统便会自动计算设备需求并扩容。

分钟粒度上报的服务器负载信息则为监控系统做调度决策提供了依据。系统会依据机房剩余带宽、服务器带宽、CPU、IO 等综合信息决定虚拟机是否需要从直通车中启用或者禁用。用户访问时先请求直通车调度系统,直通车会根据调度策略返回一个 302 地址,302 地址中为实际 CDN 资源地址。用户跳转到 302 地址,并获取实际内容。

2、技术优化

使用虚拟化技术复用资源的重要前提是,不影响现有业务。这就要求对资源有充分的隔离,比如 CPU/磁盘,以及对带宽的使用。下面是实现过程中存在的几个问题及解决方案:

精准控制单机负载:负载过高会影响业务质量,需要对单机负载进行精准的控制。

解决方案:

☉ 配额系统:直通车中有配额系统,对每个虚拟机可使用的资源做了限制,包括CPU/IO 和带宽。监控系统中上报的信息,结合配额系统,可以确保服务器负载被限定在制定的范围内,粒度为分钟级。 ☉ 部分请求返回 302:对 CPU/带宽/IO 等做了限制后,应用程序能根据母机当前负载,实时判断是否处理一个请求。如果负载在限制范围内,直接处理;如果负载超出限制,则返回 302,使用户跳转到直通车的调度地址,这样能在尽量不影响业务质量的情况对负载做精准控制。程序层面对负载的实时控制,是配额系统的有效补充。 ☉ 网卡流量控制:在极端情况下,业务带宽超过设定阈值,这时虚拟网卡会主动丢包,避免对母机造成影响。

限制磁盘大小:Docker 在 ext3/ext4 文件系统中无法对文件/目录级别进行磁盘大小限制。

解决方案:

◈ 由于腾讯云 CDN 业务基本都是使用 ext3/ext4 文件系统,这种情况下 Docker 只能对根据用户或用户组对磁盘进行限制,但现网业务都是直接在 root 环境下使用。这里我们使用 loop device 来解决磁盘大小限制问题。虚拟机中突发业务使用挂载在 loop device 上的目录,这样就可以间接限制磁盘大小,防止使用太多磁盘影响其他业务。

CPU绑定:默认是绑定所有 CPU,部分单 CPU 负载高会影响母机业务。

解决方案:

◈ 通过脚本每分钟采集一次系统所有单CPU负载,为避免频繁调整和受毛刺数据影响,取15分钟的均值。最后选取负载较低的部分核,并通过配置文件cpuset.cpus来动态绑定,将虚拟机对母机业务影响降低到最小,并且能充分利用资源。

效果

突发池上线后,高效支持了王者荣耀下载、NBA 直播、KPL/LPL 游戏直播等多次大型突发活动,节约成本 2000万。通过共享 buffer,搭建突发池能显著提高突发能力和降低成本。

总结

腾讯云 CDN[1] 通过 Docker 技术复用资源,搭建 Tb 级别突发池,能支持直播、点播、静态等各种业务突发,能自动检测到业务突发需求并在 10 分钟内完成资源扩容,具有发布快,成本低等特点。资源复用能提高资源利用率,为业务提供极大的突发池,但要注意复用业务之间不能相互影响,这需要对服务器进行实时的监控和及时的调度。

另外还有一些待改进的地方,比如内核参数基于容器隔离,方便不同业务调优;部分业务客户端不支持 302 跳转,调度系统需要支持域名调度方式。 

推荐文章

< 左右滑动查看相关文章 >

点击图片、输入文章 ID 或识别二维码直达

原文链接 请访问“原文链接”获得可点击的文内链接、全尺寸原图和相关文章。