TGDC | 腾讯云团队宋永周：搭建云端游戏后台技术

GameLook报道/2020年12月7日- 10日，由腾讯游戏学院举办的第四届腾讯游戏开发者大会（Tencent Game Developers Conference，简称TGDC）在线上举行。

TGDC自 2017年创办以来，一直坚持以开发者视角与需求为出发点，结合行业发展趋势，对大会内容进行不断升级和扩充，旨在为国内外游戏专业人士打造开放的交流分享平台，推动游戏行业良性发展、探索游戏更多可能。

近年来云技术发展迅猛，许多行业对于云技术的需求非常强烈，其中游戏行业目前十分依赖云技术的支持，腾讯云团队多年致力于解决游戏云技术问题。在TGDC12月9日的活动上，来自腾讯云的游戏行业架构总监宋永周先生，为大家分享了腾讯云产品的技术与方案实例。

以下是演讲实录：

宋永周：各位游戏行业的从业者朋友们，大家好。我是来自腾讯云团队的游戏解决方案架构师宋永周，很高兴今天能够TGDC这个舞台上与大家分享，我对游戏技术架构的一些理解和思考。我今天分享的题目叫《搭建云端游戏的脚手架》，为什么选择用脚手架这个词呢？在我看来，构建游戏后台的技术架构和我们工地上去修建高楼大厦是有些相通性的。

很多人问我的职业经历，我一般会这样解释：大家应该都见过建筑工地吧，过去呢我做了十年的游戏运维工程师，就像是工地上搬砖的小工，而我现在呢做游戏解决方案的架构师，更像是工地上负责搭建脚手架，我的工作就是帮助客户的运维，去构建一个稳定安全的环境，让他们能够放心的去搬砖。

所以今天我将以脚手架工的身份和大家一起分析一下，游戏业务的架构在云上搭建会遇到哪些问题。作为我今天分享的一个主题，那接下来呢，我将以一个脚手架工的身份和大家一起去分享一下如何在云端去构建游戏后台的这个高楼大厦。

我今天分享的内容主要有四个方面：

首先第一块是整个行业的问题分析。我会结合过去我们支持游戏客户的一些经验，给大家分享一下我们从客户的视角，去看到游戏架构上云会遇到哪些问题。

第二块是整个游戏架构上云的一些技术结构是什么样子的。具体到环境搭建的环节里面，其实就是图纸怎么画的一个问题。

第三块我会给大家分享一下，我们给客户做了一些架构优化的案例。大家可以理解为如何去改造一个危楼。

第四块我会给大家分享一下，我们在云时代有哪些先进的生产力和工具，能够帮助我们游戏客户能够更快速高效的去构建游戏的技术架构。

结合这两年我们去支持游戏客户的一些经验，我总结下来我们游戏客户上云所关注的点，主要是有三个方面：

首先第一块是成本，因为客户选择迁移上云，他一般是从IDC或者是从其他的友商去迁移过来。如果要选择我们云的话，他首先要考虑说你的成本有没有优势，这是一个很关键的考量点。

第二块的话其实客户也是希望说能够通过上云去做到他业务的一个研发和运营效率的提升。希望说云提供给客户的环境，除了基础的风和水电之外还能够有一些工具类的东西，去帮助他去提升他自己业务的研发和运营的效率。

第三块是客户其实是希望说能够用云这个环境去做一些弹性的保障。对他业务来说的话，在一个时间周期内其实他的业务是有高峰和低谷的，如果用云的话能够更好地去利用云的弹性，把资源做到一个更充分的利用。

了解了客户上云所面临的具体问题之后，我们给客户输出解决方案的时候，可能会从以下四个方面去做考量：

第一块是稳定性。

我们会提供一些高可用SLA和业务的一些指标保证，让客户在云上的业务能够稳定地去运行，能够有一个基础的保障。

第二块是扩展性。

我们其实要给客户提供弹性伸缩和资源调度的能力，去帮助客户在他业务有弹性需求的时候能够快速地去满足他的资源需求。

第三块是生产效率的提升。

