首页   注册   登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
拉勾
V2EX  ›  推广

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

  •  2
     
  •   wxxshu · 221 天前 · 641 次点击
    这是一个创建于 221 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

    对战类游戏的设计思路

    协议的选择

    游戏设计之初,需要决定选择哪种协议来进行通讯。对于对战类游戏来说,首先推荐的肯定是 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 进行关注。

    目前尚无回复
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2182 人在线   最高记录 4385   ·  
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.3 · 19ms · UTC 15:22 · PVG 23:22 · LAX 08:22 · JFK 11:22
    ♥ Do have faith in what you're doing.
    沪ICP备16043287号-1