王者荣耀为什么不使用微服务架构?
共 4219字,需浏览 9分钟
·
2020-09-10 20:45
微服务为了把业务完美拆解,把原来的同一个进程里的模块拆分成不同的服务,显著增加额外的网络开销。更别说什么Service Mesh,各种Gateway,Proxy,Sidecar简直就是担心延迟太低。
微服务基本只有request/response的模式。做不了streaming?微服务通常要求应用是无状态的才能做到水平扩展。streaming本身就是加入了状态。
我可以想像,为了提高通讯的性能,一场英雄联盟游戏很可能会使用同一个服务器负责这10个玩家之间的通讯,这样就使得数据可以在本地交换,性能最大化。这对客户端或者说服务端统一网关的要求是必须支持sticky routing。假设客户端连接断了,接下来的必须重连之前的同一个服务器。微服务的stateless,水瓶扩展要求本身就是反sticky routing的,因为sticky routing本身就是状态。
对服务端集群来说,同时有无数个王者荣耀的比赛在进行,每个都可以看成一个沙盒,每个沙盒都处于一个不同的状态:塔被推了几个了,你被杀了几次了,对面几个超神了,20分钟到了没。
微服务本身是为了应对业务逻辑的复杂,需要要的新的组织接口的方式。游戏本身逻辑其实没有这么复杂,比如大厅就是一些基本功能,修改帐号,登录等。游戏本身就是游戏本身的逻辑。
游戏逻辑服务器本身(比如斗地主等棋牌)因为网络响应性能要求问题(玩家对每个操作的反馈时长敏感度远高于业务系统),所以游戏服务器都是有状态的,状态就存在内存,偶尔会接受Redis,MySQL等是绝对不可以的接受的,关系行数据库仅用来定时异步持久化数据,仅游戏服务器而言持久化在Redis即可。
游戏服务器一般纯需要主动推送,所以第一代微服务网关就没办法满足需求, TCP的没有网关用,Spring Cloud Gateway的Web socket也许可以用(但是从防攻击角度讲端游用TCP绝对比Web socket合理)。
服务间通信RPC首先Ribbon,Feign等并不是合适,因为都是基于http的,用http存在一个消息乱序问题,比如玩家出牌两次,在http就可能出现次序不一致。游戏服务器集群一般使用长连接互联。可能需要用Dubbo?(听说是长连接)
游戏逻辑服务器(比如斗地主服务器),一般是不能用Spring MVC做的,因为线程模型完全不同。多线程模型处理游戏性能差还非常复杂,一般都是使用单进程/线程 驱动固定数量房间的方式(这也是为何服务器一定有状态,一定不能直接读写MySQL)。一般就直接Netty了。
自动扩容在游戏这边叫做开服,早就有固定流程和工具和限流方式了。
游戏很多操作不存在服务降级熔断,不行就要直接报错给用户。
大厅服务器登录注册等的确可以做微服务,但是其实也不是做微服务,就是几个接口有自动水平扩容的方案即可。服务注册发现用处不大,开服都是确定的事情,还有一系列运营手段配合,关服也是绝对不能随便关的。
游戏处理的流量真的不算多,你在线1万的棋牌游戏已经很赚钱了,10W就是个特别厉害的产品了。
一些独立的服务器比如充值之类的需要微服务化么?只能说这种服务器都需要微服务处理了,项目组做梦都能笑醒。
。。。有些国民级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,搜了一下公开资料,,发现他们也略微谈过一点他们后台微服务化的事情
不过他们也是比较含糊其辞的,没谈具体功能模块划分,只含糊举了些抽象例子。所以为了避免有些问题,我也就不提了。
微服务本身就是个模块化的概念,国内喜欢眉毛胡子一把抓强调单机性能单机并发(实质是发懒),而要把单体应用的各种模块分拆出来,问题主要是团队管理、服务治理、开发协调、部署、功能边界和定义这些微服务本身的坑。至于很多人说的性能、响应速度等等,这些都是拆分时要考虑的因素之一罢了,并不是啥模块都要纠结这些的。
对此你怎么看?
推荐阅读
站长 polarisxu
自己的原创文章
不限于 Go 技术
职场和创业经验
Go语言中文网
每天为你
分享 Go 知识
Go爱好者值得关注