网游自动开服不是什么有难度的技术，严格来说只能算是一个业务需求。这篇文章会介绍一种自动开服的方案，梳理清楚实现逻辑以及相关的注意点。
写在前面
虽然把方案形容成“自动”，但并非是我们想象中的流程： 服务器自动购买/部署->新服运行->玩家进入， 而是在 服务器自动购买/部署 这一步做了一些妥协。
为什么？
现在云服务都提供API接口来购买相关的服务器，很方便同时也很复杂。复杂的原因在于需要考虑的异常因素较多，几个重要的：
- 账户余额是否足够；
- 对应地域的云资源是否有剩余；
- 当前是否还有必要继续开服/开服节奏问题；
所以我们在实现自己业务需求的同时还得考虑与云平台种种交互异常以及客观条件约束，一是增加开发成本、二是增加系统复杂度。
最终我们放弃了这种API购买方案，采用的是 预先购买/部署 的方式，通俗点讲就是： 先把服务器准备好，再考虑自动开服的逻辑 。
这些做的优点是：完美避开上述三个问题以及其他通过API与平台交互的问题，缺点是：每次服务器新增需要一部分手工操作，但是总体评估下来是利大于弊的。
需求拆分
服务器准备
建议的操作是制作已经安装好服务器运行环境的系统镜像，购入新的服务器后通过自定义的系统镜像安装系统，再通过shell脚本一键部署，将服务器进程和相关辅助进程启动起来。
开服时机
一般来说自动开服的时机会根据当前 新区创角人数 这个维度展开（可能也会考虑活跃和同时在线人数），这些都是比较容易统计的运营数据。为了统计相关数据，可以单独实现一个模块（暂时称为：ZoneStatSvr）来处理。
增加服务器状态
正常来说服务器状态包括但不限于 正常、火爆、繁忙、维护 这些状态，我们需要多出一个状态- 隐藏 （客户端不可见且服务端不可进入）用于自动开服。
数据持久化
可以通过mysql进行支持，mysql进行简单的主备。
业务流程图
GameSvr：游戏逻辑服务器，用户游戏逻辑核心处理，同时将玩家创角行为上报至ZoneStatSvr；
GateWaySvr：网关服务器，用户接入层核心，定期去ZoneStatSvr更新区服状态；
ZoneStatSvr：区服状态服务器，持有区服状态，检测新开服的条件是否满足；
一些细节：ZoneStatSvr持有两份区服状态，一份固定状态，这部分用配置表的方式实现，比如：
- zone 1 – 正常
- zone 2 – 隐藏
- zone 3 – 隐藏
- ……
还有一份变化状态，这份状态内存持有，同时定期落地到mysql，比如：
- zone 2 – 角色数 – 开启
- zone 3 – 角色数 – 开启
最终将两份状态合并得到服务器最终的状态，也是用户看到的状态：
- zone 1 – 正常 – 开启
- zone 2 – 正常 – 开启
- zone 3 – 正常 – 开启
- ……
一些问题点
ZoneStatSvr单点问题？
涉及到两个情景：
- 进程重启，在重启时固定状态通过读取配置表恢复，变化状态通过读取mysql数据恢复，最多会丢失1分钟非敏感数据，可以接受；
- 进程所在服务器宕机即ZoneStatSvr进程死亡，不影响整个服务器逻辑的运行，自动开服功能会暂停，需要尽快恢复进程，接受程度与恢复快慢有关；
mysql可用性？
使用分机主备的mysql可以达到99%~99.9%的可用性（如果你使用是云服务那么可用性应该更高）。
即使mysql不幸出问题，ZoneStatSvr内存中还是会持有数据，我只需要尽快恢复mysql服务/数据即可。
如果ZoneStatSvr也同时出问题了，好吧，这种概率…….
进程不够了？
可能在没注意的情况下游戏服进程不够了，这个时候开服逻辑上不应该出错，默认行为就是无新服可开，一直保持当前的服务器状态。
做的更完美些，可以短信通知相关人员：游戏服进程已经使用完毕，收到短信后看情形是否进行服务器添加。
扩充新服？
只用修改区服状态配置表里的固定信息，所以ZoneStatSvr最好支持区服信息配置表的热加载。
（全文结束）
转载文章请注明出处：漫漫路 - lanindex.com