游戏服务架构之 网关

游戏服务架构

长连接

游戏服务的一个特点是，需要维护大量的长连接来保证用户与游戏间的通信，比如tcp长连接、websocket双工通信等。

多服务

游戏类服务器，为了各个模块之间不相互影响，一般都是微服务的方式实现，比如匹配、房间、游戏等都是单独部署的，为了让用户切换不同场景时，延迟更低，那就需要减少连接建立的次数，因此，需要考虑对一条连接持续复用。

网关的作用

作为连接层

但受限于单台机器的性能瓶颈，以及单点故障问题，用户的长连接一般不会直接与游戏实例。

为了提高用户打开语音房、小游戏的延迟体验，会尽可能对连接进行复用，所以会设计一个connector连接层，用于连接的管理，这种实现的好处有：

1. 用户建立连接过程的鉴权、限流、保活等操作可以统一管理；
2. 用户在切换不同房间、不同游戏模式时，不需要再次建立长连接，通过connector连接层进行服务转发即可，能显著降低请求延时；

实现负载均衡

connector层可以实现负载均衡，根据用户连接数的大小动态扩容；同时，还可以把玩家请求分配到多个内部服务中，防止某个机器过载，提高系统的整体可用性。

架构

根据上面的分析，可以得出一个简单的游戏服务器基本架构：

1. 外网SLB：实现用户流量的安全过滤、负载均衡；
2. 连接层：connector管理用户连接，通过RPC的方式把请求转发到具体的服务中；
3. 主动推送：内部服务需要主动推送一些信息给用户，比如实时修炼进度，通过PUSH的方式实现。

服用通信

上面介绍了游戏服务器的基础框架，但还有一些问题需要解决：

1. 网关收到的消息如何转发给内部服务？
2. 内部服务的主动推送如何获取到具体的网关服务实例？
3. 网关节点故障/下线后，维护的用户连接怎么办？
4. 内部服务实例故障后，会怎么样？

消息转发

消息转发有两部分，第一步是如何找到消息需要到哪个服务，然后是选择哪个服务实例。

寻找服务，可以通过在消息头中，指定消息类型，再根据维护的路由表找到消息对应的服务。

寻找游戏实例，可以通过uid取余的方式，找到一个具体的游戏实例即可。

主动推送

在网关把消息转发到具体的游戏实例前，可以对消息进行一些封装，携带当前网关id，这样内部服务需要push时，就可以通过记录的消息对应的id找到具体的网关实例。

网关节点数变化

网关下线时，维护的连接就会自动断开，重连接时也会分配到新的网关。

内部服务实例故障

同网关下线一样，RPC通知关闭，重新选择新的内部服务实例即可。