游戏运维活动中少不了做的事情就是停服更新，可能是因为版本更新、也可能是修复 BUG，当然修复 BUG 还可以用热修复（大部分热修复是有限制的，这里就不细说）。但是传统的游戏开发版本更新就避免不了停服更新了，目前也有些做的比较好的项目可以做到不停服更新版本。譬如：《王者荣耀》。

不停服更新的机制好处有如下几点：
1.不停服更新可以给用户更好的体验，可以无缝更新。用户只要在客户端更新完毕就可以立刻进新版本。
2.可以做灰度发布，新版本上线前先让一部分用户先更新到新版本，可以对比两个版本的数据，来验证新版本是否达到预期
3.灰度发布可以在发现重大 BUG 的情况下减少损失，等待新版本稳定后再对全部用户开放。但是要防止测试人员因为有了这个机制而松懈，因为这个机制是为了提高用户体验，而不是让用户来做测试。

注意：不管是使用上述的哪种方案，抑或是其他方案，都会存在额外的服务器费用以及版本运维和运营的成本增加。这个不难理解，需要的服务器多了，同时维护的版本也多了，出错的概率就更高了。如果没有比较好的版本规划或者没有充分的测试，可能带来反向效果。

下面是直观的切版本流程：

C.png

《王者荣耀》可以在旧版本游戏开局的情况下同时进行新版本发布，并且可以让旧版本玩家打完后再退出游戏，更新到最新版本从而进入新版本服务器。那他是怎么做的呢？没有官方的答案，但是我想原理应该很简单，大致就是用滚动更新的思路。简单说就是如果一台服务器可以支撑 1w 在线，那么支撑 100w 在线就是 100 台服务器，那么理论上来说，只要有第 101 台服务器，就可以实现不停服更新。原理就是，新版本在第 101 台服务器上发布。然后假设第 1 台的用户全退出了游戏，都进入到了第 101 这台服务器，他们都是最新版本了，这时候再把第 1 台服务器更新到最新服务器，第 2 台的用户全部退出了游戏都进入到了第 1 台服务器，第 2 台服务器又可以发布最新版本。。。 一直到所有人都更新到最新版本如图：

1.png

原理是如此简单，但是实际的实现起来却没那么容易，这里涉及到少量客户端的支持和 web 后台的一些工作以及高水准自动化运维（版本切换如果人工操作出问题的概率非常大）、还有 DB 数据同步，还有服务器确保同一时刻用户只能在一个版本中的事宜，是一个系统性的工作，系统粒度越是细，性价比越高，譬如《王者荣耀》项目做这种方案，肯定很划算。

小团队想要做这种不停服更新需要付出的代价还是挺高的，一方面是来自服务器费用，一方面是需要开发人员很给力。而且运营过程也容易因为弄错版本导致运营事故。总之代价不算低。但是如果真想实现，换种实现方式也可以做到差不多的效果，就是滚动的单元是按整体来做滚动，不像理想状态下的只滚动逻辑服，整体对开发人员相对少一些要求。两组服务器来进行滚动更新，服务器要多一套，然后按单双版本轮流更新切换。

这样要处理的事情就简单些了，只要确保用一个用户在同一个时刻只能存在同一个版本服务器中，并且数据一致性得到保障，还有 web 后台可以正确对不同版本进行操作就好了。

我这里以我目前的项目来举例（数据库用了 mongodb 和 redis，其他类型数据库可能不同，mongodb 可以动态改变文档的结构，而 mysql 数据表结构如果改动的情况下， 可能比较麻烦），做了两个滚服更新方案，照例上图

这是方案 A ，完全独立的两套系统。通过数据同步来达到目的。
这个方案的优点就是两套系统完全解耦，缺点就是如果 DB 同步没做好，容易出现：数据混乱、或者是并发上不去，其中一种情况。

A.png

这是方案 B ，除了主数据库外，各自独立的两套系统。
这个方案的好处就是不会出现数据混乱或者并发问题，而且主数据库用高配置外，conf 库可以使用比较低配置的实例，可以省较多的费用。缺点就是轻度的耦合，web 和 服务器 都有一部分读写相同的实例，一部分读写该版本才有的实例，在出现问题的时候定位稍微麻烦些，不过这个方案整体性价比还是比较高。

B.png

通过方案 A 或者 B 都可能做到新老版本的循环更新迭代，如版本 1 部署到 game A，版本 2 部署到 game B
版本 3 在 版本 2 跑起来， 版本 1 的人都下线的情况下，部署到 game A 如此类推。

既然在滚动更新的过程中有一段时间老版本和新版本是同时存在，那么多人交互就会出现版本不一致的情况，那么解决它的最好办法就是不同版本的用户不一起游戏。在新老版本共存期间，老版本只接受登出，不接受登陆，如果游戏是按一局为单位的，不更新到最新版本不可以进行匹配新游戏，即可。

最后我们敲定：
一、 conf 库还在同个实例中，用 conf + 版本号 的方式，如：conf1、conf2、conf3 ... 这样，每一个版本一个配置库。

二、 web 后台用一套，每次新版本发布，由 web 进行操作版本号的递增，假如当前版本为 1，那么升级就是 + 1 为 2，对应配置库就是 conf2, 一旦执行升级，老版本的配置就没法改动了，只能改动新版本配置。版本号只会增加，不会减少，如果特殊情况下需要改动老配置，需要由技术一起配合。这个约定就是比较重要的环节，用这样的方式来避免既有可能改老版本配置，又有可能改新版本配置带来的混乱。

三、web 进行操作版本号递增，分两个阶段，第一个阶段是对内开放新版本，这一期间测试人员进行内部测试。配置也可以进行调整修改，不影响当前对外在线跑的版本。第二个阶段就是由运营人员来正式发布新版本。通知所有玩家。这时候是正式滚服开始。

四、运维要做的事情就是把服务器分为 A系统 和 B系统。然后开发人员给到的运行程序会打包好，名字用 A 开头
或者用 B 开头，以区别版本是放到哪个系统（集群）上。如：执行文件压缩包 A_1_xxx.tar.gz 、 B_2_xxx.tar.gz 、 A_3_xxx.tar.gz ，这样的格式。奇数部署到 A系统，偶数部署到 B系统，运维用自动化检测版本和当前集群是否一致。

五、服务端要做的依然是做好多系统同用户的互斥，以及出运行程序时候的打包带上正确的版本号信息。

六、配置表每个版本都独立全量放在一个文件夹里，避免弄混了。

下面是最终方案：（这个方案最适合我们目前的实际情况）

F.png

下面是最终方案流程图：

D.png

选择用 redis 订阅发布功能来做消息通道的原因有几个：

1. 为了保持解偶，game A 和 game B 我并不想让它们知道彼此的存在，否则运行 game 的主机改变，都要做一些配置相关的修改。为了解决这个问题，前面的想法是每次登陆 web api 要判断是否灰度状态，如果灰度状态需要先通知旧版本踢人，再请求新版本网关信息，但是这里会带来性能热点。而且因为状态的变更容易出错。

2.redis 作为 订阅发布（类似观察者模式）之前在项目中用过，效率很高，如果老版本关闭了，也无需做检测，因为没人订阅踢人消息不影响流程。还有现成代码，这是之前用法。
https://www.jianshu.com/p/d865b6cd6bdb

3.对外隐藏细节，后续的维护相对容易些。web api 只需要判断版本号，请求对应的 game 即可，web 端的改动比较少。

下面是发布的流程：

E.png