为什么游戏公司的server不使用微服务化？

        相信很多朋友都知道微服务架构（Microservices），这里我还是做下简单介绍，它是一种架构风格，是将单一应用程序开发为一组小型服务的方法。每个服务运行在其独立的进程中，并通过轻量级通信协议（通常是HTTP资源API）进行通信。这些服务围绕业务功能构建，并通过全自动部署机制独立部署。微服务的优势在于代码更容易更新，团队可以对不同的组件使用不同的技术栈和不同的编程语言，并且组件可以相互独立地扩展，从而减少与必须扩展整个应用相关的浪费和成本。

        最近在网上看到这样一篇文章《为什么游戏公司的server不愿意微服务化？》，结合相关资料，总结了以下几点原因，供大伙参考：

1. 稳定性问题：游戏服务器对稳定性的要求非常高，而微服务化可能会增加系统的复杂度，进而增加出现故障的概率。
2. 性能问题：游戏服务器需要支持高并发访问，而微服务化可能会增加系统的延迟和网络通信的开销，从而影响系统的性能。
3. 开发难度：微服务化需要对系统进行细粒度拆分和服务治理等工作，对开发人员的技能和经验要求较高，对于开发人员来说可能会带来更大的工作量和难度。
4. 成本问题：采用微服务化需要增加对容器、自动化部署等基础设施的投入，需要更多的人力、物力和财力支持，对于游戏公司来说可能会增加开发成本和运维成本。
5. 实时性和性能需求：游戏服务器对实时性能的要求非常高，微服务的网络开销和复杂性可能会影响游戏的实时性，尤其是在需要高速多向通讯的场景。
6. 通信模式的复杂性：游戏服务器之间的通信模式通常涉及到实时的 streaming、broadcast、multicast、pubsub 等，而微服务基本上是建立在 request/response 模式上的，不太适合这种高度复杂的通信模式。
7. 状态和内存管理：游戏服务器通常需要维护大量的状态信息，而微服务的无状态特性可能导致在处理这些状态时性能下降，尤其是在需要在本地进行数据交换以优化性能的情况下。
8. 服务间通信复杂性：微服务的服务间通信通常基于 HTTP，而游戏服务器集群通常使用长连接互联。常见的微服务通信工具如 Ribbon、Feign 等可能不适合游戏服务器集群的长连接通信。
9. 线程模型和性能：游戏逻辑服务器的线程模型通常不适用于传统的 Spring MVC，可能需要使用像 Netty 这样的框架。多线程模型的处理在游戏性能要求高的情况下可能更为复杂。
10. 大厅服务器和核心业务：一些部分如大厅服务器的登录注册等可以考虑微服务化，但游戏核心业务，尤其是需要高性能和实时性的部分，可能更适合使用专门优化的单体架构。
11. 流量和用户规模：游戏处理的流量相对较小，对在线人数的要求可能不像一些传统的 Web 应用那样庞大，因此微服务的弹性扩展等特性在这种场景下可能并不是首要考虑。
12. 复杂性与业务简单性：微服务是为复杂的业务场景设计的，而游戏逻辑相对较为简单，使用微服务可能会引入不必要的复杂性。

从以上几点可以看出，由于微服务化在稳定性、性能、开发难度、成本等方面存在一些问题，并且不太适合游戏行业的实时性和高性能需求，因此游戏公司的server不使用微服务化。