TGDC | 搭建云端游戏的脚手架

发表时间：2021-01-07 10:04:05 作者：编辑部 来源：游戏王国 浏览：次

在上一篇文章中，小编为您详细介绍了关于《自制豆浆豆渣能吃吗蚂蚁庄园蚂蚁庄园自制豆浆答案[多图]》相关知识。本篇中小编将再为您讲解标题TGDC | 搭建云端游戏的脚手架。

2020年12月9日，由腾讯游戏学院举办的第四届腾讯游戏开发者大会（Tencent Game Developers Conference，简称TGDC）于线上举行。来自腾讯云的游戏行业架构总监宋永周先生，分享了腾讯云产品的技术与方案实例。以下是分享视频和文字实录：

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

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

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

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

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

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

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

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

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

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

第二块，客户希望通过上云，做到业务研发和运营效率的提升。云提供给客户的环境，除了基础的风和水电之外，还有一些工具，帮助他提升业务研发和运营的效率。

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

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

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

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

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

最后是安全性。我们会通过主机安全和业务安全两个维度，保障客户的业务运行在云上是安全稳定的。

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

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

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

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

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

我们找一组数据来验证一下，这样拆分是否合理。这是伽马数据做的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%这么一个成本优化的一个比例。