Lua热更新实现

用途

在生产环境上，总有可能出现不可预知的Bug，而通常修改好Bug仅仅又修改几句，停机维护的成本又太高，对于游戏来说，通常每个服就是单独的进程，也做不到像分布式环境下，关掉一部分机器，先升级一部分，再升级另一部分的无缝升级。这时候如果有热更就可以迅速的把Bug修复方案通过热更新进行修复，不会对用户任何的影响。例如：

1. 业务逻辑有Bug
2. 配置的数据有误
3. 需求发生变更

热更新的原则

1、热更新不破坏原有数据

热更新更新的基本内容就是更新服务的逻辑，通常只是逻辑发生变化，但原有的值并不能被改变，例如：

local a = 1
function get_a()
    return a
end

此时，我们调用get_a()返回是的1，我们将热更成

local a = 2
function get_a()
    print("get_a function")
    return a
end

此时我们改变了a的初始值，但我们并不知道之前服务a的值是不是被重新赋过值，假设热更前a的值仍然为1，那么我们热更后调用get_a()返回的应该是1，而不应受新的初始值影响，而且同能打印出了"get_a function"，这时候则认为热更正常。

2、不为热更新写更多的代码

热更新可以通过很多种方法实现，比如说模块为了支持数据不变的特性，需要在模块里额外写一些代码来记录旧值，热更新之后再把旧值copy过来，或者用一些特殊的语法来支撑。这种方法将会对项目增加很多的负担，而且一旦发生意料之外的Bug，热更系统几乎处于半瘫痪状态。应该来说，代码原本该怎么实现就怎么实现，对于99%的lua代码都是支持的，不需要修改来迎合热更新。通常热更新不改变原有变量值的类型。

热更新的实现，代码适用于5.2以上

原理

利用_ENV环境，在加载的时候把数据加载到_ENV下，然后再通过对比的方式修改_G底下的值，从而实现热更新，函数

function hotfix(chunk, check_name)

定义env的table，并为env设置_G访问权限，然后调用load实现把数据重新加载进来

local env = {}
setmetatable(env, { __index = _G })
local _ENV = env
local f, err = load(chunk, check_name,  't', env)
assert(f,err)
local ok, err = pcall(f)
assert(ok,err)

此时env我们可以得到新函数有变更的部分，我们替换的为可见变量，也就是可直接访问的变量

for name,value in pairs(env) do
    local g_value = _G[name]
    if type(g_value) ~= type(value) then
        _G[name] = value
    elseif type(value) == 'function' then
        update_func(value, g_value, name, 'G'..'  ')
        _G[name] = value
    elseif type(value) == 'table' then
        update_table(value, g_value, name, 'G'..'  ')
    end
end

通过env当前的值和_G当前的值进行对比

1. 如果类型不同我们直接覆盖原值，此时value不为nil，不会出现原则被覆盖成nil的情况
2. 如果当前值为函数，我们进行函数的upvalue值比对

   function update_func(env_f, g_f, name, deep)
    --取得原值所有的upvalue，保存起来
    local old_upvalue_map = {}
    for i = 1, math.huge do
        local name, value = debug.getupvalue(g_f, i)
        if not name then break end
        old_upvalue_map[name] = value
    end
    --遍历所有新的upvalue，根据名字和原值对比，如果原值不存在则进行跳过，如果为其它值则进行遍历env类似的步骤
    for i = 1, math.huge do
        local name, value = debug.getupvalue(env_f, i)
        if not name then break end
        local old_value = old_upvalue_map[name]
        if old_value then
            if type(old_value) ~= type(value) then
                debug.setupvalue(env_f, i, old_value)
            elseif type(old_value) == 'function' then
                update_func(value, old_value, name, deep..'  '..name..'  ')
            elseif type(old_value) == 'table' then
                update_table(value, old_value, name, deep..'  '..name..'  ')
                debug.setupvalue(env_f, i, old_value)
            else
                debug.setupvalue(env_f, i, old_value)
            end
        end
    end
   end
   

3. 如果当前值为table，我们遍历table值进行对比

   local protection = {
    setmetatable = true,
    pairs = true,
    ipairs = true,
    next = true,
    require = true,
    _ENV = true,
   }
   --防止重复的table替换，造成死循环
   local visited_sig = {}
   function update_table(env_t, g_t, name, deep)
    --对某些关键函数不进行比对
    if protection[env_t] or protection[g_t] then return end
    --如果原值与当前值内存一致，值一样不进行对比
    if env_t == g_t then return end
    local signature = tostring(g_t)..tostring(env_t)
    if visited_sig[signature] then return end
    visited_sig[signature] = true
    --遍历对比值，如进行遍历env类似的步骤
    for name, value in pairs(env_t) do
        local old_value = g_t[name]
        if type(value) == type(old_value) then
            if type(value) == 'function' then
                update_func(value, old_value, name, deep..'  '..name..'  ')
                g_t[name] = value
            elseif type(value) == 'table' then
                update_table(value, old_value, name, deep..'  '..name..'  ')
            end
        else
            g_t[name] = value
        end
    end
    --遍历table的元表，进行对比
    local old_meta = debug.getmetatable(g_t)
    local new_meta = debug.getmetatable(env_t)
    if type(old_meta) == 'table' and type(new_meta) == 'table' then
        update_table(new_meta, old_meta, name..'s Meta', deep..'  '..name..'s Meta'..'  ' )
    end
   end
   

