游戏服务器整体架构思考

1.启动层

        不管是单体架构还是微服务架构,其实服务器本身都是要启动的。 不管是用grpc实现远程调用,还是dubbo,还是说就一个简单的tcp监听,都是要启动的。

      启动的时候,肯定要整合下controller接入层,不管是叫:router还是啥,其实本质是接入层,别人发来请求后,我起码得知道到哪里处理呀。

     有的可以进行一些设计,比如:router,我一个服务器,可能既处理mj,又处理斗地主,又处理五子棋。 我又不想让客户端发送:moduleId+msgId,所以说,我可以做一下设计,比如:把2个int编码为1个(通过移位或者 100*moudleId + msgId也行)。  pomelo协议也有过人之处,router直接就是字符串: mj.enterRoom    fivechess.enterRoom 这样子天然就区分开了,我根据前缀,可以知道要转发到哪里处理(可能是远程节点,也可能是:单服下的某个线程)。

      除了controller的处理外,还有各种初始化,比如:日志。 数据库初始化。监控初始化。rpc初始化。 nats初始化。 世界初始化等等。

2.业务层

        controller // 这个其实就是扫描,知道请求到哪里处理,衔接启动层。

        service  // 业务层,我知道了到那个controller处理自然就知道用哪个service处理。

                注意的是:不要和Manager搞混了,就算是有Manager,也需要独立出来,然后new一个对象处理,我们对外只暴露service接口给各个服务使用,而不是去调用manager中的细节。

        dao // 持久层,而不是说:在service中直接操作数据库。userDao, bagDao。。。

思考:

        有了上面整体的2层架构,一切逻辑就会清晰起来,知道各自模块的职责。

你可能感兴趣的:(#,设计模式,游戏,服务器,架构)