王者荣耀:游戏server的服务应该很容易拆分吗?

91百科网 16 0

笔者最近去采访了一家游戏公司。

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

我问他,公司对于微服务架构有什么规划和考虑吗?

他很惊讶,说,我从来没有听说过微服务。 你能解释一下吗?

我大致说的是方便测试、方便维护、方便升级、服务之间松耦合、多语言开发、自动扩展……等等。

然后他说游戏服务器不需要微服务,因为它需要实时性。 做微服务会影响性能。 它可以以模块的形式进行开发。

我也不确定,但是微服务不是一种趋势吗? 尤其是对于大公司来说,游戏服务器服务应该很容易拆分吧?

回答

我整理了一些好的答案并想与大家分享。 只能说学会了,手法一定要用在对的场景!

陈宏基的回答

比如moba游戏/王者荣耀/LOL,只要看王者荣耀的客户端就可以想象了。

账号系统、符文系统、英雄系统、皮肤系统、好友系统、好友之间的消息传递都是常规操作。 如果流量足够大,当然可以使用微服务架构来完成。

但这不是这个游戏的核心。 核心是MOBA:多人在线竞技场。 有什么特点?

顺便说一句,如果你近期准备面试跳槽,建议到ddkk.com在线答题,涵盖10000+Java面试题,涵盖几乎所有主流技术面试题,最全面的500道面试题市场上有成套技术栈,都是优质产品。 一系列教程,免费提供。

10人之间各种游戏赛事高速多方位通讯流/广播/组播/pubsub多种通讯方式

所以游戏的核心是小群体之间的高速网络通信。 就是对方所说的实时。 如果多出10ms的延迟,玩家就会骂人。

1、微服务为了完美拆解业务,将同一进程中的原有模块拆分为不同的服务,这显着增加了额外的网络开销,更不用说servicemesh、各种网关、代理、sidecar了。 这简直令人担忧。 延迟太低;

2. 微服务基本上只有请求/响应模型,不能做流式传输? 微服务通常要求应用程序是无状态的,以实现水平扩展。 流本身会添加状态;

3.我可以想象,一款英雄联盟游戏为了提高通信性能,很可能会使用同一个服务器来负责这10个玩家之间的通信,这样就可以在本地交换数据,并提高这对客户端的性能可以最大化。 也就是说,服务器端统一网关的要求是必须支持粘性路由。 如果客户端连接断开,则必须重新连接同一服务器的无状态微服务。 水瓶扩展需求本身就是反粘性路由,因为粘性路由本身就是状态;

4、对于服务器集群来说,有无数王者荣耀游戏同时进行。 每一个都可以看作是一个沙箱。 每个沙箱都处于不同的状态:有多少塔被推了? 我已经被杀过好几次了,而且有些对手超级强大。 20分钟后,这些都是长期状态。 直到游戏结束,服务器才能清除游戏状态;

所以虽然这些状态不需要写入持久化存储,但它们肯定会长期存在于内存中。 这都是状态。 如果无论如何你都有状态,就不要考虑使用微服务。 除非你想将所有这些状态移至redis,否则服务器将不得不在信息流传输的过程中发出远程请求。 每次回来,延迟都会增加。 无论如何,都不好。 (举个例子,假设对方是A你的水晶,A的每一次操作都是一个事件,流式传输到服务器上的沙箱,沙箱里有一个流处理器,每次接收到你的水晶的事件是A,它会计算你的水晶是否爆炸。这个计算需要非常快,你不可能远程存储你的水晶的生命值数据。)

。 插播一下,如果你近期准备面试跳槽,建议在ddkk.com在线答题,涵盖10000+条Java面试题,涵盖几乎所有主流技术面试题,500套最市场上完整的技术堆栈。 优秀的系列教程,免费提供。

这类游戏对网络、内存、CPU的优化要求很高。 整个游戏过程中,几乎没有RPC调用。 确实需要远程数据,应该预取,也就是游戏刚开始的时候。 已加载

微服务不是灵丹妙药。 它们只是为了拆解原有的CRUD应用提供方便。 它们没有触及高级的交互方法和分布式系统的真正难点:状态。 事实上,它们并不像大家想象的那么有用。 之所以感觉微服务改变了互联网,是因为90%的互联网应用都只是简单的、小规模的CRUD。

如果对方没有听说过微服务也没有问题,因为这本身并不是一个高深的概念。 相反,对方听了你的解释就会知道微服务不适合做游戏。 这说明对方对游戏系统设计有很强的理解力和足够的认识。 深的。

匿名用户的回答

看来我最近被微服务洗脑了。 我个人感觉,对于正常的微服务来说,一个服务必须由3个以上的工程师单独维护,才能真正把微服务组织起来。

而且,现在大多数微服务都运行在HTTP协议上,这对性能的占用很大。 即使使用TCP HTTP2,性能也远远不如单个实体。 尤其是业务fork调用时如何划分微服务,以及数据事件的一致性是非常头疼的。 一件事。

微服务在WEB领域应用广泛,工程师也很多。 业务越来越大,几乎发挥了自己的作用。 这个场景很适合。实时性不需要那么高

我知道很多人妖魔化了微服务。 别人要求100级的技能,你只学了1级,然后他就提出来,告诉别人,这太棒了。

我读了那么多博客和技术文章,但微软官方关于微服务技术的文章是最好的。 它清楚地告诉你这个架构适合什么样的场景和团队,什么样的场景不应该使用。 而不是有些文章都是废话

脱离业务的技术架构是为了框架而构建架构,这只是搬起石头砸自己的脚。

对于开发者来说,强烈建议自己研究新技术。 但如果不考虑实际情况,那就是疯了。

顺便说一句,如果你近期准备面试跳槽,建议到ddkk.com在线答题,涵盖10000+Java面试题,涵盖几乎所有主流技术面试题,最全面的500道面试题市场上有成套技术栈,都是优质产品。 一系列教程,免费提供。

为什么我有这样的感觉? 因为我是受害者。 因此,我建议您无论您的团队项目的基本业务是什么,都选择最适合您的结构。 不要盲目跟风,更不要盲目与大公司比较。 您的企业和团队仅仅只是其他企业和团队的一小部分是不够的。 别人的HR团队可能比你的技术团队人数还多。

架构越统一,维护它的人就越多。 不然你就会发现为什么这个架构我用起来这么麻烦。不是别人的架构不够好,而是你的团队还不需要。

莉莉尔特的回答

...游戏服务器几乎总是有很多状态。 让我问你一个致命的问题。 游戏原本是在同一个进程中,可以直接访问内存。 如果您使用微服务,该服务可能不在本地设备上。 ,那么就需要通过网络进行传输。 你考虑过延迟问题吗? 您是否考虑过如果连接中断会发生什么?

每个微服务都是跨本地计算机的 RPC 调用。 这东西不靠谱。 如果您希望它可靠,您是否会同意超时并重新传输接口调用的毫秒数? 200/500? (有两种情况:对方已处理和对方未处理,但实际上是同一个呼叫请求)

如果玩家只是放一个技能,需要投射状态,那么由于断线重传需要数百毫秒才能响应,玩家体验如何。

当然我们可以使用协程,也可以使用C++,但是你考虑过编码的复杂度吗? 而且大量的异步编程在游戏服务器上是非常困难的,这意味着需要更多的游戏服务器开发人员,并且开发人员的整体素质不能太差。

标签: 架构 面试 服务 延迟 王者

发表评论 (已有0条评论)

还木有评论哦,快来抢沙发吧~