B体育官方为什么游戏公司不使用微服务架构？

　　然后他说游戏 server 不太需要微服务，因为要求 real time，做微服务会影响效能，分模组来开发就好了

　　账号系统，符文系统，英雄系统，皮肤系统，好友系统，好友之间 messaging，这些都是常规操作，如果流量足够大，当然可以用微服务的架构去做。

　　所以游戏的核心在于小规模群体之间的高速网络通信 。就是对方说的 realtime。多了一个 10ms 的延迟玩家就要骂娘了。

　　微服务为了把业务完美拆解，把原来的同一个进程里的模块拆分成不同的服务，显著增加额外的网络开销 。更别说什么 service mesh，各种 gateway，proxy，sidecar，简直就是担心延迟太低。

　　微服务基本只有 request/response 的模式。做不了 streaming？微服务通常要求应用是无状态的才能做到水平扩展。streaming 本身就是加入了状态

　　我可以想像，为了提高通讯的性能，一场英雄联盟游戏很可能会使用同一个服务器负责这 10 个玩家之间的通讯，这样就使得数据可以在本地交换，性能最大化 。这对客户端或者说服务端统一网关的要求是必须支持 sticky routing。假设客户端连接断了，接下来的必须重连之前的同一个服务器。微服务的 stateless，水瓶扩展要求本身就是反 sticky routing 的，因为 sticky routing 本身就是状态。

　　对服务端集群来说，同时有无数个王者荣耀的比赛在进行，每个都可以看成一个沙盒，每个沙盒都处于一个不同的状态：塔被推了几个了，你被杀了几次了，对面几个超神了，20 分钟到了没。这些都是长时间存在的状态，直到游戏结束，服务端才可以清理一场游戏的状态。

　　所以虽然不用把这些状态写进持久性存储，但是必然会在内存中存在很长时间。都是状态，反正有状态，就别想用微服务。除非你说把这些状态都移到 redis 里去，那么在服务器在信息流传输到一半还要做一个 remote request，一来一回，延迟就上升了。总之怎样都不好。（比如想象对方在 A 你的水晶，每一次 A 的操作都是一个 event，被 streaming 到服务端的沙盒中，沙盒中有一个流处理器，每次接收到一个你水晶被 A 的 event 都会计算一下你水晶爆了没。这个计算需要极快，你是不可能把你水晶生命值的数据存在远端的）

　　像这类游戏，都是对网络，内存，CPU 的优化需求很高，整个游戏进行过程中，几乎不存在什么 RPC call，真的需要 remote data，也应该是 prefetch，就是在游戏刚开始的时候加载好

　　微服务不是什么银弹，也就是方便拆解一下原来的 CRUD 应用罢了而已，一没触及高级的交互方式，二没触及分布式系统真正的难点：状态，其实没有大家想的那么有用。之所以感觉上好像微服务改变了互联网，只不过 90%的互联网应用都只是简单小规模的 CRUD 而已。

　　对方没有听说过微服务完全没有问题，因为这本身就不是什么高深的概念，反而对方听你一说一下就知道微服务不适合游戏，说明对方理解能力很强，对游戏系统设计也了解足够深。

　　看来是是最近被 微服务了， 个人感觉正常微服务，一个服务必须有 3 个以上工程师单独维护，才真真把微服务盘起来。

　　而且微服务现在最多就是 HTTP 这种协议跑，很占性能的，就算是走 TCP HTTP2 远远不如单体性能，尤其是微服务做业务分叉调用的时候怎么划分，数据事件一致性 是非常头痛的一件事。

　　微服务用的广是 WEB 方面 而且工程师多，业务变来变多，而且它几乎是自己玩自己的。这种场景就非常适合。实时性不需要那么高那种

　　我知道很多人，把微服务魔化了，别人要 100 层功力，而你只学到了 1 层。然后就硬搬上来跟别人说这很

　　我看过那么多博客，技术文，唯独就微软官方那一篇 微服务技术写的最好，明确的告诉你这种架构适合什么样的场景跟团队，什么样的场景不要用，而不是一些文章无脑吹

　　为啥有这种感触，因为我是受害人。所以奉劝各位 什么样的团队项目底子业务 就选择最合适自己的架构，不要盲目去跟风，更不要盲目的去对比大厂云云云，你的业务跟团队是别人的零头都不够。别人的 HR 团队可能都比你技术团队人数多。

　　架构分的越单元化，那么需要的人数是翻倍起来维护的，不然你就会发现为什么这个架构我用起来这么啰嗦。不是别人的架构不够好，是你的团队还不需要

　　...游戏服务器都是几乎都是带大量状态的，我就问你一个致命问题，游戏里面本来在同个进程内，内存直接可以访问到，走微服务就可能这个服务不在本机设备上面，那就需要走网络传输过去，那么你考虑过延迟问题吗？有考虑过如果连接挂掉？

　　每个微服务跨本机都是一个 RPC 调用，这东西是不可靠的，如果你要可靠行啊，你准备约定一个接口调用多少毫秒超时重传？200/500?(这就存在两个情况：对面已经处理，对面没有处理，但实际上是同一个调用请求）

　　固然，我们可以使用协程，C++也可以，那么编码复杂度有考虑过吗？而且大量的异步编程在游戏服务器上面是很困难的，也就意味着需要更多的游戏服务器开发人员，而且还得要求开发人员的综合素质不能太差。

　　公众号“Java精选”所发表内容注明来源的，版权归原出处所有（无法查证版权的或者未注明出处的均来自网络，系转载，转载的目的在于传递更多信息，版权属于原作者。如有侵权，请联系，笔者会第一时间删除处理！

　　最近有很多人问，有没有读者交流群！加入方式很简单，公众号Java精选，回复“加群”，即可入群！