Post

“全球同服”游戏服务器设计思路

背景

最近查阅了一些“全球同服”服务器架构设计的资料,也请教了有全球同服架构经验的几位大牛,发现全球同服并没有想象中的那么困难。对于玩家而言,玩家并感知不到自己属于哪个服务器(登陆时无服务器列表),但实际上,玩家通过既定算法,被自动分配到了某个服务器中进行游戏。

分布式设计方案

因为服务器单服因承载量的原因,不可能将所有玩家都放在一个服务器(机器硬件),因此,全球同服的服务器架构都使用了分布式设计。

服务器组一般由登陆服(login)、网关服(gs)、逻辑服(ls)、中心服(cs)、战斗服(fs)、以及交互功能的服务器,例如:好友服(friend)、聊天服(chat)、工会服(union)、排行服(rank)等服务器组构成。

  • 登陆服:登陆一般分为自有渠道登陆和第三方渠道登陆,登陆流程一般为登陆信息校验、帐号id获取。玩家之间无交互过程,因此可做分布式部署。

  • 网关服:网关服主要负责与客户端通信,玩家间无交互过程,可做分布式部署。

  • 逻辑服:逻辑服即游戏内主要玩法的实现,有些架构中 也称为游戏服,只做单机类玩法,无玩家间交互,因此也可做分布式部署。

  • 中心服:有些架构中也称为世界服、全局服,苍龙称为列表服,中心服作为所有逻辑服的连接枢纽,不同逻辑服间玩家的交互依靠中心服转发,拓扑图呈现星型结构,因此中心服无法做分布式部署。(如果玩家量级太大,中心服无法承担现有玩家通信压力,就只能扩展中心服,但这样就相当于做了玩家分区,例如:《恋与制作人》,现在出现了2服)。

  • 战斗服:战斗服顾名思义就是承担游戏内战斗玩法,实现战斗内的各项功能,最终产出战斗结果。只需同时获取到战斗双方的信息即可开战,因此可做分布式部署。

  • 好友服、聊天服、工会服、排行服等:因特殊功能性一般不做分布式扩展。

综上所述,在全球同服的设计模式下,除了中心服及各种交互功能服无法做分布式部署,其他服务器节点都可做分布式部署,承担全球同服的服务器压力。

目前市面上全球同服的作品

《部落冲突》(COC):游戏不分服,客户端与服务器连接推断是长连接,可以加入部落(公会),有掠夺战,有伪世界聊天,公共频道说话并非每个玩家都能看到。

《恋与制作人》:目前IOS版增开了2服,推测是因为玩家过多,全局服务器无法承担通信压力。客户端与服务器通信很像是短连接,可长时间处于断网状态,只要断网时游戏内无操作即可正常游戏,无世界聊天。

《奇迹暖暖》:与《暖暖环游世界》玩法很像,都是少女换装养成类游戏。客户端服务器通信应该是短链接。奇迹暖暖增加了很多社交性玩法,比如竞技场跟玩家PK,搭配赛的参与和点赞,之后又开了联盟。

两种分布式方案:数据分散存储与集中存储

在分布式服务器架构中,玩家感知不到多个游戏服(Virtual Server)的存在,每次登陆时,通过云中算法为玩家分配游戏服ID。

  • 方案一:数据分散存储

image

如上图所示,假设玩家1被分配到了1服,玩家2被分配到了2服。如果数据分散存储,则玩家1数据存储在了1服的数据库中,玩家2存储在了2服的数据库中。那么玩家1以后每次登陆,都只能被分配到1服中。

优点:

  1. 减少了数据存储难度,采用常规数据库存储即可。
  2. 可沿用常规服务器架构设计(非全球同服)中的数据持久化方案,代码改动量少。
  3. 可沿用以往服务器承载量经验,服务器简单、稳定、可靠。

缺点:

  1. 无法使多个服(Virtual Server)实现负载均衡,可能会出现某个服玩家过多,某个服玩家过少的情况。
  2. 若某个服负载严重时会出现排队登陆的情况(玩家看来就是某些用户需要排队,某些用户不用排队)。
  • 方案二:数据集中存储

image

如上图所示,采用数据集中存储,则以后无论玩家被分配到哪个服(Virtual Server),都可以通过分布式数据库(Distributed Storage)加载玩家数据。

优点:

  1. 可以通过调整云中登陆算法,实现各服的负载均衡
  2. 若所有服(Virtual Server)都已达到负载上限,可通过增加Virtual Server服务器组来增加全服承载量,不会出现排队情况

缺点:

  1. 需要高吞吐量的数据库支持,我目前打算采用的有MongoDB Sharding或Redis Cluster
  2. 对搭建数据库的服务器硬件配置要求较高,因为需要较大内存和较高吞吐量的磁盘IO和计算性能较高的CPU
  3. 服务器架构较为复杂,能复用以往项目的代码较少。
  4. 无法处理(或者很难处理?)离线玩家数据,例如要攻击名叫XXX的玩家,因为XXX并不在线,他的数据未加载到任意一个服中,因此无法交互。

总结

  1. 可以看出,采用方案二的数据存储模型更为科学,但同时对代码质量也有较高要求。
  2. 全球同服的架构设计中,技术难点与承载量瓶颈在于中心服的设计,这是影响全服承载量的关键。
  3. 全球同服的玩法设计,应尽量避免与不在线玩家的数据交互(若采用方案二的数据存储模型)。
  4. 因为同时在线玩家数量巨大(可能是十万级甚至百万级),应尽量避免广播全区全服聊天、跑马灯信息,可参照COC的方式做伪世界聊天,并非所有玩家都能看到。
This post is licensed under CC BY 4.0 by the author.