全球服游戏如今正在成为出海游戏的主要考虑模式，跨国对战、全球通服打破国界的限制，将不同地区不同语言的玩家放在一起合作/竞技，成功吸引了大量玩家的关注，并逐渐成为主流的游戏玩法。
游戏厂商们也在尝试采用一地部署多地覆盖、全球逐步宣发的模式进行第一款全球服游戏的发行试点及成本控制。文章主要针对全球服和出海游戏的特性优势、架构布局、网络规划、实用技术等几个方面进行探讨。
本文主要观点：
(1) 微服务是主流，模块化架构易于扩容以及维护，微服务+自动化的业务架构对于全球服游戏来说几乎是必然的选择；
(2) 架构高度自动化，自动注册/剔除保证可用性；
(3) 帧同步+UDP特性，高性能传输和带宽成本控制（对战类游戏要求较为突出）；
(4) 核心架构集中部署为主，全球网络优化覆盖玩家；
(5) 游戏代码的关键帧及预判设计关系到游戏对网络延迟的兼容性。
为什么要微服务和自动化？
原因一：全球服游戏多为逻辑服或无区服概念的通服、对战类游戏。为了保证游戏性和全球化的特点，保证匹配和游戏世界玩家的多元化，传统意义上的区服架构和跨服对战模式并不适配，以皇室战争、列王纷争等为例的一众匹配对战游戏便是其中的代表。
原因二：全球服游戏要求承载全球玩家的涌入，及时发现负载瓶颈并扩容是一个必然的要求，模块化拆分架构之后可以灵活的针对不同活动、玩家特性增加对应的业务服务器，并通过自动注册机制实现快速扩容。
整个架构采用注册管理+自动化之后，可以通过研发脚本或者通行的管理工具，甚至Docker的K8S来实现业务宕机的自动恢复和容灾、负载突发的自动扩容，这可以极大的降低运维成本，并对于业务健壮性进行极大的提升。
对于游戏服务的自动注册机制，在项目早期，受限于研发实力或者工期，开发者一般会选择ZooKeeper进行管理维护，但是在实际运行中由于ZooKeeper自身较重的功能实现、二次开发及bug处理的复杂度，很多用户会将其替换为自主研发实现的轻量级RPC自动注册服务。实际情况要具体视研发能力而定，此外GRPC也有不少的支持者。
帧同步技术和UDP传输协议的使用
关于帧同步主要针对对战类游戏，对于RPG世界或者卡牌类游戏也有一定参考意义，用户使用帧同步主要在于三点：1、全球同步效率；2、服务端压力缓解；3、全球化大流量的成本控制。
以往有过这样的情况，用户在全球服游戏逐步宣发、对应国家客户端上线的过程中，遇到跨国专线成本问题无法承担的问题，最终无奈选择降级服务采用特殊优化过的外网出口覆盖的案例。
而选择使用UDP传输而非TCP传输主要考虑到对战要求的实时性，TCP自身的重传逻辑已经无法满足全球化（对战）游戏的网络保障要求，通过自主实现UDP重传，甚至是报文同时重复发送的逻辑，来保证游戏数据包最终的抵达成功率。
关于帧同步主要针对对战类游戏，对于RPG世界或者卡牌类游戏也有一定参考意义，用户使用帧同步主要在于三点：1、全球同步效率；2、服务端压力缓解；3、全球化大流量的成本控制。
以往有过这样的情况，用户在全球服游戏逐步宣发、对应国家客户端上线的过程中，遇到跨国专线成本问题无法承担的问题，最终无奈选择降级服务采用特殊优化过的外网出口覆盖的案例。
而选择使用UDP传输而非TCP传输主要考虑到对战要求的实时性，TCP自身的重传逻辑已经无法满足全球化（对战）游戏的网络保障要求，通过自主实现UDP重传，甚至是报文同时重复发送的逻辑，来保证游戏数据包最终的抵达成功率。
关于最核心的全球服模式上，我的总结是：先集中再分布。
以当前大部分游戏的框架，如卡牌对战、RPG世界等完全可以通过集中部署+网络调优的方式实现，当前全球双向延迟一般在300ms以内，而一般人的反应时间一般在300ms左右，故网络延迟对于玩家的感知非常微小，大部分游戏都可以集中部署并且不牺牲玩家游戏体验。同时集中部署的另一个优势是对于架构复杂度的降低，维护便捷度的提升，对于成本控制及玩家数据统计也会方便很多。
集中部署全球服架构
什么情况下考虑“再分布”呢？首先，游戏是房间类的对战游戏，其次游戏对于网络延迟极敏感（FPS类），最后重要的点是，游戏架构采取的是对战前缓存预热数据、对战结束后写入的异步模式。
分布式部署全球服架构
下图为对战游戏的基础架构，通过该部署模式要点为：
（1）平台操作仍然集中化部署玩家统一访问，如日常操作、装备购买等延迟不敏感操作；（2）对战房间分布于全球各个数据中心，而当玩家需要对战、进行匹配分房时，通过算法调度到相对大多数用户最近的节点；
（3）节点提前预取相关用户数据，对战产生的全部数据统计由本地进行交互处理，并在对战结束后集中上传至中心数据节点。
对战游戏基础架构
该方案在对战网络延迟和数据一致性上进行了保证，但是相对架构会更为复杂，实际落地过程中需要较好的配合和较深的维护经验。
那么，当前的分布式数据库解决方案是否能够解决全球服数据一致性的问题？实际上，为了保证数据一致性，这里以TiDB为例，暂不支持超过30ms的集群内部延迟。而且即使强行部署，集群内部的高延迟会严重影响QPS性能。在当前的技术环境下，全球分布式数据库最好的代表者应该是区块链技术，不过性能是绝对无法满足大部分游戏使用的，即使是仅有21个核心节点的EOS，其极限QPS也远逊于普通配置的集中数据库。
游戏设计和网络延迟的关系
游戏设计初期必然要对当前全球网络环境有一个初步了解，这点之前也有提到，基本上当前物理链路的双向延迟为300ms内，但是考虑到无线信号不稳定、传统3G网络性能等原因，极端情况可能达500-1000ms甚至更高的情况，游戏必须为此进行一定取舍，早期帧同步游戏会因为网络最差的玩家造成整个战局的卡顿，而随着技术的发展，乐观锁已经通过舍弃低网络质量玩家的部分数据包来保证全球的游戏体验。
简单全球网络数据
这边先不说延迟本身，聊下限制网络延迟的客观因素和数据：地球周长是40076千米 (赤道)，光速恒定299792458米／秒（真空），而网络当前主要是光纤传输，在物理速度和传输介质没有突破性进展的情况下绕地球一周需要近150ms，而实际网络光缆不一定完全直线，中间设备转发也会造成延迟开销，按照实际网络质量评估的话，中国全国覆盖一般在100ms（包括偏远地区）。
我们之前遇到一位用户，研发要求全球服在60ms的延迟以内。按照正常情况，60ms一般可以勉强覆盖北上广三地热门地区。但是要全球服的情况下会比较捉襟见肘，这种情况下，建议做成跨国区域服的模式。
另外关于国际出口的情况，以中国为例，从我们的监控情况看，常规出口的可用率并不乐观，而我们亚太数据中心接入的电信CN2精品网可以做到不错的稳定性保证（也的确有全球服游戏通过此出口传输），但是并不能做到非常完美的SLA，不定期也会发生拥塞和抖动。而且这个问题并不是中国特例，台湾地区、俄罗斯、印尼、印度部分邦都存在有一定的跨国出口问题，需要通过外网接入点选择或者产品解决方案如UCloud PathX解决方案进行网络优化。
PathX案例视图
所以在做一个全球服的项目之前，可以先做调研、和云厂商或者同行多聊聊，基于这些信息，在关键帧和乐观锁的时间制定、游戏内部预判及同步机制的设计上会更有把握。
杂谈拓展：区块链游戏
区块链游戏是一种新兴的游戏模式，但是本质上是依托于以太坊或者其他共识模式的链实现的玩法，当前市场上的游戏主要分两类：1、纯区块链游戏；2、装备或搜集元素上链。
前者主要以以太猫为代表，核心是收集、养成类游戏，随着部分市场关注赋予了部分商业属性。后者则是融合了区块链元素在其内部，附加了很多其他玩法，诸如集换式卡牌等等。
区块链行业还在摸索阶段，共识算法、共同监督、不可否认性是其核心特质，但性能较低、需要支付GAS等也是其短板，现在作相关评论还比较早，如果有兴趣的话，可以钻研下相关共识技术，对于各种链、共识技术有一个认知后，再根据自己的游戏模式选择一个适合的场景。
一般来说区块链游戏和链本身是相互依存的，如果链自身出现问题也会影响到游戏，可以说链是基础支撑，这个在选择的时候建议慎重考虑。我们也在探索相关的技术方向实践，并同公有云进行结合。
作者介绍
沈皓：UCloud PathX产品早期方案设计者之一，深耕全球服游戏领域，曾全面负责多个知名游戏出海项目的全球/跨国业务对接、部署及落地。对于MOBA、RTS、FPS等各类游戏的出海全球化的需求、难点、架构实现等深入分析并有独到见解。
本文来自 UCloud技术公告牌，本文观点不代表GameLook立场，转载请联系原作者。
