账号系统、符文系统、英雄系统、皮肤系统、好友系统、好友之间的交流，这些都是日常操作。 如果流量够大，当然可以用微服务架构来完成。

但这不是这款游戏的核心，它是 MOBA：多人在线战斗竞技场。

有什么特点？ 高速多向通信流/广播/组播/10人之间发布和订阅各种游戏活动的各种通信模式

所以游戏的核心是小团体之间的高速网络通信。 是对方所说的真实时间。 如果有额外的 10ms 延迟，玩家将被诅咒。

微服务为了完美拆解业务，将同一进程中的原有模块拆分为不同的服务，显着增加了额外的网络开销。 更不用说服务网格、各种网关、代理和边车，只需要担心低延迟。

微服务基本上只有一种请求/响应模式。 不能做流媒体？ 微服务通常要求应用程序是无状态的，以便水平扩展。 流式传输本身被添加到状态中。 可以想象，为了提高通信性能，一款英雄联盟游戏很可能会使用同一个服务器来进行这10名玩家之间的通信，这样就可以在本地交换数据，从而最大限度地提高性能。 客户端或服务器端统一网关的要求是支持粘性路由。

假设客户端断开连接，下一个客户端必须像以前一样重新连接到同一台服务器。 微服务的无状态、水瓶扩展需求本质上是反粘性路由，因为粘性路由本身就是状态。

对于一个服务器集群来说，同时进行的LOL游戏数不胜数，每一局都可以看成一个沙盒，每个沙盒都处于不同的状态：推了多少塔，杀了多少？ 这是第二次。 对面有多少个超神，20分钟就到了？ 这些是长期存在的状态，直到游戏结束才能被服务器清除。 因此，虽然这些状态不需要写入持久存储，但它们不可避免地会在内存中保留很长时间。 他们都是州。 无论如何，如果你有状态，甚至不要考虑使用微服务。 除非您正在谈论将所有这些状态转移到 redis，否则服务器将不得不在流的中途发出远程请求，并且随着您来回移动，延迟会增加。 无论如何都不好。 （比如，假设对方在你A的水晶中，A的每一次操作都是到服务器沙箱的一个事件流。沙箱中有一个流处理器来计算你的水晶是否爆炸。这个计算需要很 快，你不能远程存储你的水晶健康数据）