背景

最近接手了一个新游的架构设计，因为新游偏向社交类游戏，单个游戏体内会存在多人联机、多种不同类型游戏对局的交互，即要考虑多种不同玩法服务的兼容和多人联系情况下的稳定性。

问题

传统的C/S架构中，可以一定程度上容忍server侧的变更或者某个实例突发宕机的情况（大不了重新请求一下就好了），但游戏架构要求多人联机场景下的稳定性和兼容性，无法容忍游戏联机过程中server中某个实例突发宕机或扩缩容的情况，因为当一个容器突发宕机，那就意味着那个容器上的游戏对局将会受到影响，严重影响用户体验。

我们先来看看使用C/S架构开发游戏的架构模式：

从这个架构中可以明显看出下面的这些问题：

1. 数据同步链路长：在一场对局中，传统C/S架构下，每个客户端WS所连接的Server实例可能不一样，并且同一个对局内的数据流同步必须依赖中间件进行，数据流传输链路长，高负载请求下，可能出现延迟感知明显的问题。
2. 稳定性不足：假如某个实例宕机，此时对应的用户会突然断开连接并丢失部分操作请求，影响对局进程。
3. 延迟较高：客户端可能分布在世界各地，每个客户端到服务的延迟都不同，在多人游戏对实时性要求较高的情况下，不同的游戏延迟会导致用户感知到的对局数据不同，影响游戏体验
4. 开发/维护成本较高：即使在不同的游戏模式下，都需要单独在不同模式的游戏serevr中实现相同的对局、房间管理逻辑，而客户端需要根据不同的游戏模式去连接不同的对局服务器，额外增加成本。

DS

没有什么是设计一个中间层解决不了的。面对多人联机社交游戏场景下的服务设计，我们引入DS服务层的概念来解决这个问题。

DS，全称叫做Dedicated Server（专用服务器），它可以用来给多人联机时提供稳定的房间信息管理和对局进度管理以及用户客户端的WS连接管理，并且一定程度上可以降低我们多游戏业务的开发成本。

那么我们来引入DS看下引入DS之后的架构：

DS优势

可以看到，引入DS之后，每个游戏客户端所连接的WS服务节点由DS统一调度管理，提高整个系统的可维护性。

1. 在同一个对局内，每个客户端连接的对局服务器在同一个实例上面，这样可以最大程度减少数据同步带来的性能损耗。

2. 数据会在DS内部的cache实例上缓存，假如在对局运行中某个DS实例崩溃，那么此时DS网关可以快速将实例上的所有连接转到其他实例，并从cache中把相关数据load到新实例里面，在用户端的感知也仅仅只是短暂断线重连，而且作用于同一对局内的所有用户，可以保证游戏对局进程影响最小化。

3. 得益于DS收束了所有的WS代理连接，那么我们就可以支持游戏客户端在一个游戏场景中，同时使用多个游戏WS服务，而客户都只感知到了一个WS数据流，多个WS客户端有DS实现WS映射。

例如：在一个游戏场景中，存在房间管理的WS、用户上下线的WS、用户沟通消息RTC信令、游戏玩法的对局数据WS等多个WS连接点，有DS的接入，客户端只需要接入一个DS的ws即可，如下架构图：