游戏开发经验谈（二）：对战类全球服游戏的设计与实现

[wxxshu]

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

对战类游戏的设计思路

协议的选择

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