王者荣耀为什么不使用微服务架构?

Go语言精选

共 4219字,需浏览 9分钟

 ·

2020-09-10 20:45

点击上方蓝色“Go语言中文网”关注我们,领全套Go资料,每天学习 Go 语言


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


背景介绍


笔者最近去面试了家游戏公司(有上市)。我问他,公司有没有做微服务架构的打算及考量?他很惊讶的,我没听说过微服务耶,你可以解释一下吗?

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

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

我也不确定,但微服务不是趋势吗?特别是大公司,游戏server的服务应该很容易拆分吧?


陈宏基是这样回答的


比如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(或者允许注入)等等。

放浪者这样回答到

。。。有些国民级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,搜了一下公开资料,,发现他们也略微谈过一点他们后台微服务化的事情


不过他们也是比较含糊其辞的,没谈具体功能模块划分,只含糊举了些抽象例子。所以为了避免有些问题,我也就不提了。


微服务本身就是个模块化的概念,国内喜欢眉毛胡子一把抓强调单机性能单机并发(实质是发懒),而要把单体应用的各种模块分拆出来,问题主要是团队管理、服务治理、开发协调、部署、功能边界和定义这些微服务本身的坑。至于很多人说的性能、响应速度等等,这些都是拆分时要考虑的因素之一罢了,并不是啥模块都要纠结这些的。


原文链接:https://www.zhihu.com/question/359630395


对此你怎么看?



推荐阅读


学习交流 Go 语言,扫码回复「进群」即可


站长 polarisxu

自己的原创文章

不限于 Go 技术

职场和创业经验


Go语言中文网

每天为你

分享 Go 知识

Go爱好者值得关注



浏览 15
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报