今天在知乎上看到这样一个问题："为何游戏公司的server不肯意微服务化？"mysql
背景介绍：web
笔者最近去面试了家游戏公司。面试
最近面试了一家游戏公司（满大间的，有上市）redis
我问他，公司有没有作微服务架构的打算及考量？spring
他很惊讶的说，我没据说过微服务耶，你能够解释一下吗？sql
我大概说了，方便测试，方便维护，方便升级，服务之间松耦合，可多语言开发，自动扩容…之类的点数据库
而后他说游戏server不太须要微服务，由于要求real time，作微服务会影响效能，分模组来开发就行了服务器
我也不肯定，但微服务不是趋势吗？特别是大公司，游戏server的服务应该很容易拆分吧？微信
hongjic93 是这样回答的：网络
好比moba类游戏/王者荣耀/LOL，就看王者荣耀的客户端吧，想象一下。
帐号系统，符文系统，英雄系统，皮肤系统，好友系统，好友之间messaging，这些都是常规操做，若是流量足够大，固然能够用微服务的架构去作。
不过这不是这个游戏的核心，核心是MOBA：Multiplayer online battle arena。特性是什么？
10我的之间各类游戏事件的高速多向通信 streaming/broadcast/multicast/pubsub各类通信模式 因此游戏的核心在于小规模群体之间的高速网络通讯。就是对方说的realtime。多了一个10ms的延迟玩家就要骂娘了。
1.微服务为了把业务完美拆解，把原来的同一个进程里的模块拆分红不一样的服务，显著增长额外的网络开销。更别说什么service mesh，各类gateway，proxy，sidecar，简直就是担忧延迟过低。
2.微服务基本只有request/response的模式。作不了streaming？微服务一般要求应用是无状态的才能作到水平扩展。streaming自己就是加入了状态
3.我能够想像，为了提升通信的性能，一场英雄联盟游戏极可能会使用同一个服务器负责这10个玩家之间的通信，这样就使得数据能够在本地交换，性能最大化。这对客户端或者说服务端统一网关的要求是必须支持sticky routing。假设客户端链接断了，接下来的必须重连以前的同一个服务器。微服务的stateless，水瓶扩展要求自己就是反sticky routing的，由于sticky routing自己就是状态。
4.对服务端集群来讲，同时有无数个王者荣耀的比赛在进行，每一个均可以当作一个沙盒，每一个沙盒都处于一个不一样的状态：塔被推了几个了，你被杀了几回了，对面几个超神了，20分钟到了没。这些都是长时间存在的状态，直到游戏结束，服务端才能够清理一场游戏的状态。因此虽然不用把这些状态写进持久性存储，可是必然会在内存中存在很长时间。都是状态，反正有状态，就别想用微服务。除非你说把这些状态都移到redis里去，那么在服务器在信息流传输到一半还要作一个remote request，一来一回，延迟就上升了。总之怎样都很差。（好比想象对方在A你的水晶，每一次A的操做都是一个event，被streaming到服务端的沙盒中，沙盒中有一个流处理器，每次接收到一个你水晶被A的event都会计算一下你水晶爆了没。这个计算须要极快，你是不可能把你水晶生命值的数据存在远端的） 像这类游戏，都是对网络，内存，CPU的优化需求很高，整个游戏进行过程当中，几乎不存在什么RPC call，真的须要remote data，也应该是prefetch，就是在游戏刚开始的时候加载好
微服务不是什么银弹，也就是方便拆解一下原来的CRUD应用罢了而已，一没触及高级的交互方式，二没触及分布式系统真正的难点：状态，其实没有你们想的那么有用。之因此感受上好像微服务改变了互联网，只不过90%的互联网应用都只是简单小规模的CRUD而已。
对方没有据说过微服务彻底没有问题，由于这自己就不是什么高深的概念，反而对方听你一说一下就知道微服务不适合游戏，说明对方理解能力很强，对游戏系统设计也了解足够深。
brice是这样回答到：
作过棋牌游戏（游戏最简单的一种），能够尝试说几个点：
1.微服务自己是为了应对业务逻辑的复杂，须要要的新的组织接口的方式。游戏自己逻辑其实没有这么复杂，好比大厅就是一些基本功能，修改账号，登陆等。游戏自己就是游戏自己的逻辑。
2.游戏逻辑服务器自己（好比斗地主等棋牌）由于网络响应性能要求问题（玩家对每一个操做的反馈时长敏感度远高于业务系统），因此游戏服务器都是有状态的，状态就存在内存，偶尔会接受redis，mysql等是绝对不能够的接受的，关系行数据库仅用来定时异步持久化数据，仅游戏服务器而言持久化在redis便可。
3.游戏服务器通常纯须要主动推送，因此第一代微服务网关就没办法知足需求， tcp的没有网关用，spring cloud gateway的web socket也许能够用（可是从防攻击角度讲端游用TCP绝对比web socket合理）。
4.服务间通讯rpc首先ribbon,feign等并非合适，由于都是基于http的，用Http存在一个消息乱序问题，好比玩家出牌两次，在http就可能出现次序不一致。游戏服务器集群通常使用长链接互联。可能须要用dubbo?(据说是长链接)
5.游戏逻辑服务器（好比斗地主服务器），通常是不能用spring mvc作的，由于线程模型彻底不一样。多线程模型处理游戏性能差还很是复杂，通常都是使用单进程/线程 驱动固定数量房间的方式（这也是为什么服务器必定有状态，必定不能直接读写mysql）。通常就直接netty了
6.自动扩容在游戏这边叫作开服，早就有固定流程和工具和限流方式了
7.游戏不少操做不存在服务降级熔断，不行就要直接报错给用户。
8.大厅服务器登陆注册等的确能够作微服务，可是其实也不是作微服务，就是几个接口有自动水平扩容的方案便可。服务注册发现用处不大，开服都是肯定的事情，还有一系列运营手段配合，关服也是绝对不能随便关的。
9.游戏处理的流量真的不算多，你在线1万的棋牌游戏已经很赚钱了，10W就是个特别厉害的产品了。
10.一些独立的服务器好比充值之类的须要微服务化么?只能说这种服务器都须要微服务处理了，项目组作梦都能笑醒。
虽然上面说了不少点，可是其实也是能够考虑用spring cloud改造的，由于游戏集群同样有注册中心，须要服务发现，须要编排启动顺序，只是spring cloud没有为了游戏设计而已，好比至少要彻底支持 webflux吧（没有仔细研究），须要一个单线程的长链接最好支持protobuf rpc框架吧（集成服务发现相关功能与接口），网关支持tcp或者至少封装或者暴露一些netty的decoder encoder（或者容许注入）等等
内容来源：知乎众网友，整理自：Java版web项目 zhihu.com/question/359630395/answer/954452799 
欢迎关注个人微信公众号「码农突围」，分享Python、Java、大数据、机器学习、人工智能等技术，关注码农技术提高•职场突围•思惟跃迁，20万+码农成长充电第一站，陪有梦想的你一块儿成长