账号系统、符文系统、英雄系统、皮肤系统、好友系统、好友之间的交流，这些都是日常操作。 如果流量够大，当然可以用微服务架构来完成。
但这不是这款游戏的核心，它是 MOBA：多人在线战斗竞技场。
有什么特点？ 高速多向通信流/广播/组播/10人之间发布和订阅各种游戏活动的各种通信模式
所以游戏的核心是小团体之间的高速网络通信。 是对方所说的真实时间。 如果有额外的 10ms 延迟，玩家将被诅咒。
微服务为了完美拆解业务，将同一进程中的原有模块拆分为不同的服务，显着增加了额外的网络开销。 更不用说服务网格、各种网关、代理和边车，只需要担心低延迟。
微服务基本上只有一种请求/响应模式。 不能做流媒体？ 微服务通常要求应用程序是无状态的，以便水平扩展。 流式传输本身被添加到状态中。 可以想象，为了提高通信性能，一款英雄联盟游戏很可能会使用同一个服务器来进行这10名玩家之间的通信，这样就可以在本地交换数据，从而最大限度地提高性能。 . 客户端或服务器端统一网关的要求是支持粘性路由。 假设客户端断开连接，下一个客户端必须像以前一样重新连接到同一台服务器。 微服务的无状态、水瓶扩展需求本质上是反粘性路由，因为粘性路由本身就是状态。
对于一个服务器集群来说，同时进行的LOL游戏数不胜数，每一局都可以看成一个沙盒，每个沙盒都处于不同的状态：推了多少塔，杀了多少？ 这是第二次。 对面有多少个超神，20分钟就到了？ 这些是长期存在的状态，直到游戏结束才能被服务器清除。 因此，虽然这些状态不需要写入持久存储，但它们不可避免地会在内存中保留很长时间。 他们都是州。 无论如何，如果你有状态，甚至不要考虑使用微服务。 除非您正在谈论将所有这些状态转移到 redis，否则服务器将不得不在流的中途发出远程请求，并且随着您来回移动，延迟会增加。 无论如何都不好。 （比如，假设对方在你A的水晶中，A的每一次操作都是到服务器沙箱的一个事件流。沙箱中有一个流处理器来计算你的水晶是否爆炸。这个计算需要很 快，你不能远程存储你的水晶健康数据）
这类游戏对网络、内存、CPU优化的要求很高。 整个游戏过程中，几乎没有RPC调用，确实需要远程数据，也应该是prefetch，也就是游戏刚开始的时候。 加载。
微服务不是灵丹妙药，也就是说，它们只是为了轻松拆解原始 CRUD 应用程序。 一是不涉及高级交互方式，二是不涉及分布式系统真正的难点：状态，其实并没有大家想象的那么好用。 感觉微服务改变了互联网的原因是因为 90% 的互联网应用程序只是小规模的 CRUD。
对方没听说过微服务是没有问题的，因为它本身并不是一个深奥的概念。 相反，对方听了你的话，就会知道微服务不适合游戏，说明对方理解能力强，对游戏系统设计有足够的了解深的。