无缝世界网游服务器架构的设计思路.docVIP

无缝世界网游服务器架构的设计思路.doc

  1. 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
  2. 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  3. 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  4. 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  5. 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  6. 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  7. 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
无缝世界网游服务器架构的设计思路 过去一年中,花了很多时间在考虑服务器架构设计方面的问题。看了大量文章、也研究了不少开源项目,眼界倒是开阔了不少,不过回过头来看,对网游架构设计方面的帮助却是不多。老外还是玩儿console game的多,MMO Games方面涉及的还是不如国内广泛。看看 \o /Books/BookDetail.aspx?productID=62407 Massively Multiplayer Games Development 1 2 这两本书吧,质量说实话很一般,帮助自然也很有限。当然这也是好事,对国内的研发公司/团队来说,在网游服务器技术方面当然就存在超越老外的可能性,而且在这方面技术超越的机会更大,当然前提是要有积累、要舍得投入,研发人员更要耐得住寂寞、经得起诱惑,在平均每天收到超过3个猎头电话的时候——依然不动心。 上面有点儿扯远了,下面聊聊无缝世界架构(Seamless world server architecture)设计方面的一点儿看法。 先说架构设计的目标——我的看法,服务器组架构设计的目标就是确定各服务器拓补关系和主要的业务逻辑处理方法。主要要解决的问题就是在满足游戏内容设计需要的前提下,如何提高带负载能力的问题。 最简单的架构就是基本的C/S架构,一台Server直接构成一个Cluster,所有Client直接连接这个Server,这个Server完成所有逻辑和数据处理。这架构其实很好,最大的好处就是它架构上的 Simplicity ,Cluster内部的跨进程交互完全被排除,复杂度立刻就降下来了,而且——完全可以实现一个无缝(Seamless world)的游戏世界。但是即使我不说,大家也知道这种单Server架构会有什么问题。不过我们不妨以另外一个角度来看这个Server——一个黑盒子。从系统外部的角度来看,什么样的系统都可以看成一个整体、一个黑盒,而不管系统内部的拓补关系和实现复杂度方面的问题。在不考虑这个系统的实现的前提下,理论上Cluster的处理能力就是由硬件的数量和能力决定的,也就是说一个Server Cluster内包含越多的服务器、服务器越‘快’,那么这个Cluster的处理能力越好、带负载能力越好。那么我们要面对的带负载能力的问题,就是如何高效的利用这些Server的问题,基本上也可以理解为如何提高玩家请求的并发处理能力的问题。 CPU厂商在很久以前就在考虑这方面的问题了,CPU其实也可以看成个黑盒。看看他们用过的技术—— \o /wiki/Pipeline_(computer) 流水线(pipeline)技术、 \o /wiki/Multi-core_(computing) 多CPU/多核(multicore)技术,以及这些技术的衍生技术。我想了很久让 Server Cluster 内部处理并行的方法、并且有了比较清晰的思路之后,才发现其实早就可以参照CPU厂商的方法。流水线的方法就是把一个指令处理拆分成很多个步骤,这样指令的处理被分解之后就可以部分重叠(相当于变成并发的了)执行。我们的Server Cluster一样可以用这种方法来拆分,我想了个名字—— Services-based Architecture——基于服务的架构。在这种架构内部,我们根据处理数据、逻辑的相关性来划分组内各个服务器的工作任务。例如:位置服务提供物体可见性信息、物品服务处理所有物品相关的逻辑、社会关系服务提供行会家族等等方面的逻辑、战斗服务器只处理战斗相关的逻辑,等等。这样划分的话、逻辑处理的并发就有了可能性。举例来说:A砍B一刀这件事情与C从奸商手里买到一件武器这个事情是完全不相干的,而且这2个请求本来就在不同的服务器上被处理,他们是被不同的Service Server并发处理的。这就是 Services-based Architecture 的并发方法。 基本上,把游戏逻辑的处理拆分成一个个的service,就和设计cpu的时候把机器指令的具体处理拆分,然后设计出一个个流水线单元是一个道理。 Cells-based Architecture——基于cell的架构。每个cell都在不同的物理server上面运行着完全一样的应用程序服务器,但是他们负责承载不同的游戏场景区域的游戏逻辑。和 services-based arch. 明显不同的就是,每个cell都是个‘在逻辑上完整的’服务器。它得处理物品操作、人物移动、战斗计算等等几乎所有的游戏逻辑。尽管这么做会带来一些(可能是很复杂)的问题,但是它完全是可行的。举例来说:在吴国A砍B一刀显然地和千里之外在越国的C砍D一刀不搭界,他们完全可以被不同的Cell并发地处理。 基本上,这就相当于一个主板上面插多个CPU或者一

文档评论(0)

153****9595 + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档