realtek audio console无法连接rpc服务_RPC服务在游戏中的简单运用

作者:二周目赤

出处:https://www.cnblogs.com/cr1719/p/13866841.html

我们最开始做的游戏框架,多数都是client—>server—>db的模式,但是随着玩家数量的增加,一个server进程就会扛不住,需要多个进程服务于多个玩家。但是给定了不同进程的玩家,有可能需要交互,这就导致了client与server端的连接,有可能是o(1),但也可能是o(n)连接,o(n)的扩展性非常差,不容易维护,因此可以剔除了。但是如果只保持o(1),那必然要引入新的抽象服务,网关也就登场了。下图是一个简单的网关部署架构:

9c0815d3073ad6c9038e57f662fc3a65.png

网关的引入,有哪些改变呢?

  • 内外网解耦,在保持客外网客户端不变的情况下,可以通过这个中间层调整内网服务的实现
  • 规范化,由于请求是网关统一接受和分发的,会直接促使客户端在发送和接受请求时规范化
  • 安全,由于网关具有收口作用,所有的安全问题都可以在这里解决,保护内网,比如反爬,认证等功能
  • 限流熔断,在网关上实现限流,避免内网被突发流量压垮
  • 统一的监控告警平台

有了网关后,开始在下游增加业务逻辑,可能我们会把所有的业务都耦合成一个service,比如聊天挂了,派系挂了,场景挂了,都可能会对有戏本身产生影响;基于此,不得不考虑拆分进程,之前的游戏service服务,可能会被拆分为多个服务,但是对于大多数的游戏开发人员来说,基于服务的开发,比基于进程的开发,也难的多,如果不是领导推进,也不会有人愿意把聊天做成一个单独的服务。

对于游戏来说,服务拆分最最极端的情况,就是一个消息cmd对应了一个service,但是这种情况会导致service越来越多,无法维护的程度,实际上游戏拆分也确实没有必要。不过服务service越来越多,某个service甚至处于内存,cpu瓶颈的状态,应该如何解决呢?这时候rpc的服务治理派上了用场。我们对上面的图示做下改动:

3899ea6a301a1c871f730891a0d07deb.png

game-rpc的引入,解决了哪些问题呢?

  • 开发人员不再需要关注内部通信机制,减少项目开发时间,降低成本
  • 强大的集群容错,负载均衡能力等,保证每次调用都能路由到合适的节点

service与service做成了集群,每个service启动后,往zk或nacos注册中心注册自己的url。gateway在启动后,订阅zk注册中心的service列表,依托于rpc本身强大的集群,负载等功能,可以自动实现service的切换。

在针对rpg等长连接游戏类型时,玩家在场景中的移动都需要同步,广播给周围的玩家,但是rpc是单通道的,不能回传,这应该如何处理呢?

有借于此,game-rpc增加了全双工的概念,不仅仅是client对service的请求,同时service也可以根据uniqueId,进行主动推送。于是上面的流程图变成了下面这样:

3df70a20310642e44c7eec18eab4122f.png

一切看上去都很完美,似乎没有问题了,然而新的问题随之出现。

我们知道,优秀的架构体系中,单点问题是不能容忍的,很不幸,我们的gateway,就出现了单点。随着玩家数量的增加,整个服务都会处于不可用的状态。于是网关需要拆成集群的模式,新的架构图显示如下:

81fda08b06f0c3215769f32a1f6beffa.png

网关拆分后,gate1和gate2的玩家是两个tcp长连状态的服务,无法交互,这应该怎么办?

我们参照了现行市面上比较常用的tcp网关做法,消息下行通知的解决方案,目前框架支持了两种方式:

  • MQ广播机制,当某台网关服务器收到广播消息后,MQ通知给集群内的所有gate server,每个gate在收到消息后,判断要推送端的消息是否是当前gate所持有的会话,如果在当前服务,则进行推送,否则抛弃
37c9846431f5b3a821d874d109a8c41e.png
  • redis session共享,针对MQ的广播机制,如果以后游戏火爆,同时有百万玩家在线,那么gate集群里的机器,可能会达到上百台不等,如果每个消息都需要MQ广播,有可能会导致信号风暴,于是我们调整了最后一种解决方案。玩家在登录网关,认证成功后,把玩家id作为key,当前连接的网关uniqueId作为value,存储到redis集群中。网关随后把消息路由到具体某个service,service从redis集群里获取到需要广播的玩家对应的gate服务,service通过rpc消息下行,直接推送到具体的gate,再由gate转发到client
e5a0023e92e6acd1ebd7c861485dcb09.png

说明:这种架构,更适用于全区全服类型的游戏。目前我们已经有多款线上游戏使用。

作者:二周目赤

出处:https://www.cnblogs.com/cr1719/p/13866841.html

表情包
插入表情
评论将由博主筛选后显示,对所有人可见 | 还能输入1000个字符
相关推荐
©️2020 CSDN 皮肤主题: 数字20 设计师:CSDN官方博客 返回首页