RPG游戏经典的系统架构设计

RPG游戏经典的系统架构设计：

bigword 游戏引擎就是使用这种架构，我认识的很多rpg游戏公司的同事也大致采用了这种架构方式。

loginapp ：登陆服务器，主要负责player 的登陆请求，验证player的合法性，为合法的player分配session，与cilent 采用短连接方式，可以有多个loginapp来负载均衡。验证player通过后，loginapp通过baseappmgr找到一个合适的baseapp 发送给client。

baseapp：我们可以叫做网关服务器，有多个来做负载均衡，与client 使用长连接方式，为player分配适合的cellapp，client发送的消息都通过baseapp转发给cellapp,cellapp返回给client的消息也都经过baseapp，充当游戏消息转发的中转站。baseapp同时负责聊天模块。

cellapp ：可以叫游戏服务器或地图服务器，多个，负责具体游戏逻辑实现，与player 进行游戏交互。

baseappmgr：管理网关服务器，只需要1个，或可以做主从备份方式。负责为player 分配baseapp，并记录player所在的baseapp，cellapp踢客时先通知baseappmgr，然后baseappmgr找到对应的baseapp进行踢客。

cellappmgr：管理游戏服务器，只需要1个，或可以做主从备份方式。负责为player 分配合适的cellapp，并对cellapp进行管理。

dbmgr：数据服务器，所有需要持久的数据，都经过dbmgr与数据库进行交互，dbmgr通过数据缓存，批量事务，本地持久等手段大大提高整体系统性能。对于一般同时在线只有几千的系统dbmgr只需要1个则够，对于超大型系统，玩家超多的系统，则可以使用分区方式，每一个区使用一个dbmgr，系统根据玩家所属的区来选择对应的dbmgr。

revivier：监视器，可以监视所有服务器的运行状态，如有必要可以对服务器进行启动，关闭等各种管理，其功能可以理解为ice中间件中icegrid架构的icegridnode和icegridregistry的进程管理功能

MessageLogger/statLogger：日志服务器，统计服务器，记录系统的日志，或进行必要的信息收集及统计，此模块视整个系统的必要性，可选。

棋牌类游戏常用架构：

我从事过4年的棋牌类游戏开发，使用过的架构大致如上，各模块解释如下。

LoginServer：登陆服务器，主要负责player 的登陆请求，验证player的合法性，为合法的player分配session，与cilent 采用短连接方式，可以有多个来进行负载均衡。验证player通过后，LoginServer找到一个合适的GateWay发送给client。

GateWay：网关服务器，有多个来做负载均衡，与client 使用长连接方式，client 发送的消息都通过GateWay转发给大厅服务器或游戏服务器，大厅服务器或游戏服务器返回给client的消息也都经过GateWay，充当游戏消息转发的中转站，防御网络恶意攻击。将来自不同游戏客户端的消息格式转换为系统内部统一处理的消息格式，系统处理完消息后，再将返回消息交给gateway转化为客户端对应的格式返回。

LobbyServer：大厅服务器，可以有多个，负责游戏大厅中功能，例如游戏桌数目，各游戏桌在线人数等等。

GameServer：游戏服务器，多个，不同的游戏有不同的游戏服务器，具体游戏的逻辑实现。

dbmgr：数据服务器，所有需要持久的数据，都经过dbmgr与数据库进行交互，dbmgr通过数据缓存，批量事务，本地持久等手段大大提高整体系统性能。对于一般

同时在线只有几千的系统dbmgr只需要1个则够，对于超大型系统，玩家超多的系统，则可以使用分区方式，每一个区使用一个dbmgr，系统根据玩家所属的区来选择对应的dbmgr。

本人从事过3年的移动业务运营支撑系统开发，行业术语叫做boss系统，后又转入游戏行业进行游戏开发。现设计一个业务运营支撑系统的架构如下：

详细解释各模块如下：

gateway/dispatch ：网关服务程序，使用多个以及dns来实现负载，负责接受来自外部系统的请求，将外部系统请求的协议格式，转换为内部的协议格式，或反向转换。充当业务消息转发的中转站，防御网络恶意攻击。其中dispatch模块负责事件分发，向注册中心查询业务服务对象地址，并根据业务将业务请求分发给不同的业务服务对象，通过配置实现业务流程的集中控制，顺序控制，有点类似bpel的业务流程定制功能。

busiserver：业务服务程序，一个业务服务程序下有多个业务服务对象。

gridnode：进程管理节点，管理一个节点上的所有进程的启动，停止等，busiserver 通过gridnode向gridregistry动态注册或注销业务服务对象。

gridregistry：注册中心，业务服务对象注册中心，所有的业务服务对象都要向gridregistry注册。dispatch模块只能查询到向gridregistry注册成功的服务对象。gridregistry向 dispatch提供服务对象的地址时，可以选择负载均衡策略。业务服务对象可以静态向gridregistry注册，也可以动态注册。同时gridregistry充当进程管理的中心，gridregistry通过联系所有的gridnode，管理整个系统的所有busiserver，并监视所有busiserver的状态，监视所有gridnode所在机器的压力情况。gridregistry 采取主从备份的方式，另dispatch模块不会每次都向gridregistry请求业务服务对象的地址，而是第一次请求到后，以后直接跟第一次请求到的业务服务对象交互所以gridregstry的压力很小。

dbmgr：数据服务器，所有需要持久的数据，都经过dbmgr与数据库进行交互，dbmgr通过数据缓存，批量事务，本地持久等手段大大提高整体系统性能。对于一般同时在线只有几千的系统dbmgr只需要1个则够，对于超大型系统，玩家超多的系统，则可以使用分区方式，每一个区使用一个dbmgr，系统根据玩家所属的区来选择对应的dbmgr。dbmgr本身也可以通过gridregistry以及gridnode来监控以及管理，本图为了简洁一些略掉。

backendmgr：系统维护人员后台管理系统，此系统通过gridregistry可以获取系统中所有节点的状态以及节点上服务的运行状态，并手工对所有的服务进行管理。

此架构主要参考ice中间件的icegrid架构，以及我从事过的电信行业业务运行支撑系统的架构。可以应用于电信以及电力等各行业的业务运营支撑系统。各位有什么建议，欢迎指点交流。