微服务本身是为了应对业务逻辑的复杂，需要要的新的组织接口的方式。游戏本身逻辑其实没有这么复杂，比如大厅就是一些基本功能，修改“账号”，登录等。游戏本身就是游戏本身的逻辑。
游戏逻辑服务器本身（比如斗地主等棋牌）因为网络响应性能要求问题（玩家对每个操作的反馈时长敏感度远高于业务系统），所以游戏服务器都是有状态的，状态就存在内存，偶尔会接受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