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