如何在OpenResty里实现代码热更新

所谓「代码热更新」,是指代码发生变化后,不用 reload 或者 graceful restart 进程就能生效。比如有一个聊天服务,连接着一百万个用户的长连接,所谓代码热更新就是在长连接不断的前提下完成代码更新。实际上因为所有的 require 操作都是通过 package.loaded 来加载模块的,只要代码是以 module 的形式组织的,那么就可以通过 package.loaded 实现代码热更新,并且基本不影响性能。

下面让我们做个实验来说明一下如何实现代码热更新的,首先设置如下配置:

lua_code_cache on;
worker_processes 1;

location /run {
    content_by_lua '
        ngx.say(require("test").run())
    ';
}

location /unload {
    allow 127.0.0.1;
    deny all;

    content_by_lua '
        package.loaded[ngx.var.arg_m] = nil
    ';
}

需要说明的是,之所以把 worker_processes 设置为 1,是因为每个 worker 进程都有一个独立的 lua vm,设置成 1 更方便测试,稍后我会说明大于 1 的时候怎么办。此外,有两个 location,其中 run 是用来运行模块的,unload 的是用来卸载模块的。

接着在 package.path 所包含的某个路径上创建 test 模块:

local _M = {}

function _M.run()
    return 1
end

return _M

逻辑很简单,就是返回一个数字。一切准备就绪后,reload 一下 ngx,让我们开始实验:

  1. 请求 http://localhost/run,显示 1
  2. 修改模块 test.lua,把 1 改成 100
  3. 请求 http://localhost/unload?m=test,卸载 package.loaded 中的 test
  4. 请求 http://localhost/run,显示 100

由此可见,在模块内容被修改后,我们没有 reload 进程,只是通过卸载 package.loaded 中对应的模块,就实现了代码热更新。

看起来实现代码热更新非常简单。打住!有例外,让我们修改一下 test 模块:

local ffi = require("ffi")

ffi.cdef[[
struct test { int v; };
]]

local _M = {}

function _M.run()
    local test = ffi.new("struct test", {1})

    return test.v
end

return _M

还是打印一个数字,只是用 ffi 实现的,让我们再来重复一下实验步骤,结果报错了:

attempt to redefine …

究其原因,是因为当我们通过 package.loaded 卸载模块的时候,如果用到了 ffi.cdef 之类的 ffi 操作,那么其中的 C 语言类型声明是无法卸载的。

好在我们可以通过条件判断来决定是否要执行 ffi.cdef 语句:

if not pcall(ffi.typeof, "struct test") then
    ffi.cdef[[
    struct test { int v; };
    ]]
end

说明:如果我们要修改原始定义的话,那么就只能 reload 了。好在这种情况不多。

最后,让我来说一说多进程的问题,在测试过程中,我只使用了一个进程,并且通过一个特定的 location 来实现卸载 package.loaded 中指定模块的功能,但是在实际情况中, worker_processes 多半是大于 1 的,也就说有多个 worker 进程,此时,如果再使用特定 location 来操作的话,你是无法确定到底是操作在哪个 worker 上的。

比较直观的解决方案是:

  1. 把需要动态加载的代码放在一个模块文件中,并标记版本号。
  2. 暴露一个 location,允许从外部写最新的版本号到共享内存字典。
  3. 通过 package.loaders 实现自定义的 loader,把它插在 package.loaders 第二个位置上(因为缺省情况下第一个位置是为 package.preload 准备的,第二个位置是为 package.path 准备的),这样在 require 的时候就可以按照自定义的逻辑加载模块:检查模块的版本号与共享内存字典中的最新版本号是否一致,如果不一致的话,则通过 loadstring 重新加载模块,并且缓存到 package.loaded 中去。

如此可以解决问题,但是不爽的是每个请求都要检查版本号。看看另一个方案:

  1. 在 init_worker 设置每个 worker 都通过 timer 定时扫描自己的共享内存队列。
  2. 暴露一个 location,允许从外部写模块名字到每一个 worker 的共享内存队列。
  3. 如果 timer 发现新数据,就说明有模块变化了,通过 package.loaded 卸载,再通过 require 重新加载模块,当然也可以自定义 loader,通过 loadstring 重新加载模块。

补充:如果自定义 loader 的话,那么在通过 loadstring 加载模块的时候,不一定非要从本地磁盘加载模块,思维发散一下,可以通过读取远程数据来加载。比如说有一百台服务器需要更新代码,那么可以把新代码发送到某个 redis 上,然后所有服务器通过请求 redis 拿到新代码,并把 loadstring 缓存到 package.loaded 中去,如此避免了部署的麻烦。

发表评论

电子邮件地址不会被公开。 必填项已用*标注