比如 MOBA 类游戏/王者荣耀/LOL，就看王者荣耀的客户端吧，想象一下。

账号系统，符文系统，英雄系统，皮肤系统，好友系统，好友之间 Messaging，这些都是常规操作，如果流量足够大，当然可以用微服务的架构去做。

不过这不是这个游戏的核心，核心是 MOBA：Multiplayer online battle arena。

特性是什么?10 个人之间各种游戏事件的高速多向通讯，Streaming/Broadcast/Multicast/Pubsub 各种通讯模式。

所以游戏的核心在于小规模群体之间的高速网络通信。就是对方说的 Realtime。多了一个 10ms 的延迟玩家就要骂娘了。

①微服务为了把业务完美拆解，把原来的同一个进程里的模块拆分成不同的服务，显著增加额外的网络开销。

更别说什么 Service Mesh，各种 Gateway，Proxy，Sidecar，简直就是担心延迟太低。

②微服务基本只有 Request/Response的模式。做不了 Streaming?微服务通常要求应用是无状态的才能做到水平扩展。Streaming 本身就是加入了状态。

③我可以想像，为了提高通讯的性能，一场英雄联盟游戏很可能会使用同一个服务器负责这 10 个玩家之间的通讯，这样就使得数据可以在本地交换，性能最大化。

这对客户端或者说服务端统一网关的要求是必须支持 Sticky Routing。假设客户端连接断了，接下来的必须重连之前的同一个服务器。

微服务的 Stateless，水瓶扩展要求本身就是反 Sticky Routing 的，因为 Sticky Routing 本身就是状态。

④对服务端集群来说，同时有无数个王者荣耀的比赛在进行，每个都可以看成一个沙盒，每个沙盒都处于一个不同的状态：塔被推了几个了，你被杀了几次了，对面几个超神了，20 分钟到了没。

这些都是长时间存在的状态，直到游戏结束，服务端才可以清理一场游戏的状态。

所以虽然不用把这些状态写进持久性存储，但是必然会在内存中存在很长时间。都是状态，反正有状态，就别想用微服务。

除非你说把这些状态都移到 Redis 里去，那么在服务器在信息流传输到一半还要做一个 Remote Request，一来一回，延迟就上升了。

总之怎样都不好。(比如想象对方在 A 你的水晶，每一次 A 的操作都是一个 Event，被 Streaming 到服务端的沙盒中，沙盒中有一个流处理器，每次接收到一个你水晶被 A 的 Event 都会计算一下你水晶爆了没。这个计算需要极快，你是不可能把你水晶生命值的数据存在远端的。)

像这类游戏，都是对网络，内存，CPU 的优化需求很高，整个游戏进行过程中，几乎不存在什么 RPC call，真的需要 Remote Data，也应该是 Rrefetch，就是在游戏刚开始的时候加载好。

微服务不是什么银弹，也就是方便拆解一下原来的 CRUD 应用罢了而已，一没触及高级的交互方式，二没触及分布式系统真正的难点：状态，其实没有大家想的那么有用。

之所以感觉上好像微服务改变了互联网，只不过 90% 的互联网应用都只是简单小规模的 CRUD 而已。