338763208
049-678713176
导航

您的位置:主页 > 摄影业务 >

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

本文摘要:2020年12月7日- 10日,由游戏学院举行的第四届游戏开发者大会(Tencent Game Developers Conference,简称TGDC)在线上举行。TGDC自 2017年开办以来,一直坚持以开发者视角与需求为出发点,联合行业生长趋势,对大会内容举行不停升级和扩充,旨在为海内外游戏专业人士打造开放的交流分享平台,推动游戏行业良性生长、探索游戏更多可能。

leyu乐鱼全站app

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。以上是我全部门享的内容,谢谢大家。


本文关键词:leyu乐鱼全站app,TGDC,腾讯,云,宋永周,搭建,云端,游戏,后台

本文来源:leyu乐鱼全站app-www.getconstructioncarpentryjobs.com