为什么游戏公司的server不愿意微服务化？
首先，得明白什么是微服务。简单来说，就是把一个庞大的、功能紧密耦合的单体服务，拆分成一系列小而独立的、专门负责某个具体功能的服务。这些服务之间通过轻量级的通信方式（比如API调用）来协调工作。听起来很美妙，对吧？但实际落地到游戏服务器，那感觉就像是要把一个精密的瑞士手表拆开，然后重新用乐高搭起来。
历史包袱和技术债务：
很多游戏公司，特别是那些经历过早期互联网浪潮或者拥有几款“长寿”游戏的公司，它们的服务器架构往往是随着时间一点点堆叠起来的。最早的时候，可能为了快速上线或者资源有限，大家就直接上一个大而全的单体应用，把登录、匹配、战斗逻辑、排行榜、社交等等所有功能都塞在一起。这种架构在早期可能很有效率，开发和部署都比较直接。
但随着游戏版本的迭代、功能的新增、玩家数量的激增，这个“大单体”就像一个不断膨胀的巨人，内部的代码越来越复杂，不同功能模块之间的依赖关系也盘根错节。这时候要强行拆分成微服务，就如同想把一个已经固化的水泥块分成很多小块，而且要保证每一块都能独立工作，这简直是噩梦。
代码耦合严重： 很多功能，比如玩家的装备数据，可能在单体里被多个模块直接访问和修改，没有明确的界限。一旦拆分成微服务，你就得找出这个数据的所有使用者，然后定义清晰的访问接口。这工作量可能比重写这个功能还要大。
遗留技术和历史遗留问题： 老游戏可能用的是一些现在看来效率不高、维护困难的技术栈。你想把这些东西包装成独立的微服务，要么得忍受旧技术的局限性，要么就得花大价钱和人力去升级技术栈，甚至重写。这笔账算下来，有时候觉得不划算。
缺乏自动化测试和部署的成熟体系： 在微服务化之前，很多公司可能并没有建立起一套完善的自动化测试和持续集成/持续部署（CI/CD）体系。强行推行微服务，如果测试跟不上，部署流程混乱，那会是灾难性的。每次改动一点小功能，都可能导致整个游戏服务器不稳定。
游戏服务器的特殊性：
游戏服务器和一般的互联网服务（比如电商、新闻资讯）在很多方面都有本质的区别，这些区别也让微服务化变得不那么直接。
对实时性和低延迟的极致追求： 游戏，尤其是动作类、竞技类游戏，对服务器的响应速度要求极高。每一次玩家的指令（比如移动、攻击）都需要服务器在毫秒级别内进行处理和反馈。如果将这些功能拆分成几十个甚至上百个微服务，每次玩家操作都可能需要跨越多个服务进行通信。每一次网络请求都会带来额外的延迟，服务的调用栈会变得非常深。即使每个服务本身的响应速度很快，但累积起来的通信开销就可能让游戏体验变得卡顿。
想象一下，你按了一下移动键，这个指令可能需要经过：玩家身份验证服务 > 位置更新服务 > 碰撞检测服务 > 战斗逻辑服务 > 渲染同步服务…… 如果这些服务之间是独立部署的，每次通信都需要网络I/O，这就会增加延迟。
高度集成的状态管理： 游戏世界的状态是高度动态和复杂的。玩家的血量、位置、技能冷却、背包里的道具、任务进度等等，这些信息需要被精确地同步给所有相关的玩家。在单体架构下，这些状态可能都集中在一个共享的内存空间或者数据库里，访问和更新起来非常方便且高效。
如果把这些拆分成微服务，你可能需要一个“玩家状态服务”、“物品服务”、“任务服务”。那么，当玩家使用了一个消耗品时，就需要同时调用“物品服务”来减少道具数量，同时调用“玩家状态服务”来更新玩家的属性。这中间就需要非常精密的协调和同步机制，否则很容易出现数据不一致的情况，比如你用掉了药水，但是药水并没有从背包里消失，或者你的血量没有恢复。
庞大的计算量和计算密集型任务： 很多游戏服务器需要处理大量的计算密集型任务，比如AI行为、物理模拟、大型多人场景下的渲染数据计算等。将这些任务拆分到不同的微服务，可能会带来服务间的通信开销、序列化/反序列化开销，以及额外的进程管理开销，这些都会占用CPU和内存资源，反而降低整体的计算效率。
比如一个大型团战场景，需要处理几十个玩家的技能释放、走位、碰撞、伤害计算，如果这些都在一个专门的“战斗计算服务”里处理，效率会很高。如果拆分成了几十个小服务，每次计算一个玩家的动作，都要和其他服务进行频繁的通信和状态同步，这个开销会非常大。
运维和管理成本：
微服务听起来很美好，因为它能让你更容易地独立部署和扩展单个服务。但实际上，微服务化会极大地增加运维的复杂性。
服务数量爆炸： 一个大型游戏服务器，可能原本只需要管理少数几个进程。微服务化后，可能需要管理几十个、上百个甚至上千个独立的服务实例。这意味着你需要一套非常强大的自动化运维、监控、日志管理、告警系统来支撑。
服务发现和注册： 各个微服务之间如何找到彼此？这就需要服务发现和注册中心。
分布式事务和数据一致性： 在分布式系统中，要保证多个服务之间的数据一致性是非常困难的。比如前面提到的消耗品例子，就需要处理分布式事务。如果其中一个服务失败了，整个操作怎么办？回滚？补偿？这需要复杂的设计和实现。
监控和追踪： 当一个请求穿过多个微服务时，你想知道问题出在哪里，就必须有强大的分布式追踪系统，能够帮你把一个请求在所有服务中的调用链路可视化出来。
版本管理和部署协调： 即使是独立部署，也要考虑服务之间的兼容性。一个服务的更新可能会影响到依赖它的其他服务。如何进行平滑升级、灰度发布，也是一个很大的挑战。
架构选择的平衡：
所以，很多游戏公司并不是完全不拥抱微服务，而是会根据实际情况，采取一种权衡和渐进的策略。
“大而可靠”的单体，内部模块化： 有些公司宁愿保持一个相对稳定、经过充分测试和优化的单体应用，但在单体内部做得非常模块化，遵循良好的设计原则。这样既能保证性能，也能相对容易地进行代码维护和功能开发。当某个模块确实瓶颈了，再考虑将其独立出来。
按功能划分服务，而不是按技术栈： 比如，可以把玩家的登录注册、好友系统、排行榜系统等相对独立、低延迟要求不那么高的功能，拆分成独立的微服务。而核心的战斗逻辑、物理模拟等高频、低延迟要求极高的部分，则会保持在一个高性能的单体服务里，甚至可能是在一个专门的进程池中进行管理。
“领域驱动设计”的理念： 在不完全走向微服务的情况下，可以在单体内部采用领域驱动设计（DDD）的理念，将代码按照业务领域进行划分，形成清晰的边界。这样即使不拆分成独立的微服务，也能提高代码的可维护性和可测试性，为未来可能的拆分打下基础。
容器化和资源隔离： 利用Docker等容器技术，可以将不同的功能模块打包成独立的容器运行。虽然逻辑上还是在一个大的应用里，但在资源使用、进程隔离、独立部署和升级方面，已经具备了类似微服务的灵活性，并且避免了跨进程通信带来的额外开销。
总结一下，游戏公司服务器不愿意“全盘微服务化”，主要原因在于：
1. 对实时性和低延迟的极端需求，微服务间的通信开销是巨大阻碍。
2. 游戏状态的复杂性和高度集成性，数据一致性管理难度极大。
3. 历史遗留技术和代码耦合，拆分成本高昂且风险大。
4. 巨大的运维和管理复杂度，需要成熟的配套体系支撑。
5. 计算密集型任务，微服务拆分可能导致效率反而下降。
这不是说微服务不好，而是对于游戏服务器这种对性能、稳定性和实时性有近乎严苛要求的系统来说，照搬互联网其他领域的微服务实践，可能会带来适得其反的效果。游戏公司更倾向于找到最适合自己游戏类型、规模和团队能力的架构平衡点。就像你不会用积木去搭一辆需要上高速的超跑一样，架构的选择总是要服务于业务的根本需求。
网友意见
原回答都是对对战系统的猜测，从来没写过游戏但应该八九不离十。
@放浪者 的回答里面有讲英雄联盟在线运维的链接感兴趣的同学可以去看，确实有运用微服务，不过里面并没有提到对战系统。
===================
比如moba类游戏，就看LOL的客户端吧，想象一下。
- 账号系统，符文系统，英雄系统，皮肤系统，好友系统，好友之间messaging，这些都是常规操作，如果流量足够大，当然可以用微服务的架构去做。
不过这不是这个游戏的核心，核心是MOBA：Multiplayer online battle arena。特性是什么？
- 10个人之间各种游戏事件的高速多向通讯 streaming/broadcast/multicast/pubsub各种通讯模式
所以游戏的核心在于小规模群体之间的高速网络通信。就是对方说的realtime。多了一个10ms的延迟玩家就要骂娘了。
- 微服务为了把业务完美拆解，把原来的同一个进程里的模块拆分成不同的服务，显著增加额外的网络开销。更别说什么service mesh，各种gateway，proxy，sidecar，简直就是担心延迟太低。
- 微服务基本只有request/response的模式。做不了streaming？微服务通常要求应用是无状态的才能做到水平扩展。streaming本身就是加入了状态
- 我可以想像，为了提高通讯的性能，一场英雄联盟游戏很可能会使用同一个服务器负责这10个玩家之间的通讯，这样就使得数据可以在本地交换，性能最大化。这对客户端或者说服务端统一网关的要求是必须支持sticky routing。假设客户端连接断了，接下来的必须重连之前的同一个服务器。微服务的stateless，水瓶扩展要求本身就是反sticky routing的，因为sticky routing本身就是状态。
- 对服务端集群来说，同时有无数个LOL比赛在进行，每个都可以看成一个沙盒，每个沙盒都处于一个不同的状态：塔被推了几个了，你被杀了几次了，对面几个超神了，20分钟到了没。 这些都是长时间存在的状态，直到游戏结束，服务端才可以清理一场游戏的状态。所以虽然不用把这些状态写进持久性存储，但是必然会在内存中存在很长时间。都是状态，反正有状态，就别想用微服务。除非你说把这些状态都移到redis里去，那么在服务器在信息流传输到一半还要做一个remote request，一来一回，延迟就上升了。总之怎样都不好。（比如想象对方在A你的水晶，每一次A的操作都是一个event，被streaming到服务端的沙盒中，沙盒中有一个流处理器，每次接收到一个你水晶被A的event都会计算一下你水晶爆了没。这个计算需要极快，你是不可能把你水晶生命值的数据存在远端的）
像这类游戏，都是对网络，内存，CPU的优化需求很高，整个游戏进行过程中，几乎不存在什么RPC call，真的需要remote data，也应该是prefetch，就是在游戏刚开始的时候加载好
微服务不是什么银弹，也就是方便拆解一下原来的CRUD应用罢了而已，一没触及高级的交互方式，二没触及分布式系统真正的难点：状态，其实没有大家想的那么有用。之所以感觉上好像微服务改变了互联网，只不过90%的互联网应用都只是简单小规模的CRUD而已。
对方没有听说过微服务完全没有问题，因为这本身就不是什么高深的概念，反而对方听你一说一下就知道微服务不适合游戏，说明对方理解能力很强，对游戏系统设计也了解足够深。
（虽然我没的确没写过游戏，以上仅供参考）
我大概说了，方便测试，方便维护，方便升级，服务之间松耦合，可多语言开发，自动扩容…之类的点
非常好，那么请问这些东西对于游戏服务器端来说有什么意义呢？
微服务是趋势，那你也要看它是为了解决什么问题，怎么成为趋势的哈……
下面有说低延迟的，而事实上低延迟并不是主要原因，微服务的服务调用延迟无论如何也是小于从服务器到玩家客户端之间的延迟的。虽然不能说完全忽略，但是这不成为主要原因。
而stateful和stateless才是主要原因，游戏是stateful的，而服务是stateless的。服务的特征本身就包含stateless。当然有人会说Storage Service、Cache Service不就是Stateful的吗？但实际上，说白了这些服务的服务本身是stateless的，只是后面带了一坨Storage，这和本身就是Stateful的Game Server完全不是一回事儿。说白了常见的什么MySQL、Redis，本质上是一个QueryService+Storage……
只有stateless，才能满足高可用、高吞吐、高伸缩性，这正是类Google的互联网应用所需要的。所以游戏为了stateful大都放弃了高可用、高吞吐、高伸缩性。要不设计这么多服，每个服里面搞这么多副本什么的干啥？
那么游戏服务器能不能和互联网应用一样做成Stateless Service+Storage的形式呢？
也不能，因为互联网应用这么做的原因是为了计算和存储分离。更充分的利用计算资源，获得更好的综合成本。互联网应用会尽量避免存取操作，因为存取的IO延迟比计算和网络的延迟高太多了。所以互联网应用会尽量只在少数StorageService进行存取操作，并且做很多缓存来改善存取延迟，就算为此放弃强一致性也在所不惜。
而游戏服务器则完全不能容忍跨服务的存取IO和同步延迟。试想想，别人砍你一刀你过了几秒钟才扣血，那就出大事了，因为在这期间你可能已经挨了七八刀了，一不小心别人就把你鞭尸了七八次。
而知乎，我改个答案能在一分钟内更新掉就算是中奖了……你自己体会下……
。。。有些国民级moba游戏的微服务化过程，可能有保密问题，我就不谈了。
拿中年人喜闻乐见的WOW来说，你们不知道有专门的排队服务器、场景服务器、副本服务器么这些么？你以为每次切换场景时的loading界面在做啥？就是完成service的切换啊。
你非要用web那一套来套在游戏上面，那当然不行，那说明你对microservice的理解太狭隘了。microservice重点是业务逻辑的拆分和独立，难道你以为这么多mmorpg，是一个巨大无比的monolithic的应用在跑？怎么可能。
多人游戏和互联网app相比，最大的差别不是microservice还是monolithic，也不是啥实时还是非实时，而是stateful和stateless的差别。互联网app大量的工作是在数据读写上，为了能疯狂scale，service本身一般是stateless的，最简单的一个例子就是web server的session概念（现在比较过时了，但是是个很好的例子），既可以本地，也可以存入redis或者db。游戏的server其实也是保存这样一个当前场景涵盖所有人的巨大session（比如副本，比如moba中的游戏全局状态）。由于游戏过程本身并没有什么保存价值，所以对这些实时进行的游戏状态进行持久化没啥意义，因此才有专门的对战服务器等等。
其实你把什么对战服务器、排队服务器、匹配服务器等等都叫做xx service，就会发现其实就是微服务概念。
补充一点个人不保证正确的私货：其实整个游戏开发行业和互联网行业的技术思维差异就在于stateful vs stateless，做习惯了游戏开发的人（无论客户端还是backend），习惯了直接在内存读写数据，不习惯从远程读写（无论是redis还是db或者nosql或者啥），换句话说他们不太习惯原始数据不在本地机器上，而恰恰业务逻辑和数据分离是互联网架构的重要指导思想。这使得游戏开发程序员的技术思维很有些不一样，我不能说不好，但是确实有点技能点的配置不同的感觉，这当实现非游戏项目的时候是有障碍的。
*********************************************
评论中的朋友是一个较为典型的例子，始终固守在传统（国内）对游戏单体开发的思路上，你当然可以这么做，但是不意味着就必须这么做，更不意味着这么做就是好的。
一开始我说的国民级游戏之一就是LOL，搜了一下公开资料，，发现他们也略微谈过一点他们后台微服务化的事情 ，有兴趣的可以看看。
不过他们也是比较含糊其辞的，没谈具体功能模块划分，只含糊举了些抽象例子。所以为了避免有些问题，我也就不提了。
微服务本身就是个模块化的概念，国内喜欢眉毛胡子一把抓强调单机性能单机并发（实质是发懒），而要把单体应用的各种模块分拆出来，问题主要是团队管理、服务治理、开发协调、部署、功能边界和定义这些微服务本身的坑。至于很多人说的性能、响应速度等等，这些都是拆分时要考虑的因素之一罢了，并不是啥模块都要纠结这些的。
类似的话题
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2025 tinynews.org All Rights Reserved. 百科问答小站 版权所有