我们会通过一些PaaS和SaaS类的产品能力，对整个我们的产品技术堆栈做一个弥补，帮助客户去提升他在研发和运营过程中的一些效率问题。

最后一块是安全性。

我们会通过主机安全和业务安全等两个维度，去保障客户的业务，如果运行在云上的话它是安全稳定的。

接下来我们来一起分析一下，游戏业务架构上云整个过程是什么样的？我们作为一个脚手架工，如何去帮助游戏客户去构建在云上的业务环境？

正式聊这个内容之前，我想和大家一起来去看两款大家熟知的国民级的网游。第一款游戏是《王者荣耀》，大家知道《王者荣耀》它的特点是多人对战，强PVP属性的这么一款游戏。就是说同一个对局里面的玩家，实时是需要知道彼此的位置和操作的。这种类型的游戏它对于网络的要求是非常高的，你所有的操作都是需要通过网络和服务器同步给玩家彼此，所以这类游戏，我们把它叫做匹配竞技类游戏。

相对于这类游戏的话，第二类游戏就是这种，比如说《魔兽世界》它可能是一个PVE属性的游戏，用户在大部分的时间内，他是同一个服务器上的玩家，是不需要知道彼此的位置和状态的。只是说在少量的，比如说同屏或者是同一个副本里面的玩家，他是需要知道彼此的一些状态。这一类游戏其实它对于网络的延迟要求是相对较低的，因为它是一个虚拟世界类的游戏属性，所以一般我们会在它的部署上会选择分区的方式，就是说我每一个区单个区是有容量上限的。这样能够保证用户在，比如说排行榜单或者社交关系上是合理的。

回顾一下整个云上的游戏，其实把它分为大世界类游戏和匹配竞技类游戏，这两种主流的一个技术架构。对于两款技术架构的一个分析我们来看的话，其实我们可以把市面上一些主流的架构去往两种大类型里面靠。

比如说像MOBA类的FPS类的，它可能会属于说匹配竞技类游戏，像MMORPG或者是战争塔防、城防类的SLG类、沙盒类的这种，我们可能会把它归类为虚拟大世界类的一些游戏，以强PVE和强PVP这两种属性来去对游戏技术架构做一个大的拆分。

我们找一组数据来验证一下这样拆分是否合理。这是伽马数据做的2020年上半年Top10的游戏榜单，按照刚才的理论它是成立的，就是说其实游戏，我可以把它分为匹配竞技类游戏和大世界类游戏这两种类型。

搞清楚游戏的技术架构类型之后，我们来分别看一下我现在作为一个脚手架工，我要搭建这两种类型的游戏的技术架构它会有什么样的区别。

首先我们来看一下匹配竞技类的游戏：

匹配竞技类游戏在整个技术架构上看，我们可以把它理解为像一个农贸市场的架构。我们把每一个正在进行中的对局比作一个交易，其实大厅可以认为它是整个交易的一个管理机构，构建这么一个大区，我可以让更多的用户能够在我自由市场里面去做交易。我要考虑的首要问题是如何去支持架构的无限扩展，能够让所有的可以一起玩的玩家在一个区里面，做一个不分区服的架构。

相对于匹配竞技类游戏的架构，我们看一下大世界类游戏的架构：

大世界类的游戏我们可以理解为一个大型商场的架构。其实我所有的区，每一个区大家可以理解为是一个商场里面的专卖店，但每一个专卖店它能够容纳的交易量是有上限的，所以我们在整个架构上是做分区分服的架构，就是说我每个区和区之间相对是隔离的。在这种技术架构底下，运营要去考虑更多的问题是如何去批量管理这些专卖店。可能后期有一些专卖店运营的不好，我要把它关掉或者是我要腾出新的位置来，我要去扩容，要去引更多新的店进来，对游戏运营来讲就是开区。

基于上述内容的话我们在游戏整个技术架构的分类上，就是匹配竞技类游戏和大世界类游戏，我们主要把它分成六种架构类型。

针对于匹配竞技类游戏，因为它可以选择分区和不分区，也可以选择集中部署和分布部署，所以这里有四种架构。对于大世界类的游戏，因为默认是分区的，所以我们就有集中部署和分布式部署两种架构。

