知乎高赞:为什么像王者荣耀这样的游戏Server不愿意使用微服务?

知乎高赞:为什么像王者荣耀这样的游戏Server不愿意使用微服务?

今天,在知乎上看到这样一个问题:"为什么游戏公司的server不愿意微服务化?"

# 背景介绍

笔者最近去面试了家游戏公司。

最近面试了一家游戏公司(满大间的,有上市)

我问他,公司有没有做微服务架构的打算及考量?

他很惊讶的说,我没听说过微服务耶,你可以解释一下吗?

我大概说了,方便测试,方便维护,方便升级,服务之间松耦合,可多语言开发,自动扩容…之类的点。

然后他说游戏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(或者允许注入)等等。

来源:zhihu.com/question/359630395/answer/954452799

———-  END  ———-

重磅!后厂技术官-技术交流群已成立

扫码可添加后厂技术官助手, 可申请加入后厂技术官大群和细分方向群,细分方向已涵盖: Java、Python、机器学习、大数据、人工智能 等群。

一定要备注: 开发方向+地点+学校/公司+昵称 (如Java开发+北京+快手+阿信) ,根据格式备注,可更快被通过且邀请进群

知乎高赞:为什么像王者荣耀这样的游戏Server不愿意使用微服务?

▲长按加群

推荐阅读

•  再见,我的前公司 人人网!

•  美团外卖Flutter动态化实践

•   刚刚!美国官宣117000名 IT 人失业,真是史无前例!

•   真香!红色警戒游戏源代码开源了!

•   当初我要是这么学习操作系统就好了(附带思维导图)

推荐一个技术号

Github实验室, 由国内一线大厂专家、985博士、硕士组成的团体运营。 主要分享和研究业界实用、有趣的开源项目,学习资源,开发工具,学术交流。

关注就无套路送你一份5000页Java面试最强合集PDF。

知乎高赞:为什么像王者荣耀这样的游戏Server不愿意使用微服务?

长按二维码识别关注

最近面试BAT,整理一份面试资料 大厂Java面试通关指北 ,覆盖了Java核心技术、JVM、Java并发、SSM、微服务、数据库、数据结构等等。

获取方式:点“ 在看 ”,关注公众号并回复  BAT  领取,更多内容陆续奉上。

如有收获,点个在看,诚挚感谢 明天见(。・ω・。)ノ♡

原文 

http://mp.weixin.qq.com/s?__biz=MzAxMTg2MjA2OA==&mid=2649852789&idx=3&sn=146eeabe813b838ad7453d453a4b050f

本站部分文章源于互联网,本着传播知识、有益学习和研究的目的进行的转载,为网友免费提供。如有著作权人或出版方提出异议,本站将立即删除。如果您对文章转载有任何疑问请告之我们,以便我们及时纠正。

PS:推荐一个微信公众号: askHarries 或者qq群:474807195,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

转载请注明原文出处:Harries Blog™ » 知乎高赞:为什么像王者荣耀这样的游戏Server不愿意使用微服务?

赞 (0)
分享到:更多 ()

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址