探讨《王者荣耀》为何未采用微服务架构：游戏服务器设计背后的深刻原因与技术选择

在近日的知乎讨论中，一个引人关注的问题浮出水面：“为何游戏公司不愿意实现微服务架构？”这一话题引发了广泛的讨论。

背景分析

笔者最近参加了一家知名游戏公司的面试。在交谈时，我询问了该公司是否计划采用微服务架构。对方对此表现出惊讶，甚至要求我解释微服务的具体概念。我迅速提到了微服务带来的测试便利性、维护简易性、升级灵活性、服务之间的松耦合性、支持多语言开发和自动扩展等优点。

然而，对方表示游戏服务器并不需要微服务架构，因为它们对实时性有较高的要求，采用微服务反而可能影响性能。他们认为通过分模块的方式开发就足够了。

在我看来，微服务似乎是一个大势所趋，尤其是在大型公司中，游戏服务器的服务应该能够轻松拆分。

在这里，我整理了几个深刻的回答，分享给大家。技术的使用应当针对具体的场景，这一点尤为重要。

以《王者荣耀》为例，考虑其客户端架构，涉及的系统包括账号系统、符文系统、英雄系统、皮肤系统、好友系统以及好友间的消息传递等。虽然如果流量足够大，是可以通过微服务架构实现这些功能，但这些并非游戏的核心。

游戏的核心在于MOBA（多人在线战斗竞技场）特性，强调的是10位玩家之间的高速多向通信、数据流通和实时交互。稍有延迟，玩家的体验就会受到严重影响。

微服务拆分业务时，虽然可以提高模块化，但也显著增加了网络开销。更不用提服务网格、网关、代理等的引入，这些都可能导致延迟问题。
微服务通常以请求/响应为基础，难以实现流式通信。为了实现水平扩展，微服务需要无状态，而流式通信本身就依赖于状态的保持。
为了提升通信性能，像《英雄联盟》这样的游戏可能会在同一服务器上处理10名玩家之间的通信，以便于数据本地交换，优化性能。因此，服务器需要支持粘性路由，这是微服务的无状态特征所无法满足的。
对于游戏服务器集群，每场比赛都可以视为一个状态沙盒，包含各种实时状态信息，这些状态在游戏进行期间会长期存在于内存中，直到游戏结束。

尽管不需要将这些状态存入持久化存储中，但它们会在内存中占据较长时间。状态的存在使得微服务架构难以适用。若将状态信息转移到Redis等远程存储中，势必导致更高的延迟，这对实时性要求极高的游戏来说是不可接受的。

综上所述，这类游戏对网络、内存和CPU的优化需求非常高。游戏过程中几乎不涉及RPC调用，真正需要远程数据时，通常是预加载。

微服务并非万能的解决方案，它更多是便捷拆解CRUD应用的一种方法，在复杂的交互和状态管理上并没有显著优势。微服务的流行，往往源自于大部分互联网应用的简单CRUD需求。

该公司的反应并不奇怪，微服务本身并不是复杂概念，反而能够快速理解其在游戏开发中的不适用性，表明其对游戏系统设计有深入的了解。