接下来我们和大家一起看一下整个架构图。如果我把它画出来它会是什么样子的？这里列举了一个匹配竞技类游戏集中分布的架构。大家可以看一下：

用户从客户端进入到游戏对局，大概经历了有这么几个过程：

首先他会在客户端打开之后去做版本校验，通过CDN获得到客户端的更新包，让用户的客户端到达最新，通过登录模块连接到游戏大厅上来，当用户需要开启对局的时候，这时候其实在大厅上的匹配模块会撮合一个对局，把撮合成的对局的用户传送到一组空闲的战斗服上去，完成战斗的对局。

大概是这么一个架构，这是一个集中式的架构。意思是说我所有的服务其实是部署在一个地方的，用户可以从不同地方去连到服务，完成游戏的对局。这种架构它其实是有缺陷的。对于刚才讲的这种延时要求很高的游戏，它是没法在这种架构底下去完成游戏。

所以相对于集中式的部署的话，就会有分布式部署的架构。

这个架构其实相对于刚才这个图，它的一个区别在后端的战斗服环节，其实除了可以把它放在一起之外，也可以把它放在不同的VPC底下，放在不同的区域底下，再通过腾讯云提供的VPC互通专线把它组成一个内网，这样的话我的用户可以就近去选择连到就近服务器，让游戏体验的延迟会更低。

刚才讲了游戏的技术架构，接下来我想和大家一起分享一下我们做的一个针对于大世界类游戏的分区分服架构优化的一个案例。

首先这里统一一下区和服的概念，我们常规的讲游戏的分区分服，其实有很多种讲法。我们主流的分法是这么讲的：

一款游戏可以通过我的发行区域或者是发行的平台或者是发行渠道，把它分成若干个服，每一个服之间相对是独立的，甚至也是用了不同的帐户体系，在一个服底下因为我是一个大世界类游戏，我要分区可能会把它分成若干个区，一区、二区、三区，分成若干个区，像我们投屏出来的这两款游戏，这是我们腾讯自己的游戏《火影》和《鸿图》，一个服底下这些区之间它是可以共享帐户甚至是充值余额的，这是一个分区分服的架构整体的一个概念。

在云上怎么部署呢？通常我们的客户大部分的客户是这样做的：

有一个平台的服务会有若干组游戏的大区的服务，其实对每一个游戏大区来讲的话，它就是一台物理的机器，我们会在物理机器上去部署它的程序和数据库，当然这种部署也是一个典型的部署方式，维护起来当然也不是很麻烦，但是它会有些问题。

比如说如果我这台服务器挂了，我这个区可能就丢掉了，我的数据是不可以恢复的，或者是我要恢复的时候，它会有一些故障期间的数据就没有了。

第二个其实我的区和区之间它的用户数量是不均衡的，有可能会一区的人特别多，二区的人特别少。这样其实单机的承载是不合理的，一区有风险；二区很空闲。

针对这种架构我们怎么做优化呢？

首先我们是引入一个架构分层的概念。我们建议客户在业务逻辑上把刚才的这种所有业务逻辑糅在一起的架构，拆分为三层。

一个是接入层，接入层包括区服导航、负载均衡以及连接管理、登录等这些逻辑，我把它放在接入层。

在业务逻辑层，我把它拆为小区，每个区自己的业务逻辑的模块。

在存储层的话，我会建议客户把游戏的数据缓存，日志把它单独去存放。

基于架构的优化之后，我们会把这个架构优化成这个样子：

玩家通过高防流量之后， 我会通一个LB把它去连接到游戏服务里面，这里我放一个LB的好处是说一方面可以做一些公网IP的一些收敛；另外也可以针对LB去做一些流量上的防护，保证说后端的区不会被攻击掉，不会像之前的架构一样，部署很多的IP流量防护。如果是各个区之间会有跨服的战斗操作的话，我会通过一个跨服的模块去完成，数据层我会把它单独剥离出来，通过云上的数据库去实现。这样如果我的游戏逻辑挂掉了之后，其实我的数据逻辑是还在的，只要通过CVM的一个热迁移，就会很快的把这个区恢复起来，用户的影响就会变得更低。

