游戏开发经验谈(二):对战类全球服游戏的设计与实现 | U刻
  • 游戏开发经验谈(二):对战类全球服游戏的设计与实现

    栏目:技术分享

    游戏开发经验谈(二):对战类全球服游戏的设计与实现

    上篇文章《游戏开发经验谈(一):游戏架构里隐藏的五个坑及其应对方案》,我们主要讲解了游戏架构设计当中隐藏的一些坑及其应对方案,错过的小伙伴可以点击链接回溯之前的内容。本期内容,将会重点介绍对战类全球服游戏的设计思路与技术实现。

    对战类游戏的设计思路

    协议的选择

    游戏设计之初,需要决定选择哪种协议来进行通讯。对于对战类游戏来说,首先推荐的肯定是UDP。

    尽管UDP对开发基础有较高的要求,需要开发者自己实现传输成功检验、重传以及可靠性保证等,但相对于低开发成本的TCP,UDP在效率和时效性上都有极大的优势,它可以根据业务特性进行短间隔重传,或者直接发送复数包来提高弱联网状态的成功率。

    此外,相比于UDP的低延时,TCP的重传时间是秒级,对于对战类游戏来说,TCP的重传速度无疑会造成非常糟糕的玩家体验,虽然有BBR一类的技术,但也仅仅只能实现更高效的带宽利用,对于实际业务响应效率没有特别大的提升。

    当然,除了技术角度分析,公司的实际情况也是需要纳入考虑的重要的一环。总体来说,COC、KOA(阿瓦隆之王)等地图类少交互的游戏用TCP是没有问题的,而CR(皇室战争)、自由之战、全民枪战、枪林弹雨,这类MOBA、FPS等强联网需求的对战游戏,UDP基本是必备的。

    同步机制

    • 帧同步:快节奏、同时希望降低服务器不必要负载的对战类手游,帧同步是不二的选择。帧同步的好处是可以精减上传信息,只是做一些简单的数据汇总上报,需要的带宽非常少。
    • 状态同步:安全性很高,但状态同步需要的带宽量远大于帧同步,而全球服游戏本身面临着非常严峻的全球网络环境,甚至很多情况下需要专线来解决网络问题,这时候,网络开销将是比较大的成本。

    简而言之,一句话:如果你想做全球服游戏,请务必学会帧同步。

    最后,简单说一下对战游戏的几点特性:1)因为采用UDP和帧同步,数据包交互包量巨大;2)玩家快照和帧数据保存需要高性能大容量的内存存储;3)网络稳定要求高;4)架构主要以模块化为主,有的甚至可以两地三中心容灾,需要敏捷部署。

    总体来说,对战类游戏对系统架构有较高的要求。而云平台产品,正是为帮助用户解决这些问题而存在的。

    网络架构设计

    那么,我们是如何为对战类强联网用户提供网络支撑的呢?首先,在网络质量方面,我们采用自建的BGP及自有AS号,直接和电信联通移动等运营商进行路由对接。相比于找中间商,这种方式在网络的覆盖质量、故障容灾能力以及高可用上,都有更好的保障。

    此外,我们将机房和网络进行了分离,网络出口各自独立,通过不同的物理路径走到不同的出口POP点,这里的POP点就是UCloud自建BGP和运营商建立连接的地方,最底层是可用区,也就是传统意义上的机房。当用户在UCloud平台部署的时候,就是利用了可用区的架构。

    这种方式可以将所有的机房资源池化并通过专线打通内网,为用户免费提供相同地区不同机房间的网络互通,方便用户实现跨机房高可用的容灾架构,同时多POP点也可以规避物理路径问题或者运营商本地城域网故障(比如北京本地)带来的影响,保证机房出口的持续高可用。

    基于UCloud云平台的游戏架构示例

    下图是一个基于UCloud云平台的全球服游戏架构,首先,数据存储层直接使用了高可用数据库和Redis来降低运维成本,并保证业务可用性;后端在原生产品的逻辑上,对诸如半同步等功能进行了自研强化,在不改变任何用户使用习惯的情况下,强化数据一致性、安全性、以及查询性能。

    此外,服务器区域采用整体框架集群+高性能负载均衡的接入模式,TCP四层报文转发,保证大并发下的性能可靠;而对战服务器采用了注册机制,房间管理服务器为主从高可用,由于对战采用了UDP+帧同步的模式,包量可能会达到5W-8W甚至更多,因此直接采用了网络增强云主机来承载。

    在全局层面,数据库和负载均衡器都采用了UCloud跨可用区容灾的高可用产品和集群,业务服务器在我们的D/E两个可用区对半部署,保证业务的机房级容灾能力。

    根据对战游戏的特性,简单总结下对战游戏架构设计需要注意的几个点:1)服务集群化。如果要做全球化对战游戏,服务器需要集群高可用,如果是滚服模式,运维成本以及玩家跨服对战成本将会非常高;2)服务模块化。功能拆分时便于管理扩容,并且最大化利用效率节省成本;3)业务自动化。帮助降低运维成本,在业务突发的情况下能够快速扩容提升敏捷性。

    全球服技术实现

    全球服游戏将与人斗的主旨放大化,随着国战以及其他国别特性玩法的加入,基于全球服的对战游戏能够很好地激发玩家的归属感,提升玩家对游戏的黏着度和对战积极度。落实到技术层面,相比于分区对战游戏,全球服对战游戏的实现难度要高上许多,主要在于以下三点:

    • 网络:对战类游戏模式不同对于网络性能的要求不同,但为了保证传输性能,普遍会选用UDP协议实现业务可靠传输;
    • 代码:核心架构可能同分区的对战游戏没有特别大的区别,但是在网络设计、部署架构模式、网络延迟等情况下需要考虑更多;
    • 架构:不管是集中部署还是分布式部署,架构的本地承载量、模块化设计都要考虑应对全球玩家涌入的问题。

    网络

    我国实际出口的公网主要有电信163、联通、移动以及电信CN2四大类,总带宽方面电信是最大的,联通次之,移动最小。就实际利用率来说,电信163出口常年拥堵,可用率不足80%,联通移动情况稍好,但是由于本身出口量较小,应对网络波动的能力不容乐观。

    CN2是电信专门为企业级客户开通的国际出口,这也是中国当前最优的国际出口网络,但即便是CN2也并非完全稳定,根据监控记录显示,CN2链路每月仍然会有几次较长时间的抖动,如果正好赶上游戏大推依然会有风险。

    最保险的方案就是使用专线,专线具有SLA和可用性保证,并具有高稳定、低延迟、零丢包等特性,但是成本相对公网会高上许多。

    UCloud在海外采用的同样是自有BGP技术,并且基于BGP+海外专线,保证最优的访问质量,其基于路由的定位准确度远高于CDN的智能DNS。

    此外,在运维和产品保障方面,我们将国内的模式复制到了海外,并且根据不同的机房情况和地区特性进行了优化,将海外的机房架构和云产品架构在全局上和国内同步,以保证客户体验的一致性和服务的标准性。

    代码

    此前,我们接触过一个用户,他们希望获得一个有保障的网络优化加速方案来实现全球服,并且要求整个加速过程对业务无感知无侵入。简而言之,就是在不更改任何的代码的前提下,实现网络加速。为此我们进行了系列技术调研和方案设计,PathX方案由此诞生。

    前期的设计实现上,我们针对三四层网络转发以及基层代理这两种方式进行了深入调研,调研过程中发现,采用基层代理的方式会中断TCP连接,同时,在使用的过程中还会出现业务无法转发的情况,也就是所谓的“假死”。通过对比,最终我们选择了三四层网络转发的方案,并且做一个比较广的协议支持架构。

    后续,我们也针对CR的UDP对战需求进行了迭代,在原有的基础上融合DPDK和高包量技术,设计了UDP+帧同步高包量业务的承载转发模式。随着全球服时代的到来,我们将这些特性迭代进PathX产品,如今已经是2.0的版本了。

    架构

    全球服情况下,海量用户数据需要集中的接入、处理和分析,而在大数据领域,Hadoop是当仁不让、最经济的大数据解决方案,但是Hadoop的使用门槛非常高,需要至少7-8人的维护团队。而相对使用简单的的普通数据库如MySQL集群等,在性能和性价比上都不是非常理想。

    为了解决用户的高性能大数据分析需求,我们研发了数据仓库解决方案UDW,UDW基于PostgreSQL研发,具有PB级别的高性能数据存储能力,此外,我们根据用户的不同需求区分了存储密集型和计算密集型,可分别用于数据量大或者对计算实时性要求较高的场景。

    下图是一个比较标准的全球服游戏架构图。首先,用户在美国部署核心业务服务器,包括数据库、玩家节点、大数据、登录服等。然后通过全球加速方案,为玩家提供一个质量稳定的游戏服务。有的用户如FPS类的游戏厂商,会在海外额外部署一个小的微型节点,用来保证对玩家的最小延迟和稳定性。

    架构设计中,还有一个比较重要的点是关键帧的使用限制,关键帧和游戏预判会严重影响用户对游戏的要求。比如用户要求延迟控制在60毫秒以内,那么对于60毫秒以上延迟的地区,游戏是无法覆盖的,超过60毫秒的玩家就会直接掉线。

    在部署全球服游戏的时候,除了要考虑网络延迟对玩家的影响,玩家集中涌入对对战的影响等问题之外,还要测算出符合游戏要求的核心节点、不同区域玩家的最佳访问路径、哪个区的玩家可以连接到哪里的服务器等等,这是问题都需要在游戏设计前期就规划好。

    全球服游戏设计的一些想法和建议

    云商、研发、运维这三者虽然分工不同,但都是项目组不可或缺的重要组成。以我过往的经验,运维和研发之间在项目前期的交流通常都非常少,这样就会导致出现故障时,大家经常相互“甩锅”,运维工程师觉得是代码的问题,而开发则认为是运维做得不够好,这对于游戏项目来说是百害而无一利的。

    从项目的角度,建议云商、研发、运维这三者能够做到互相深入合作,云商能够针对游戏用户的诉求,提供最合适的产品和解决方案;运维是保证整个游戏长远稳定运行的核心人员,业务如何做到高可用、如何能够在后期便捷的进行维护,这些都是运维非常擅长的领域;而研发是整个项目能够实现的基石,代码的实现思路会很大程度上固化一个游戏的运维方式。

    在项目建设前期,三方都不应局限于自己的领域,互相协作开放。在项目允许的情况下,研发设计框架时可以联合运维、公有云的架构人员一同评估游戏的实现方式,尽量在前期考虑到系统的可用性、稳定性以及抗压性等问题,这样才能从技术角度避免很多不必要的弯路或者错漏,比如上篇文章所说的中心服单点问题,实现业务的长远发展。

    想要获取更多技术和活动资讯,可扫描以下二维码,关注“UCloud技术公告牌”微信公众号;或搜索微信ID:ucloud_tech进行关注。

     

    5