个人备案网站做购物网站可以不,莱州网络公司,网络优化公司排名,郑州市网站建设作者:二周目赤出处:https://www.cnblogs.com/cr1719/p/13866841.html我们最开始做的游戏框架#xff0c;多数都是client—server—db的模式#xff0c;但是随着玩家数量的增加#xff0c;一个server进程就会扛不住#xff0c;需要多个进程服务于多个玩家。但是给定…作者:二周目赤出处:https://www.cnblogs.com/cr1719/p/13866841.html我们最开始做的游戏框架多数都是client—server—db的模式但是随着玩家数量的增加一个server进程就会扛不住需要多个进程服务于多个玩家。但是给定了不同进程的玩家有可能需要交互这就导致了client与server端的连接有可能是o(1)但也可能是o(n)连接o(n)的扩展性非常差不容易维护因此可以剔除了。但是如果只保持o(1)那必然要引入新的抽象服务网关也就登场了。下图是一个简单的网关部署架构网关的引入有哪些改变呢内外网解耦在保持客外网客户端不变的情况下可以通过这个中间层调整内网服务的实现规范化由于请求是网关统一接受和分发的会直接促使客户端在发送和接受请求时规范化安全由于网关具有收口作用所有的安全问题都可以在这里解决保护内网比如反爬认证等功能限流熔断在网关上实现限流避免内网被突发流量压垮统一的监控告警平台有了网关后开始在下游增加业务逻辑可能我们会把所有的业务都耦合成一个service比如聊天挂了派系挂了场景挂了都可能会对有戏本身产生影响基于此不得不考虑拆分进程之前的游戏service服务可能会被拆分为多个服务但是对于大多数的游戏开发人员来说基于服务的开发比基于进程的开发也难的多如果不是领导推进也不会有人愿意把聊天做成一个单独的服务。对于游戏来说服务拆分最最极端的情况就是一个消息cmd对应了一个service但是这种情况会导致service越来越多无法维护的程度实际上游戏拆分也确实没有必要。不过服务service越来越多某个service甚至处于内存cpu瓶颈的状态应该如何解决呢这时候rpc的服务治理派上了用场。我们对上面的图示做下改动game-rpc的引入解决了哪些问题呢开发人员不再需要关注内部通信机制减少项目开发时间降低成本强大的集群容错负载均衡能力等保证每次调用都能路由到合适的节点service与service做成了集群每个service启动后往zk或nacos注册中心注册自己的url。gateway在启动后订阅zk注册中心的service列表依托于rpc本身强大的集群负载等功能可以自动实现service的切换。在针对rpg等长连接游戏类型时玩家在场景中的移动都需要同步广播给周围的玩家但是rpc是单通道的不能回传这应该如何处理呢有借于此game-rpc增加了全双工的概念不仅仅是client对service的请求同时service也可以根据uniqueId进行主动推送。于是上面的流程图变成了下面这样一切看上去都很完美似乎没有问题了然而新的问题随之出现。我们知道优秀的架构体系中单点问题是不能容忍的很不幸我们的gateway就出现了单点。随着玩家数量的增加整个服务都会处于不可用的状态。于是网关需要拆成集群的模式新的架构图显示如下网关拆分后gate1和gate2的玩家是两个tcp长连状态的服务无法交互这应该怎么办我们参照了现行市面上比较常用的tcp网关做法消息下行通知的解决方案目前框架支持了两种方式MQ广播机制当某台网关服务器收到广播消息后MQ通知给集群内的所有gate server每个gate在收到消息后判断要推送端的消息是否是当前gate所持有的会话如果在当前服务则进行推送否则抛弃redis session共享针对MQ的广播机制如果以后游戏火爆同时有百万玩家在线那么gate集群里的机器可能会达到上百台不等如果每个消息都需要MQ广播有可能会导致信号风暴于是我们调整了最后一种解决方案。玩家在登录网关认证成功后把玩家id作为key当前连接的网关uniqueId作为value存储到redis集群中。网关随后把消息路由到具体某个serviceservice从redis集群里获取到需要广播的玩家对应的gate服务service通过rpc消息下行直接推送到具体的gate再由gate转发到client说明这种架构更适用于全区全服类型的游戏。目前我们已经有多款线上游戏使用。作者:二周目赤出处:https://www.cnblogs.com/cr1719/p/13866841.html
