系统架构之三（业务运营支撑系统）

本人从事过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架构，以及我从事过的电信行业业务运行支撑系统的架构。 可以应用于电信以及电力等各行业的业务运营支撑系统。 各位有什么建议，欢迎指点交流。