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

图片

背景分析

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

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

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

反馈与讨论

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

大佬的观点

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

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

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

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

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

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

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

匿名用户的观点

个人认为，微服务的运用需要一个有稳定技术团队的支持，通常一个服务需要三名以上工程师进行维护，才能真正发挥微服务的优势。而且微服务现在主要基于HTTP协议运行，性能损耗较大，尤其在业务分叉调用时，数据的一致性问题也会让人头疼。

微服务广泛应用于Web领域，因其适应快速变化的业务需求，但实时性要求不高的场景更为适用。

很多时候，微服务被神化了，许多人只学到了一部分技术，却对其应用场景了解不足。微软官方的文献对微服务架构的适用范围进行了明确的说明，值得一读。

其他的观点

游戏服务器普遍带有大量状态信息，采用微服务架构后，服务可能不再本地，这将导致网络传输延迟等问题。RPC调用的可靠性和超时重传设定需要考虑到延迟，玩家体验会受到影响。

虽然可以利用协程等技术来应对这些挑战，但其编码复杂性也会随之增加，导致需要更多高素质的服务器开发人员。