游戏服务架构
长连接
游戏服务的一个特点是,需要维护大量的长连接来保证用户与游戏间的通信,比如tcp长连接、websocket双工通信等。
多服务
游戏类服务器,为了各个模块之间不相互影响,一般都是微服务的方式实现,比如匹配、房间、游戏等都是单独部署的,为了让用户切换不同场景时,延迟更低,那就需要减少连接建立的次数,因此,需要考虑对一条连接持续复用。
网关的作用
作为连接层
但受限于单台机器的性能瓶颈,以及单点故障问题,用户的长连接一般不会直接与游戏实例。
为了提高用户打开语音房、小游戏的延迟体验,会尽可能对连接进行复用,所以会设计一个connector连接层,用于连接的管理,这种实现的好处有:
- 用户建立连接过程的鉴权、限流、保活等操作可以统一管理;
- 用户在切换不同房间、不同游戏模式时,不需要再次建立长连接,通过connector连接层进行服务转发即可,能显著降低请求延时;
实现负载均衡
connector层可以实现负载均衡,根据用户连接数的大小动态扩容;同时,还可以把玩家请求分配到多个内部服务中,防止某个机器过载,提高系统的整体可用性。
架构
根据上面的分析,可以得出一个简单的游戏服务器基本架构:
- 外网SLB:实现用户流量的安全过滤、负载均衡;
- 连接层:connector管理用户连接,通过RPC的方式把请求转发到具体的服务中;
- 主动推送:内部服务需要主动推送一些信息给用户,比如实时修炼进度,通过PUSH的方式实现。
服用通信
上面介绍了游戏服务器的基础框架,但还有一些问题需要解决:
- 网关收到的消息如何转发给内部服务?
- 内部服务的主动推送如何获取到具体的网关服务实例?
- 网关节点故障/下线后,维护的用户连接怎么办?
- 内部服务实例故障后,会怎么样?
消息转发
消息转发有两部分,第一步是如何找到消息需要到哪个服务,然后是选择哪个服务实例。
寻找服务,可以通过在消息头中,指定消息类型,再根据维护的路由表找到消息对应的服务。
寻找游戏实例,可以通过uid取余的方式,找到一个具体的游戏实例即可。
主动推送
在网关把消息转发到具体的游戏实例前,可以对消息进行一些封装,携带当前网关id,这样内部服务需要push时,就可以通过记录的消息对应的id找到具体的网关实例。
网关节点数变化
网关下线时,维护的连接就会自动断开,重连接时也会分配到新的网关。
内部服务实例故障
同网关下线一样,RPC通知关闭,重新选择新的内部服务实例即可。