首先我们需要了解的是,微服务本身是为了应对业务逻辑的复杂,需要要的新的组织接口的方式。游戏本身逻辑其实没有这么复杂,比如大厅就是一些基本功能,修改帐号,登录等。游戏本身就是游戏本身的逻辑。

游戏逻辑服务器本身(比如斗地主等棋牌)因为网络响应性能要求问题(玩家对每个操作的反馈时长敏感度远高于业务系统),所以游戏服务器都是有状态的,状态就存在内存,偶尔会接受redis,mysql等是绝对不可以的接受的,关系行数据库仅用来定时异步持久化数据,仅游戏服务器而言持久化在redis即可。

 

游戏服务器一般纯需要主动推送,所以第一代微服务网关就没办法满足需求, tcp的没有网关用,spring cloud gateway的web socket也许可以用(但是从防攻击角度讲端游用TCP绝对比web socket合理)。

服务间通信rpc首先ribbon,feign等并不是合适,因为都是基于http的,用Http存在一个消息乱序问题,比如玩家出牌两次,在http就可能出现次序不一致。游戏服务器集群一般使用长连接互联。可能需要用dubbo?(听说是长连接)

 

游戏逻辑服务器(比如斗地主服务器),一般是不能用spring mvc做的,因为线程模型完全不同。多线程模型处理游戏性能差还非常复杂,一般都是使用单进程/线程 驱动固定数量房间的方式(这也是为何服务器一定有状态,一定不能直接读写mysql)。一般就直接netty了,自动扩容在游戏这边叫做开服,早就有固定流程和工具和限流方式了

游戏很多操作不存在服务降级熔断,不行就要直接报错给用户。

大厅服务器登录注册等的确可以做微服务,但是其实也不是做微服务,就是几个接口有自动水平扩容的方案即可。服务注册发现用处不大,开服都是确定的事情,还有一系列运营手段配合,关服也是绝对不能随便关的。

 

游戏处理的流量真的不算多,你在线1万的棋牌游戏已经很赚钱了,10W就是个特别厉害的产品了。

一些独立的服务器比如充值之类的需要微服务化么?只能说这种服务器都需要微服务处理了,项目组做梦都能笑醒。

虽然上面说了很多点,但是其实也是可以考虑用spring cloud改造的,因为游戏集群一样有注册中心,需要服务发现,需要编排启动顺序,只是spring cloud没有为了游戏设计而已,比如至少要完全支持 webflux吧(没有仔细研究),需要一个单线程的长连接最好支持protobuf rpc框架吧(集成服务发现相关功能与接口),网关支持tcp或者至少封装或者暴露一些netty的decoder encoder(或者允许注入)等等TG:li9047

Logo

权威|前沿|技术|干货|国内首个API全生命周期开发者社区

更多推荐