上篇文章《游戏开发经验谈（一）：游戏架构里隐藏的五个坑及其应对方案》，我们主要讲解了游戏架构设计傍边隐藏的一些坑及其应对方案，错过的小伙伴可以点击链接回溯之前的内容。本期内容，将会重点介绍对战类全球服游戏的设计思路与技术实现。 对战类游戏的设计思路 协议的选择 游戏设计之初，需要决定选择哪种协议来进行通讯。对于对战类游戏来说，首先保举的必定是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毫秒的玩家就会直接掉线。 在摆设全球服游戏的时候，除了要考虑网络延迟对玩家的影响，玩家集中涌入对对战的影响等问题之外，还要测算出符合游戏要求的核心节点、不同区域玩家的最佳拜候路径、哪个区的玩家可以连接到哪里的办事器等等，这是问题都需要在游戏设计前期就规划好。 全球服游戏设计的一些想法和建议 云商、研发、运维这三者虽然分工不同，但都是项目组不成或缺的重要组成。以我过往的经验，运维和研发之间在项目前期的交流通常都非常少，这样就会导致出现故障时，大家经常彼此“甩锅”，运维工程师觉得是代码的问题，而开发则认为是运维做得不够好，这对于游戏项目来说是百害而无一利的。 从项目的角度，建议云商、研发、运维这三者能够做到互相深入合作，云商能够针对游戏用户的诉求，提供最合适的产品和解决方案；运维是保证整个游戏长远不变运行的核心人员，业务如何做到高可用、如何能够在后期便捷的进行维护，这些都是运维非常擅长的领域；而研发是整个项目能够实现的基石，代码的实现思路会很大程度上固化一个游戏的运维方式。  在项目建设前期，三方都不该局限于本身的领域，互相协作开放。在项目允许的情况下，研发设计框架时可以联合运维、公有云的架构人员一同评估游戏的实现方式，尽量在前期考虑到系统的可用性、不变性以及抗压性等问题，这样才能从技术角度避免很多不必要的弯路或者错漏，比如上篇文章所说的中心服单点问题，实现业务的长远发展。 |
小黑屋|在路上
( 蜀ICP备15035742号-1 ) 
GMT+8, 2024-11-27 01:36
Copyright 2015-2024 djqfx
