(资料图片)

要理解持续性推流和服务器网格化的重要性，得先了解下现在的游戏服务器架构为什么不满足需求，依据我个人来自某某精英这类传统的单局FPS游戏的开发经验（3.18之前的的星际公民也是这样，3.18之前的星际公民本质上是一个单局类的游戏而不是MMO类型的游戏，这个很重要，后面会说），DS/DGS和Lobby Server一定是分离的。

所谓DS或DGS指Dedicated Server/Dedicated Game Server，我们一般称之为战斗服，负责游戏Gameplay逻辑的处理与同步。Lobby Server一般称为大厅服，用于保存装备等级成就等账号信息数据，处理商城交易、好友等业务逻辑，同时负责拉起DS。当然Lobby Server和DS可以在同一个物理服务器上（一般不会这么做，主要涉及到数据安全和延迟的问题）但是一定是不同进程。登陆大厅的时候玩家的Client只连接到Lobby Server，启动匹配后由Lobby Server找到可以主持一局游戏的DS并匹配其他玩家，然后拉起DS并下发DS的地址到Client，然后Client再连接DS服务器。

Lobby Server里的玩家的装备等数据由Lobby Server下发到DS，然后再通过DS同步到Client。UE或者CryEngine（StarEngine的原型）这类引擎下Client和DS是同构的也即同一份代码运行在不同的地方，通过RPC/值复制（FPS类游戏一般不用锁帧同步）来做Client和DS的通信，通过引擎原生的Actor Channel来传递DS到客户端的数据。所以多数游戏只有Lobby Server是由真正的后台开发人员负责的，DS和Client都是客户端开发人员负责。此时DS内存中的数据为Actor的信息（游戏中的实体，比如一个水瓶，也是Client和DS通讯的基本单元。又比如AI，完全由DS驱动，然后从DS同步到客户端，所以星际公民里DS卡的时候AI就会卡），Gameplay逻辑数据等信息（伤害、Buff、任务的进度之类）等。

这种情况下，Lobby Server的数据保存在持续性的数据库内（一般就是sql数据库了），DS内的数据只存在于DS的内存中而不会保存到数据库（这就是问题所在），所以如果DS宕机或者单局游戏结束，DS里的数据就全部丢失。当然对局结束或者宕机后，部分数据会由DS上报到Lobby Server做永久性保存（比如任务进度之类，FPS游戏都有局内击杀数量达到多少个这样的任务，这个就是DS处理完后再发回Lobby Server的），部分情况下局内也会由Client直接发送协议数据到Lobby Server（某些单局类游戏支持从局内收集金币带出到大厅仓库）。可以参考堡垒之夜在单局游戏内放置一个建筑，这局游戏结束后这个建筑的位置显然不会保存下来，下一次对局开始后这台DS重新拉起Game Mode等Gameplay逻辑。

那如果是这种情况，实际上就面临两个问题，一是建筑类玩法显然是没有办法支撑的，二是一个DS进程主持一局游戏，玩家的上限必然有限制（受带宽、服务器性能的影响，比如星际公民之前玩家上限只有50现在会多一些，UE DS的理论上限大概是1000个客户端，但是实际上也做不到，CryEngine还要更差一些）。所以现有的星际公民实际上是一个单局类型的游戏，你进入游戏宇宙只是进入了一局几十人的游戏，只是这一局游戏会无限长直到这个服务器的所有玩家断开连接或者服务器宕机，这个DS就会被回收，数据被清空，直到下一次由Lobby Server拉起新一局游戏。

那肯定就有人质疑说很早以前就有游戏又能千人同屏，又能在游戏服务器内持久性的保存建筑，比如EVE。这就是游戏类型带来的限制，EVE这类MMO游戏，Client和服务器是异构的，也就是服务器代码和Client代码不同，这类游戏服务器可能既负责玩家数据也负责Gameplay逻辑。并且同步上使用帧同步，所谓帧同步就是有服务器让所有客户端保持同步在客户端和服务端分别进行相同的输入，并保证有相同的输出，并且强制锁定等待服务器和客户端的同步，这就是为什么EVE存在时间膨胀的说法，同屏游戏人数越多，需要同步和计算的数据就越多，服务器帧率就越低，进而导致客户端帧率被降低（因为服务器和客户端之间的帧同步是锁定的）。但是星际公民是一款FPS游戏，需要同步更加精细与更大量的数据，比如子弹的速度，子弹击中的部位等等（也是鉴于此，FPS类游戏大部分数据是由客户端计算并上报给DS再由DS进行校验，这也是为什么FPS等类型游戏外挂会更多），而且即不可能接受服务器帧率和客户端帧率一致的情况（星际公民r_displayinfo 4可以看到服务器帧率一般只有20多帧，这还只是一个服务器几十人的情况）也不可能接受实时同步Lobby Server数据到DS的网络延迟，所以必须采用前面所介绍的Lobby Server分离的值同步的DS-Client的服务器架构，当然这个也存在技术债的问题，早期星际公民直接使用CryEngine开始开发也必然是这种架构。

而星际公民游戏的需求导致必须在传统FPS游戏CS架构的情况下解决一下两个问题，一、持久化DS内存中数据，它包括Actor的位置、状态等一系列Gameplay数据，这是建造、探索等玩法所必需的，玩家在局内对游戏宇宙造成的影响或改变必须是永久性的。二、玩家的数量不局限于单局几十个人，而是像一个MMO一样支持上千人共同游戏。

PES解决第一个问题，持续性推流将DS的中的需要持久化的数据实时保存下来，用于支撑一个持久性的宇宙。然后在此基础上可以解决第二个问题，一个DS的容量有上限，所以最直观的方式就是分布式DS，由原本的一局游戏由一个DS服务几十个玩家改成同一局游戏由多个DS同时服务几百上千名玩家。

但是这就导致了另一个问题，以前是一个DS只需要同步几十名玩家的数据，现在不仅仅DS到玩家需要同步，DS之间也需要同步，如果每一个DS同时向所有其他DS同步数据就会导致整个系统的复杂度变为n^2，即每增加一个服务器节点都需要向所有其他服务器同步数据，这在服务器性能上和带宽上都是不可接受的，所以这就需要服务器网格化，把负责数据同步的部分剥离成一个单独的复制层，所有的客户端和所有的DS都连接到同一个复制层上，复制层是一个专有的服务器，专门用于数据的复制（Replication，游戏开发中的复制一般用这个词），DS不再负责数据同步，而只负责处理游戏逻辑，客户端和DS的数据先同步给复制层，复制层再同步给其他DS和客户端，同时复制层也负责PES将数据进行持久化的保存。所以这两项核心技术一定是必须的，否则星际公民的很多游戏玩法和游戏愿景都难以实现。

当然分布式DS的方案不止星际公民在做，很多开放世界类游戏也需要这类技术，比如TX的G6就有做一套UE的分布式DS方案，但是那个就只是使用了Ghost Actor等方式来实现分布式DS，都不如PES + Server Meshing这么彻底。