但是有两个挑战:
每增加一级服务器,状态机复杂度可能会翻倍,导致研发和找bug的成本上升;并且对开发组挑战比较大,一旦项目时间吃紧,开发人员经验不足,很容易弄挂。
这样的模型好用么?
确实有成功游戏使用类似这样的架构,并且发挥了它的性能优势,比如一些大型MMORPG。
但是有两个挑战:
每增加一级服务器,状态机复杂度可能会翻倍,导致研发和找bug的成本上升;并且对开发组挑战比较大,一旦项目时间吃紧,开发人员经验不足,很容易弄挂。
比如我见过某上海一线游戏公司的一个RPG上来就要上这样的架构,我看了下他们团队成员的经验,问了下他们的上线日期,劝他们用前面稍微简单一点的模型。
人家自信得很,认为有成功项目是这么做的,他们也要这么做,自己很想实现一套。
于是他们义无反顾的开始编码,项目做了一年多,然后,就没有然后了。
现今在游戏成功率不高的情况下,一开始上一套比较复杂的架构需要考虑投资回报率,比如你的游戏上线半年内PCU会去到多少?
如果一个APRG游戏,每组服务器5千人都到不了的话,那么选择一套更为贴近实际情况的结构更为经济。
即使后面你的项目真的超过5千人朝着1万人目标奔的话,相信那个时候你的项目已经挣大钱了,你数着钱加着班去逐步迭代,一次次拆分它,相信心里也是乐开花的。
上面这些类型基本都是从拆分MUDOS开始,将MUDOS中的各个部件从单机一步步拆成分布式。
虽然今天任然很多新项目在用上面某一种类似的结构,或者自己又做了其他热点模块的拆分。
因为他们本质上都是对MUDOS的分解,故将他们归纳为第二代游戏服务器。
类型4:
第三代游戏服务器2007
从魔兽世界开始无缝世界地图已经深入人心,比较以往游戏玩家走个几步还需要切换场景,每次切换就要等待LOADING个几十秒是一件十分破坏游戏体验的事情。
于是对于2005年以后的大型MMORPG来说,无缝地图已成为一个标准配置。
比较以往按照地图来切割游戏而言,无缝世界并不存在一块地图上面的人有且只由一台服务器处理了:
每台Node服务器用来管理一块地图区域,由NodeMaster(NM)来为他们提供总体管理。
更高层次的World则提供大陆级别的管理服务。
这里省略若干细节服务器,比如传统数据库前端,登录服务器,日志和监控等,统统用ADMIN概括。
在这样的结构下,玩家从一块区域走向另外一块区域需要简单处理一下:
玩家1完全由节点A控制,玩家3完全由节点B控制。
而处在两个节点边缘的2号玩家,则同时由A和B提供服务。
玩家2从A移动到B的过程中,会同时向A请求左边的情况,并向B请求右边的情况。
但是此时玩家2还是属于A管理。
直到玩家2彻底离开AB边界很远,才彻底交由B管理。
按照这样的逻辑将世界地图分割为一块一块的区域,交由不同的Node去管理。
玩家1完全由节点A控制,玩家3完全由节点B控制。
而处在两个节点边缘的2号玩家,则同时由A和B提供服务。
玩家2从A移动到B的过程中,会同时向A请求左边的情况,并向B请求右边的情况。
但是此时玩家2还是属于A管理。
直到玩家2彻底离开AB边界很远,才彻底交由B管理。
按照这样的逻辑将世界地图分割为一块一块的区域,交由不同的Node去管理。
对于一个Node所负责的区域,地理上没必要连接在一起,比如大陆的四周边缘部分和高山部分的区块人比较少,可以统一交给一个Node去管理,而这些区块在地理上并没有联系在一起的必要性。
一个Node到底管理哪些区块,可以根据游戏实时运行的负载情况,定时维护的时候进行更改NodeMaster上面的配置。
于是碰到第一个问题是很多Node服务器需要和玩家进行通信,需要问管理服务器特定UID为多少的玩家到底在哪台Gate上,以前按场景切割的服务器这个问题不大,问了一次以后就可以缓存起来了,但是现在服务器种类增加不少,玩家又会飘来飘去,按UID查找玩家比较麻烦;另外一方面GATE需要动态根据坐标计算和哪些Node通信,导致逻辑越来越厚,于是把:
“用户对象”从负责连接管理的GATE中切割出来势在必行于是有了下面的模型:
网关服务器再次退回到精简的网络转发功能,而用户逻辑则由按照UID划分的OBJ服务器来承担,GATE是按照网络接入时的负载来分布,而OBJ则是按照资源的编号(UID)来分布,这样和一个用户通信直接根据UID计算出OBJ服务器编号发送数据即可。
而新独立出来的OBJ则提供了更多高层次的服务:
网关服务器再次退回到精简的网络转发功能,而用户逻辑则由按照UID划分的OBJ服务器来承担,GATE是按照网络接入时的负载来分布,而OBJ则是按照资源的编号(UID)来分布,这样和一个用户通信直接根据UID计算出OBJ服务器编号发送数据即可。
而新独立出来的OBJ则提供了更多高层次的服务:
∙对象移动:
管理具体玩家在不同的Node所管辖的区域之间的移动,并同需要的Node进行沟通。
∙数据广播:
Node可以给每个用户设置若干TAG,然后通知ObjectMaster按照TAG广播。
∙对象消息:
通用消息推送,给某个用户发送数据,直接告诉OBJ,不需要直接和GATE打交道。
∙好友聊天:
角色之间聊天直接走OBJ/OBJMASTER。
整个服务器主体分为三层以后,NODE专注场景,OBJ专注玩家对象,GATE专注网络。
这样的模型在无缝场景服务器中得到广泛的应用。
但是随着时间的推移,负载问题也越来越明显,做个活动,远来不活跃的区域变得十分活跃,靠每周维护来调整还是比较笨重的,于是有了动态负载均衡。
动态负载均衡有两种方法,第一种是按照负载,由NodeMaster定时动态移动修改一下各个Node的边界,而不同的玩家对象按照先前的方法从一台Node上迁移到另外一台Node上:
图11动态负载均衡
图11动态负载均衡
这样NodeMaster定时查找地图上的热点区域,计算新的场景切割方式,然后告诉其他服务器开始调整,具体处理方式还是和上面对象跨越边界移动的方法一样。
但是上面这种方式实现相对复杂一些,于是人们设计出了更为简单直接的一种新方法:
图12基于网格的动态负载均衡
图12基于网格的动态负载均衡
还是将地图按照标准尺寸均匀切割成静态的网格,每个格子由一个具体的Node负责,但是根据负载情况,能够实时的迁移到其他Node上。
在迁移分为三个阶段:
准备,切换,完成。
三个状态由NodeMaster负责维护。
准备阶段新的Node开始同步老Node上面该网格的数据,完成后告诉NM;NM确认OK后同时通知新旧Node完成切换。
完成切换后,如果Obj服务器还在和老的Node进行通信,老的Node将会对它进行纠正,得到纠正的OBJ将修正自己的状态,和新的Node进行通信。
很多无缝动态负载均衡的服务端宣称自己支持无限的人数,但不意味着MMORPG游戏的人数上限真的可以无限扩充,因为这样的体系会受制于网络带宽和客户端性能。
带宽决定了同一个区域最大广播上限,而客户端性能决定了同一个屏幕到底可以绘制多少个角色。
从无缝地图引入了分布式对象模型开始,已经完全脱离MUDOS体系,成为一种新的服务端模型。
又由于动态负载均衡的引入,让无缝服务器如虎添翼,容纳着超过上一代游戏服务器数倍的人数上限,并提供了更好的游戏体验,我们称其为第三代游戏服务端架构。
网游以大型多人角色扮演为开端,RPG网游在相当长的时间里一度占据90%以上,使得基于MMORPG的服务端架构得到了蓬勃的发展,然而随着玩家对RPG的疲惫,各种非MMORPG游戏如雨后春笋般的出现在人们眼前,受到市场的欢迎。
类型5:
战网游戏服务器
经典战网服务端和RPG游戏有两个区别:
RPG是分区分服的,北京区的用户和广州区的用户老死不相往来。
而战网,虽然每局游戏一般都是8人以内,但全国只有一套服务器,所有的玩家都可以在一起游戏,而玩家和玩家之使用P2P的方式连接在一起,组成一局游戏: