为啥王者荣耀为什么不利用微办事架构？

比来，在知乎上看到如许一个问题：

"为什么游戏公司的server不情愿微办事化？"

布景介绍

比来面试了一家游戏公司（满大间的，有上市）

我问他，公司有没有做微办事架构的诡计及考量？

他很骇怪的说，我没传闻过微办事耶，你能够阐明一下吗？

我可能说了，便利测试，便利庇护，便利晋级，办事之间松耦合，可多语言开发，主动扩容…之类的点。

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

我也不确定，但微办事不是趋向吗？特殊是大公司，游戏server的办事应该很随便拆分吧？。

[hongjic93] 是如许答复的：

好比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罢了。

对方没有传闻过微办事完全没有问题，因为那自己就不是什么深邃的概念，反而对方听你一说一下就晓得微办事不合适游戏，阐明对方理解才能很强，对游戏系统设想也领会足够深。

（固然我没确实没写过游戏，以上仅供参考）

展开全文

[放浪者] 是如许答复的：

……有些国民级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或者啥），换句话说他们不太习惯原始数据不在当地机器上，而恰好营业逻辑和数据别离是互联网架构的重要批示思惟。那使得游戏开发法式员的手艺思维很有些纷歧样，我不克不及说欠好，但是确实有点技能点的设置装备摆设差别的觉得，那当实现非游戏项目标时候是有障碍的。

[brice] 是如许答复的：

做过棋牌游戏（游戏最简单的一种），能够测验考试说几个点：

1、微办事自己是为了应对营业逻辑的复杂，需要要的新的组织接口的体例。游戏自己逻辑其实没有那么复杂，好比大厅就是一些根本功用，修改帐号，登录等。游戏自己就是游戏自己的逻辑。

2、游戏逻辑办事器自己（好比斗田主等棋牌）因为收集响应性能要求问题（玩家对每个操做的反应时长灵敏度远高于营业系统），所以游戏办事器都是有形态的，形态就存在内存，偶尔会承受redis，mysql等是绝对不成以的承受的，关系行数据库仅用来按时异步耐久化数据，仅游戏办事器而言耐久化在redis即可。

3、游戏办事器一般纯需要主动推送，所以第一代微办事网关就没办法称心需求， tcp的没有网关用，spring cloud gateway的web socket也答应以用（但是从防进攻角度讲端游用TCP绝比照web socket合理）。

4、办事间通信rpc起首ribbon,feign等并非适宜，因为都是基于?(传闻是长毗连)

5、游戏逻辑办事器（好比斗田主办事器），一般是不克不及用spring mvc做的，因为线程模子完全差别。多线程模子处置游戏性能差还十分复杂，一般都是利用单历程/线程 驱动固定命量房间的体例（那也是为何办事器必然有形态，必然不克不及间接读写mysql）。一般就间接netty了

6、主动扩容在游戏那边喊做开服，早就有固定流程和东西和限流体例了

7、游戏良多操做不存在办事降级熔断，不可就要间接报错给用户。

8、大厅办事器登录注册等确实能够做微办事，但是其实也不是做微办事，就是几个接口有主动程度扩容的计划即可。办事注册发现用途不大，开服都是确定的工作，还有一系列运营手段共同，关服也是绝对不克不及随意关的。

9、游戏处置的流量实的不算多，你在线1万的棋牌游戏已经很赚钱了，10W就是个特殊凶猛的产物了。

10、一些独立的办事器好比充值之类的需要微办事化么?只能说那种办事器都需要微办事处置了，项目组做梦都能笑醒。

固然上面说了良多点，但是其实也是能够考虑用spring cloud革新的，因为游戏集群一样有注册中心，需要办事发现，需要编排启动挨次，只是spring cloud没有为了游戏设想罢了，好比至少要完全撑持 webflux吧，需要一个单线程的长毗连更好撑持protobuf rpc框架吧（集成办事发现相关功用与接口），网关撑持tcp或者至少封拆或者表露一些netty的decoder encoder（或者容许注进）等等。

各人关于"为什么游戏公司的server不情愿微办事化？"那一问题，有如何的根究和设法呢？欢送在留言区交换~

整理丨鄙人陈某（ID：oneswholife）

来源丨网址：zhihu.com/question/359630395/answer/954452799

dbaplus社群欢送广阔手艺人员投稿，投稿邮箱：editor@dbaplus.cn

关于我们

dbaplus社群是围绕Database、BigData、AIOps的企业级专业社群。资深大咖、手艺干货，天天精品原创文章推送，每周线上手艺分享，每月线下手艺沙龙，每季度GdevopsDAMS行业大会。

存眷公家号【dbaplus社群】，获取更多原创手艺文章和精选东西下载