游戏服务器一般纯需要主动推送，所以第一代微服务网关就没办法满足需求， 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（或者允许注入）等等。
放浪者这样回答到
。。。有些国民级moba游戏的微服务化过程，可能有保密问题，我就不谈了。
拿中年人喜闻乐见的WOW来说，你们不知道有专门的排队服务器、场景服务器、副本服务器么这些么？你以为每次切换场景时的loading界面在做啥？就是完成service的切换啊。
你非要用web那一套来套在游戏上面，那当然不行，那说明你对microservice的理解太狭隘了。microservice重点是业务逻辑的拆分和独立，难道你以为这么多mmorpg，是一个巨大无比的monolithic的应用在跑？怎么可能。
多人游戏和互联网app相比，最大的差别不是microservice还是monolithic，也不是啥实时还是非实时，而是stateful和stateless的差别。互联网app大量的工作是在数据读写上，为了能疯狂scale，service本身一般是stateless的，最简单的一个例子就是web server的session概念（现在比较过时了，但是是个很好的例子），既可以本地，也可以存入redis或者db。游戏的server其实也是保存这样一个当前场景涵盖所有人的巨大session（比如副本，比如moba中的游戏全局状态）。由于游戏过程本身并没有什么保存价值，所以对这些实时进行的游戏状态进行持久化没啥意义，因此才有专门的对战服务器等等。
其实你把什么对战服务器、排队服务器、匹配服务器等等都叫做xx service，就会发现其实就是微服务概念。
补充一点个人不保证正确的私货：其实整个游戏开发行业和互联网行业的技术思维差异就在于stateful vs stateless，做习惯了游戏开发的人（无论客户端还是backend），习惯了直接在内存读写数据，不习惯从远程读写（无论是redis还是db或者nosql或者啥），换句话说他们不太习惯原始数据不在本地机器上，而恰恰业务逻辑和数据分离是互联网架构的重要指导思想。这使得游戏开发程序员的技术思维很有些不一样，我不能说不好，但是确实有点技能点的配置不同的感觉，这当实现非游戏项目的时候是有障碍的。
评论中的朋友是一个较为典型的例子，始终固守在传统（国内）对游戏单体开发的思路上，你当然可以这么做，但是不意味着就必须这么做，更不意味着这么做就是好的。
一开始我说的国民级游戏之一就是LOL，搜了一下公开资料，，发现他们也略微谈过一点他们后台微服务化的事情
不过他们也是比较含糊其辞的，没谈具体功能模块划分，只含糊举了些抽象例子。所以为了避免有些问题，我也就不提了。