这是一个终极的优化架构吗？其实并不是，我们还可以针对这个架构再做进一步的优化。

我们可以看到其实刚才在每个小区逻辑里面，它会有些公共的逻辑，比如说像邮件、商城、聊天、战斗、工会等，这些公共模块。

其实在每一个区里面都是有的，如果说客户的业务架构是一款爆款游戏的话，其实对应的区服是非常多，相当于是说在每一个区里面都要管理对应的公共模块。我们建议第二层客户区可以把这些公共模块拆分出来再做一层，通过一个路由转发的方式，去给单个大区的这些游戏服务器去做服务。这样的话其实会把和用户承载相关的这部分容量，把它切到Gamesvr模块上来，让这边作为实时的针对于用户访问量的扩容或缩容。

第四块我想和大家来去分享一下，在云时代我们客户的业务架构如果说上云的话，会面临哪些问题，以及我们腾讯云作为整个云资源的提供方，我们能够给客户提供哪些东西，帮助客户去解决这些问题。

第一个问题是图纸复用的问题。可以看到这里有个业务架构，游戏这种运营场景底下其实这个架构在不断做变化。比如说你开一个新区或者做老区的一些合并，相当于是这组架构在和其他的区之间做一些相互的操作，如果说客户要去云上开一个新区的时候，他需要去云上把所有对应的每一个资源都买回来再去开新区的话，这样其实他的操作是比较复杂的。

所以基于这种需求，我们给客户提供一个工具叫TIC，就是一个基础设施，通过代码去描述基础设施这么一个工具。

这个工具它也是基于我们公有云通用的资源编排的工具叫Terraform。我们是基于Terraform的裸接口上做了一些用户使用场景的封装。

举一个例子，比如说我们现在左侧有一个这是一个简单的Web server架构，这个架构底下可能有几台机器，可能会有LB，可能会有几个数据库，这个架构我会以一段代码，把它描述下来，我有这个代码之后，其实我只需要在我的TIC平台上去运行下这个代码，对应的业务架构就可以生产下来。

这么做会有一个好处，比如说你要开一个新区，我可能是只需要把老区的一个技术架构把它的代码抠出来，只需要把它的可用区改成另外一个区，在另外一个区运行一下整个区的环境就会生产下来。

我们结合整个客户的运维流程我们来看一下，如果使用TIC之后能够帮助客户解决哪些问题。

其实传统的客户在去用云上运维的时候，会有一个环节叫CMDB，就是说把云上提供的基础设施资源去管理到业务自己的配置中心里面去，再通过你的配置中心去做运维的操作。如果我们通过TIC来去做这个事情，相当于在CMDB前置有一个步骤，这个步骤可以帮助客户快速地去通过代码去云上获取或者是回收你的这些资源。业务侧的运维就可以通过这个环节，让整个从云上获取资源到搭建环境的程就在云上闭环了。能够让客户更快速地去获取到你的基础设施提升整个运维自动化的程度。

第二个问题是弹性伸缩问题。我们可以看到在匹配竞技类的游戏战斗服模块，因为战斗服是整个游戏架构核心算力的一个消耗，尤其像我们对于“吃鸡”和《王者荣耀》这样级别的游戏的话，其实它的战斗服的资源比例已经占到整个游戏后台相当大的一个比例。

假如说这个游戏是一款爆款，经常会做一些运营活动，这时候你要去做运营活动和不做运营活动带来的基础施的弹性优化空间是非常大的。

这里就引用SQLServer的首席架构师有一次分享里面的一个梗他说：所有的运维人员都希望自己维护的这一群机器，它是一群牛而不是娇贵的宠物。从客户的运维思维来讲的话，只希望说我想用服务器的时候就有，而不是说我要实时去照顾到，我的环境底下有多少容量，我需要什么时候来做扩容。

所以我们针对这个场景的话，我们有一个专属的产品方案叫GSE。GSE帮助客户去针对性的解决匹配竞技类游戏的战斗服上云的问题。可以简单看一下GSE业务流程：

