源码casino-server剖析(1)--游戏服务的整体架构和实现

前言:
　　最近研究了一些游戏服务器的架构和实现, github上找了几个开源的实现. 有几个感觉不错, 打算仔细研读一下.
　　游戏服务器种类繁多, 这边主要是基于状态同步的棋牌类游戏, 适合入门, ^_^.

研究案列:
　　cashino-server(git地址, 请点击这里)这个项目好像是中国人写的, 从文档和提交者可以略见端倪, 代码是基于nodejs实现, 后端唯一的中间件是redis.
　　项目非常的强大, 可以说实现了一个分布式的版本, 可扩展性强. 添加新的棋牌游戏, 按照固定的套路实现即可. 当前主要实现了2款游戏, 德州和炸金花, 基本上是中外人民喜闻乐见的娱乐项目, ^_^.

解读架构:
　　一般的棋牌类游戏都有一个大厅服务器和具体的游戏(房间)服务器, 这边的架构实现也不例外.
　　
　　其由一个大厅服务器(集lobby, user, gateway), 和具体的游戏服务(cashino)组成. 整个游戏服务架构舍弃了常规的服务注册定位和路由模式, 巧妙地借用发布订阅模式来实现整合. 房间用户数据实时落中心化的存储. 客户端不再需要另起socket直连房间服务, 大厅服务本身可以无状态多节点部署. 当然这一切都是redis的功劳, 或者说项目作者对redis的魔性使用.
　　

　　login server和game server之间, 不再有http/rpc的直接交互, 只有借助redis队列实现的发布订阅关系. 这就是这个项目和其他常规棋牌类游戏服务架构的最大不同.

浅谈消息机制:
　　客户端(h5, android/ios)和login server是基于websocket构建的长链接, 后续的消息交互都是通过login server中转.
　　而服务内部其消息通讯机制, 正如上图的构建中, 全通过订阅/发布的消息队列来实现的.
　　玩家发往房间的消息, 是通过login server节点, 往房间相关的队列推送消息, 对应的game server节点会消费并处理消息. 反之房间发送给玩家的信息, 则往用户对应的队列推送消息, 对应的login server节点会接受, 并同步返回给玩家.
　　login server和game server彼此没有直接交互, 而且登陆于不同login server节点的玩家, 也能在同一个房间一起玩.

整体评价:
　　cashino-server写于3年前, 应该还是属于研究试验型的阶段, 没有经历过真正商业化的考验. 
　　架构上有它独创的一面, 巧妙地利用发布订阅的模式, 解决了内部交互的复杂度. 同时该设计对扩展友好, 可以非常方便扩展新的游戏(房卡模式的棋牌类), 只需要关注游戏本身逻辑就行.

总结:
　　后续会再写几篇文章, 更加深入去研究剖析下该项目, 希翼从中获取更多的知识.