更新

1、可以调用hotfix_file对整个文件进行热更

function hotfix_file(name)
    local file_str
    local fp = io.open(name)
    if fp then
        io.input(name)
        file_str = io.read('*all')
        io.close(fp)
    end

    if not file_str then
        return -1
    end
    return hotfix(file_str, name)
end

2、可以通过hotfix进行代码的更新

function hotfix(chunk, check_name)

关于坑

这里有一个注意事项，lua的module模块，如：

module("AA", package.seeall)

当我们加载lua模块的时候，这时候这个模块信息并不像初始化全局代码一样，就算提前设置了package.loaded["AA"] = nil, 也不会出现在env中同时也不会调用_G的__newindex函数，也就是说env["AA"]为空，故这种写法无法进行热更新，所以通常模块的写法改成如下

--定义模块AA
AA = {}
--相当于package.seeall
setmetatable(AA, {__index = _G})
--环境隔离
local _ENV = AA

我们之前的服务器是多进程纯C#架构的服务器。最近游戏上线，遇到有时候需要线上修bug的问题。之前对代码热更新预料不足，导致在线上出了一些bug时非常被动，往往需要重启服务器解决问题，影响前期的体验。我们的游戏类型是一个RPG卡牌游戏，操作偏向于单机向，大量依赖于广播的操作比较少。

这周的时间里，也考虑了几种方案，下面对比下思考的结果。

嵌入动态脚本

首先，C#+python或者lua的游戏服务器解决方案没有成功实例。现在最有名的ulua和xlua都是基于unity引擎的，在服务器的性能和承载上没有无法验证。没有成熟框架情况下，脚本和非脚本分层等如何来设定，还是需要比较多的设计和开发时间的。

其次，程序员使用脚本语言进行编程比用C#进行敏捷编程效率会差，vs等工具对于效率、正确性提升的红利会消失。此外，也是公司自己的原因，整体转变带来了不可预估的时间成本，以后的项目使用lua开发正确性能不能保障，会不会出现更多的bug？

其他的一些问题。比如一些自动化的代码（配置表，网络数据发送）往往需要在宿主语言和脚本语言上都实现一份等。这些工作会带来不少额外的工作量。

mono代码热更新

因为最终服务器是运行在linux环境下，用mono运行的，而mono是完全开源的。曾经有一位163的牛逼同事，实现了这么一套热更新的方案。方案原理是可以在运行时让mono把内存中的xxx.exe的某一些代码片段改掉，或是把入口重定向掉。

这种方法可以用来修一些bug，但很难去做一些小型新功能的支持。因为原型仅仅可以支持代码片段IL代码的改写，没法支持对新类型的操作等。

另一个缺点是，部分语法比较难以替换，比如泛型函数，闭包访问hold住的对象等，这些在虚拟机层面实现也是比较复杂的语法，在做mono热更新时就会是一些坑点的。如果我们可以完美支持mono热更新，需要了解很多底层语法的机制，那开发量可能与重写一个mono处于一个量级。

最后一个缺点是，热更新操作不如lua热更新直观。需要先编译出新的xxx.exe，然后通过工具生成出新老exe的il差，并导出成mono可以识别的文本。最后，线上触发mono去加载这个文本进行替换。而这里的步骤在lua热更新中，只需要简单的把错误的xxx.lua替换一次就可以了，我们的操作明显复杂。

实现无状态服务器

这一点主要是因为我们期望的游戏服务器类型是一个比较单机化的类卡牌游戏，才有可能这么去实现一个服务器架构。无状态服务器的最大优点是，逻辑和存储分离。也就是逻辑处理服务器只有处理器，没有状态，有点类似于actor模型；而存储服务器（可以是redis，也可以自己实现）则之提供存储和读取数据等简单稳定接口，保障存储服务器的稳定，就没有对存储服务器进行热更新的需求了。

这种框架之下，逻辑处理服务器就可以比较随意的重启了，以此实现了基于冷更新的服务器更新功能，但是玩家并不会感受到游戏更新或是断开。这种情况下，同时运行的几个服务器进程在某段时间内可能是不同版本的，可以实现一个版本逐步更替的过程。

这个方案会带来一些复杂性

• 需要一个调度服务器（CONTROLSV）调度新的LOGICSV替代旧的服务器的过程，所以这个服务器需要维护已有的服务器组。
• 需要拆分出一个能够配合存储流程的转有存储节点STORESv
• LOGICSv的逻辑代码，当需要访问和存储数据时，原本只需要访问内存对象，现在需要异步访问。增加了代码编写的复杂度。
• LOGICSv节点因为没有数据，如果要发起一些主动的update操作，也要异步去db取数据再改写。更严重的是，在操作大量数据时（比如对所有在线玩家update），会造成内部io和访问延迟比较大，并可能造成和玩家线程存取数据的冲突。