游戏客户端连到大厅之后，匹配到对局，匹配到对局之后要给它分配一个房间去完成战斗，这是传统的业务逻辑。在GSE底下会把战斗服的管理事情托管到云上，客户的业务逻辑只需要在你的大厅里面去提成GSE调度的一些服务，当你的对局需要做分配资源的时候，这时候是调云上API去完成资源分配。

具体资源怎么去监管？

我们会在我们托管在云上运行的DSPod相当于是客户自己战斗服的程序，在战斗服程序里面集成一个很轻量的SDK，SDK可以把你的房间的一些资源使用情况上报给我的GSE，通过这样分配到对局之后，会把运行的房间IP和端口再返回给这一组对局的玩家，让玩家能够连到对局上去完成游戏，是这么一个逻辑。当然托管上云之后的话，对客户来讲它可能会成为一个黑盒子，这样我们也是为了方便客户能够去看到，托管在云上的这些服务的运行的情况。我们在控制台上其实是有对应的一些操作接口，我们有个Agent会给客户去实时上报你托管在云上的一些服务运行的一些状态，包括他的监控指标。客户也可以通过云的控制台去做登录和调试。

我们看一下成本的对比，这里有两张图：

一张图是在传统的人工运维时代，做一个包月的容量监测，它对应的成本模型是什么样子的，这个图里面的波浪线大家可以理解为一段时间周期内的业务的最高在线人数；上面这个折线可以理解为它整个业务需要做的建设容量。

在接入GSE之后相当于业务实际使用的容量会比实际的在线人数会稍微高一点点，因为它是实时弹性伸缩的，所以两条红线下面的面积差就是整个GSE能够给客户带来的算力优化的一些空间。

这里有一个具体的业务模型，底下这条不规则的线是以我们一款具体的业务全年在线人数的曲线。如果说我走包月和包年这两种模式的话，有两种成本模型，根据包月和包年两种成本，我们详细算过整个成本的消耗，GSE能够去帮客户节省到20%到30%的成本。这还是一个常规的业务模型，其实它的最高在线点和平时相比，并没有高出很多。如果说在暑期期间，它做了一个周年庆的活动，可能它在线会高出更多，这时候其实GSE能够优化的成本空间可能会更大。

另外除了说能够去做成本优化之外，我们也能够通过GSE去完成一些多地部署和容灾场景。

比如说业务的战斗服，通过托管GSE之后它是部署在不同的区域的，如果第一个区域出现了网络故障，其实在服务器的队列里面只需要把第一个区直接踢掉，相当于说新来的玩家对局就不会分配到第一个区域里面去，这样可以更好地去保障不会因为网络的故障影响了线上的玩家。

第三个问题是模块外包的一个问题。我们可以看到在匹配竞技类游戏的架构里面，其实游戏的数据库是需要具备强的扩展性和高并发能力的，传统的开源数据库或者是单点部署的时候，因为它的容量使用是有上限的，没法满足我们在匹配竞技类游戏做不分区服架构的需求。

这里必须使用到分布式数据库，我们给客户提供的方案是把我们腾讯游戏在过去支持我们内部业务上的两款数据库方案推给线上的玩家。在这里主要是我们的TcaplusDB和Redis混合存储的版本。这两款产品其实都是过去腾讯游戏团队内部研发的，也是经过我们多年的线上业务稳定的压测的产品方案，接下来我会给大家分享一下这里一些进展。

TcaplusDB我们内部是2011年开始研发，在内部已经支持了快400款线上游戏，像大家知道的这些《王者荣耀》“吃鸡”等，基本上腾讯所有自研的手游都用的是TcaplusDB，其实它已经经历了大量的线上用户的压测，包括最近比较火的《王者荣耀》平均DAU一个亿的事情，其实它后端都是我们TcaplusDB在做支持，我们在去年把这款产品搬到云上，目前线上已经有四五家客户在测我们的产品。

我们在2020年的6月份上线了一款Web类业务，从AWS DynamoDB 迁移到腾讯的TcaplusDB。

