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