位置: IT常识 - 正文
推荐整理分享网络游戏架构的前世今生——网关(游戏的系统架构),希望有所帮助,仅作参考,欢迎阅读内容。
文章相关热门搜索词:网络游戏体系结构,游戏架构设计,网络游戏架构的定义,游戏的架构模式,游戏架构是什么,网络游戏架构的英文缩写,网络游戏架构的英文缩写,网络游戏体系结构,内容如对您有帮助,希望把文章链接给更多的朋友!
上文: 网络游戏架构的前世今生——非会话游戏
3.5 网关2018年,我在上海游戏圈推行网关 Gate 这个概念,也是我第一次从一个架构的学习者,逐步转变成一个架构的实践者的过程。其实现在网关这个概念早已走进民众视野,打开购物网站 app 搜索网关,能搜出一系列的产品,通常是指家用物联网网关。网关在我的理解中,既是对外实现广域互联的统一入口,也是对内实现局域互联的中转站,能解决设备或应用变多而导致的组网问题。简单来理解,就是一个网络流量的统一入口,转发到其他实际工作的服务器上。
在游戏中,网关是对外面向客户端的统一入口。在玩家完成登录等前置操作后,网关开始发挥作用,理论上网关不执行任何业务逻辑,只做筛选和转发。
如果没有网关,逻辑服直接暴露给玩家,会产生如下几个问题:
逻辑服实例越多,管理越麻烦,切换也麻烦无法做到无缝切服换服,有等待时间权限和审查下移,安全风险大大增加一条一条来看,如果是小体量的游戏,所有逻辑服业务逻辑写成一个单体应用,那对于第一条不会有太大感触。随着业务量的提升,不管是出于功能的分类还是水平的扩展角度,逻辑服实际包含的服务器实例的数量会变多。客户端需要写入更多的服务器地址,或者使用其他地址获取方案。而如果使用网关,客户端只需要记录网关服的服务器地址即可,不管之后游戏功能如何变迁,永远只需要和网关对接,客户端不需要受后端架构影响。
第二条是最容易体会的。传统的切服换服是需要断开长连接返回“登陆后尚未建立长连接”的状态,由派发服 Dispatch (注:这里的“派发服”是我自己取的名,仅供参考)列出当前可以选择的所有区服,择一获取区服连接地址建立连接(有些游戏的区服选择不在UI进行展示,玩家感知较弱,但其本质相同)。这个过程涉及到断开长连接与再建立的过程,不管切换这个过程的UI交互如何设计,必然会面临切换连接的网络卡顿问题,无非是UI交互上如何优雅的提升用户体验。而如果最前面是一层网关层,玩家客户端是与网关建立的长连接,切服换服只是把网关背后的逻辑服实例更换了一下,并不会直接影响到客户端与网关直接的连接,所以可以做到无缝切服换服。
第三条是隐性且容易被忽视的,一个游戏在被 DDos 攻击后,被其他各种各样的手段入侵后,才会去考虑这一系列的问题。这时候游戏架构已经成型,无法大改,只能选择接入一些安全产品,能提升多大的防护力不得而知。如果我们将逻辑服的业务逻辑直接暴露在公网之上,想要做安全策略需要在每一个服务上编写,例如审计、IP黑白名单、用户权限、异常记录、封禁等。这样不仅工作量大,也很难从工程上确保每个服务都保质保量的做好安全策略,即攻击面分散,易被各个击破。我们只需要缩小直接面对敌人的接入面,就能将防守的精力集中,才有可能做好这件事,即最小化攻击面。回头再看看上面网关的架构,网关作为对外的统一入口,其实也承担了安全防护的职责。我们只需要在网关上编写我们的安全策略即可,当然也可以在网关上集成第三方的安全服务,事半功倍。
我一直认为网络安全是一场攻防战,不存在最锋利的矛,也不存在最坚固的盾。最小化攻击面实则为工程实现提供了一种可能——只需要在一处地方编写安全策略,从而防护所有服务的可能,这并不意味着不去编写安全策略就能防护,更不意味着编写了安全策略就能防住。需要有正确合适的心理预期在这件事上。
由上面几点引申而来,分出网关服这一方案有一个突出的优点,这个方案实则是从强有状态的逻辑服中剥离出一块无状态的部分。为了追求接口的处理速度和返回效率,在游戏工程项目上逻辑服都是有状态的,每个用户的状态信息被储存在内存中,且优先被读取使用。而网关服要做的事和游戏业务逻辑无关——筛选和转发,是很容易写成无状态的。这里的无状态不是严格意义上的无状态,而是网关服不存游戏玩家信息,可以轻易切换、关闭而不用担心会丢失信息。这一特性决定了,网关服能直接水平扩展,即可以开任意多个,可以自由的在高峰期扩展数量、在低谷期收缩数量,可以在 DDoS来临时快速启动更多的实例扛住并筛选掉攻击流量,保证后方业务逻辑正常运转。当然这是建立在物理机或虚拟机资源无限的情况下,实战中还需考虑成本。
网关中唯一的“状态”是用户的长连接信息,网关1保存的客户端连接和网关2中保存的客户端连接完全不同。但这个信息是可被丢弃的,客户端只需要和其他网关重新建立长连接即可。
在游戏中,网关也是对内实现局域互联的中转站。游戏通讯是全双工的,逻辑服某一块业务例如邮件系统,有主动发送内容给客户端的需求,而不是请求-响应(request & response)模型。逻辑服中这样的系统有很多,如果逻辑服实例各自为战,每一块代码都是自行通知客户端,则整个网络拓扑复杂。我们可以通过网关来实现一个中转,从而实现逻辑服业务层隐藏在接入层之下,应对策划等需求方不断的业务调整。
当然,网关也可以作为逻辑服内实例的中转站、逻辑服与战斗服的中转站。逻辑服与战斗服的交互可以很好的借助网关来完成,同时能利用上述的鉴权等安全措施防止伪造战斗服。同时也进一步解耦战斗服和逻辑服,中间由无状态的网关隐去双方的业务实现。至于逻辑服内部的中转,实用性不大,有更好的服务发现方案运转这个体系,后文会有详细介绍。
下期预告: 3.6 停服与热更 3.7 微服务
下一篇:Vue学习之从入门到神经(两万字收藏篇)(vue快速入门)
友情链接: 武汉网站建设