Tencent TcaplusDB。这里我们主打几个标签，一个是我们专为游戏而生，因为其实放眼行业里面的话，TcaplusDB它应该是整个游戏行业里面同时承载人数最多的游戏数据库，所以稳定性是毋庸置疑的；第二个是我们做了一些兼容游戏场景的一些业务逻辑，比如说在游戏整个运营过程中我们可能会考虑到高可用或者是单用户回档需求或者是一些易用性和安全性的诉求，其实在我们整个TcaplusDB里面架构师都有做考虑，这是整个TcaplusDB的一些进展。

第二块是我们把腾讯游戏内部的TenDis，我们现在云上叫Redis混合存储版也迁移上云，这里主要是解决Redis内存数据库，其实它的成本和安全性是有些问题的。

首先是内存的价格相对于SSD贵很多，另外因为是内存所以说它数据丢掉的话，它对业务是有影响的。我们是基于Redis架构Redis加RocksDB这样一个架构，把数据做冷热分离之后存在SSD里面。这样的话，我们能大幅去降低业务的一个成本，其实最高可能降掉80%，达到20%这么一个成本优化的一个比例。

Redis混合存储版在内部主要是服务我们游戏社区、游戏的助手等这样一些周边产品。我们在外部其实现在也有一些互联网的客户在测这里一些方案。

以上是我今天全部分享的内容，接下来是一个Q&A问答的环节。我们也收集了线上的一些问题。这里我选几个问题来和大家一起分享一下：

首先第一个问题，有人问道：作为游戏的行业龙头，腾讯云在做游戏云业务方面有哪些核心的优势？

我想其实腾讯作为整个国内乃至全球最大的游戏厂商，其实腾讯云做游戏上的优势是非常多的，今天我主要想列举两个方面：

首先第一块我觉得是我们熟悉用户，其实云在给游戏客户做方案的时候，首先会考虑给客户做比如业务架构的推荐和业务选点的推荐，我们给客户做的方案推荐一定是最专业的。因为我们早期腾讯做云也是因为自己的游戏业务和互联网业务发展的一些要求，所以我们在做包括机房选址包括用户去覆盖的这些方案，腾讯云相对于其他云厂商来讲的话，我们有信心说我们是更专业的。

第二块是除了我们能够给客户提供基础设施和网络这些技术的资源之外，我们也会给客户分享我们多年的研发运营游戏的一个经验。大家可以看到我们在产品方案上，除了提供IaaS之外，我们也提供一些像游戏数据库、游戏语音、游戏加速、游戏开发者、一些小游戏开发的功能组件等等。这些PaaS和SaaS类产品目的是为了提供全方位完整的方案，帮助客户积木式地去搭建游戏，去提升研发的效率，降低你的成本投入。

第二个问题，有朋友问到说TcaplusDB在支持游戏业务上有哪些优势以及能否支持游戏之外的行业？

这是一个好的问题，首先TcaplusDB在优势方面，它是一款全自研的分布式NoSQL数据库，它最大的特点就是能够支持水平无限扩展以及高并发的读写，单个节点的读写可以达到30万QPS那是非常高的一个并发能力。目前我们主打的是游戏行业，主要是因为我们这个项目做TcaplusDB这个项目，最早也是因为去要去解决我们自己在研发和运营大规模运营游戏上的一些需求，所以我们在做游戏业务运营的时候是特别出色的。比如说对于单用户回档，不停服更新以及二级索引，去支持在NoSQL架构底下做条件查询，以及不停服更新去解决游戏业务在更新的过程中服务不终止等。在这些场景之下TcaplusDB相对于其他数据库是有绝对优势的。

另外是说在支持其他行业方面其实TcaplusDB它是一款数据库，它当然是没有说一定只支持游戏行业的，实际事实上我们也在考虑在游戏行业之外的其他行业里面去做一些拓展。比如说当你的业务有高并发的需求和平行扩展能力诉求来讲的话。你都可以去选择用TcaplusDB。举个例子，我们广东省的区块链的电子发票，这个项目其实它的后台用的也是我们TcaplusDB。

以上是我全部分享的内容，谢谢大家。