Skip to content

乱谈游戏服务端分布式架构(二)

乱谈游戏服务端分布式架构(二) published on 乱谈游戏服务端分布式架构(二)有71条评论

architecture1

乱谈游戏服务端分布式架构(一),我们提取需求是以服务端在物理机在网络上的部署方式为出发点,这次我们将从另一个侧面来提取需求。

顺便说一下,要全面的描述一个系统的需要从多个不同的侧面来观察,从不同的方向和视角才能获得一个系统的全部需求。好比一个城市,在这个城市中有很多摄像机,每个摄像机都只能捕获这个城市的一个角落或者说一个局部信息,想了解这个城市的概貌,那么需要无数的摄像机。

……扯远了,回到正题上,这次我们立足的出发点为逻辑支撑情况,注意是对游戏逻辑的支撑情况,和物理机部署情况无关。先阐述一下我的期望:

  • 可以支持众多用户连接(>50K)
  • 用户连接本身和用户逻辑之间无强关联性,这样可以解决很多问题:例如用户中途掉线,随即又连接上来的情况,这样用户逻辑部分的数据就不用重读,用户状态也不用恢复,只需要替换一下和用户连接之间的关联性即可
  • 游戏逻辑端可以分类,如验证服务端、数据中心服务端、副本管理端、副本逻辑端、大厅服务端、比赛管理端、房间逻辑端等等
  • 逻辑端功能可以完全分离,比如副本管理端和副本逻辑端可以在同一进程下,也可以各自独立为一个进程运行,便于部署
  • 逻辑端采用多进程单线程模式,便于开发
  • 逻辑端之间会发生通讯,但又不希望众多的逻辑端之间互相连接
  • 数据包进入逻辑端需要有一种机制保证该连接的数据包合法
  • 相同的逻辑端可以启动多个实例,用于支撑更多的用户或者负载均衡。
  • 各个逻辑端可以自由扩展功能,这些扩展对原有逻辑无影响,如:对指定数据包加解密,数据包日志等

看着内容很多,其实不然,而且细细分析下发现,和之前的需求有很多共通之处,提取一下变为简要需求:

  • 一个独立的连接服务端,能支持>50K的用户连接
  • 该连接端同时能接受公网和私网的连接,来自公网的是客户端连接,来自私网的是逻辑端连接
  • 连接端需要管理用户连接和逻辑端连接,各种不同的连接需要分类管理
  • 连接端用于转发各种数据包,并且可以通过扩展模块来添加连接端功能
  • 连接端需管理Token,Token来自一个不需要Token的逻辑端,拥有Token的客户端连接发送的包才会被发往指定的逻辑端
  • 所有的逻辑端都连接到连接端,逻辑端之间的通讯由连接端负责转发。逻辑端连接不需要Token
  • 抽象逻辑端,目前将它分为2类,逻辑管理端和逻辑服务端
  • 逻辑端逻辑处理器实现为外部加载模块,可以随时替换
  • 连接端有OP管理机制,逻辑端负责注册自己能处理的OP,连接端根据OP来分发数据包

 

原创文章,转载请注明: 转载自游戏无界·达秀的黑暗空间

本文链接地址: 乱谈游戏服务端分布式架构(二)

本站作品除特殊申明外均为原创,采用知识共享署名-非商业性使用-禁止演绎 3.0 Unported许可协议进行许可。如果需转载请保持文章完整性和标明原文出处,禁止商业用途。

您对下面的文章也感兴趣吧:

  1. Pingback: nathaniel