转自:知乎

https://www.zhihu.com/question/359630395/answer/954452799

背景介绍

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

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

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

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

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

然后他说游戏 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 而已。

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

陈宏基的回答:

https://www.zhihu.com/question/359630395/answer/954452799

一位匿名用户的回答

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

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

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

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

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

脱离业务的技术架构,就是为了框架而架构,就是没事给自己搬石头砸脚跟

对于开发者来说,自己去研究研究新技术是值的非常推崇的。但是不考虑实际情况,那就是魔怔了。

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

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

有小伙伴想找微软的微服务架构链接 我放一下:

https://learn.microsoft.com/zh-cn/dotnet/architecture/microservices/multi-container-microservice-net-applications/microservice-application-design

liulilte 的回答

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

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

如果玩家只是放一个技能,需要投射状态呢,因为断开重传等几百毫秒响应,那么玩家体验是啥。

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

推荐阅读  点击标题可跳转

1、Fish Shell采用Rust重写会导致性能下降

2、Linux网络应用开发—进程通信IPC汇总

3、被罚 11 万元!跳槽员工忘关屏幕共享,向 Nvidia 展示窃取源码,遭前东家当场抓获

作者 admin

发表回复