网络游戏架构的前世今生——热更

上文：网络游戏架构的前世今生——网关

3.6 停服与热更

把眼光跳出游戏行业之外，停服维护是大多数应用更新版本时的选择。一个项目周期推进完毕后，修复了一些已知bug，增加了一些新的功能，选择在线用户较少时更新服务器版本（通常是在半夜）。有些应用会提前发出维护公告，或是每周固定一个时间段进行维护。也会遇到突发状况，例如临时发现紧急bug需要尽快修复上线，这种突发状况会导致应用的某些页面或模块会处于无法正常响应用户请求的状态，日常使用手机、电脑的过程中也不少见。

这是最容易实现的更新方案。我们在本地开发好一个新的版本，为了避免出错，最简单的办法就是关闭老版本的服务器，等客户端全部下线后，再部署并开启新版本的服务器，经过内部人员的测试通过后，再开放给用户正常使用。更进一步，我们可以准备一个只对内部开放的灰度服，则可以尽量降低停服维护的时间。

游戏服务器的更新也是如此。回到之前五子棋的例子，我们计划将原先的匹配功能，拆分为休闲模式和积分匹配模式两种，于是我们花费了两周的时间开发、测试，准备更新版本。我们的五子棋拥有网页客户端、手机客户端等不同客户端的接入。

对于网页客户端，我们可以提前准备好网页的分发，停服维护后切换域名解析即可。对于手机客户端，需要提前打包好游戏，上传 app 分发平台审核，并预先设置好发布时间。偶尔会遇上客户端打包太晚、或是审核不能及时通过的情况，保险起见我们让开发注意新的服务器版本兼容当前版本，即让当前版本也能正常游戏。

我们成功完成了第一次停服更新。过了一天后，我们发现了一个严重的 bug，导致休闲模式无法正常匹配，需要紧急修复。于是我们临时发送了一个停服维护的通告给全体玩家，然后按约定时间开始停服维护。维护后不久，我们又发现了积分匹配模式的严重 bug，这一次需要客户端和服务器都进行更新。而手机客户端的更新流程较长，玩家在这期间怨声载道，我们需要解决这一问题。

原先我们使用一种语言编写游戏客户端，UE4 C++ 或是 Unity C#，为了赋予客户端热更的能力，我们需要改造这一架构。我们将手机客户端的编写分为两层，一层是运行高效的非脚本语言，另一层是方便热更新的脚本语言，例如常见的 C# + Lua、C# + JS 等。将底层的模块由非脚本语言编写，例如网络模块、渲染、场景切换等，而将用户逻辑层的模块由脚本语言编写，例如游戏逻辑 Gameplay、商城页面等。而这种切分方案也符合二八定律，八成的代码是脚本语言，拥有方便热更新的能力，但同时只有不到二成的时间在运行；二成的代码是非脚本语言，没有热更新的能力但稳定高效，超过八成的时间在底层网络、渲染、交互上。脚本语言的上手门槛低和调试门槛低，更适合一个高速迭代的游戏开发团队使用；而非脚本语言的内容，往往会提炼成一套公司特有的游戏框架，经历项目的考验和修复，不会轻易大改。

早期的应用市场支持 C# 的热更，但现在根据平台的不同有不同的限制，使用 Lua 等脚本语言是主流。
游戏客户端的热更偏离了本专栏的重点，可以查阅其他书籍资料查看这块内容。

我们解决了客户端的问题，绝大多数时候都能通过热更来更新客户端。少数情况下需要动到非脚本语言的代码，例如游戏大版本更新涉及到大功能模块的调整，或是网络库的更新。玩家的抱怨减少了，但在持续运营一段时间后，通过分析数据我们发现了新的问题——每次停服更新都会导致玩家在线人数骤降，频繁的停服对玩家的留存有明显的负面影响。

这个问题是我个人几款游戏的经验，不代表大部分游戏的情况。事实上，我最近玩过的国内几款手游，都是处于每周一次停服维护的状态，偶尔会有临时的停服维护发公告，并没有解决上面这个问题。

我们需要不停服维护，热更服务器。如果是会话类游戏，那战斗服务器不需要热更，每局游戏时长有限，下一局使用新版本即可，只需要考虑逻辑服的热更；而非会话类游戏没有明显区分。

我们可以仿照游戏客户端的做法，将大部分业务逻辑分拆出去，使用脚本语言编写。例如使用 KBEngine 框架，用 C++ 编写底层架构，用 Python 编写业务逻辑，这在通常的更新迭代中就够用了。我以前使用过 Cocos 做客户端，那么服务器使用 JS 作为脚本语言，可以共用部分代码。同理，Lua本身就很适合做服务器脚本语言，且性能是这几个方案中最高的，一般全球同服方案最简单的实现，就是借助 Nginx+Lua 快速投入生产使用。

即使采用了上面的方案，我们还是需要定期停服维护服务器，因为那些非脚本语言的更新还是需要重新编译重新启动。有没有更好的方案？

滚动更新 （Rolling Update）能真正做到这一点，并且不需要引入任何脚本语言，最大化服务器的性能。具体方案如何？且待下一章 《微服务》 分解。

下期预告：
3.7 微服务