动态插件
之前已经拆解细点逐个介绍了 tcp 、http 代理相关核心点，现在介绍一个让 api gateway 变得很灵活的功能实现： 动态插件。
由于 lua 的动态语言特点，我们可以比较方便做到动态插件机制。
首先我们来了解这一切的基石：lua 模块加载机制。
lua 模块加载机制
一个模块是什么样？
例如： xxxmodule.lua 文件内容
local module = {} -- 注意不要使用全局变量，会造成变量污染，导致无法卸载模块
-- 定义一个函数
function module.func1()
io.write("这是一个公有函数！\n")
end
return module如何加载模块？
Lua提供了一个名为require的函数用来加载模块。要加载一个模块，只需要简单地调用就可以了。例如：
local a = require("xxxmodule")
a.func1() -- "这是一个公有函数！\n"到底是怎么工作的呢？
require 函数会在模块path列表搜索模块，openresty可以指定如下两种：
lua 库： lua_package_path "./?.lua;/usr/local/openresty/luajit/share/luajit-2.1.0-beta3/?.lua;";
c 库： lua_package_cpath "./?.so;/usr/local/lib/lua/5.1/?.so;";
找到模块文件之后，就会解析执行整个文件的内容（类似函数 loadstring），由于后是return 模块变量，我们就可以使用这个变量的函数等等一切了
如果开启了 lua_code_cache on， require 函数会将第二步拿到的变量存在 package.loaded 这个table 中，达到缓存效果
那么如何卸载呢？
非常简单，只需一句：
package.loaded['xxxmodule'] = nil所以基于lua的模块管理，我们就可以非常容易实现插件模块的管理
lua severless function simple demo
所以我们可以基于这样的动态机制，实现 lua severless function 或者动态插件机制，示例如下：
http {
default_type application/json;
lua_code_cache on;
lua_package_path "$prefix/deps/share/lua/5.1/?.lua;$prefix/deps/share/lua/5.1/?/init.lua;$prefix/src/?.lua;$prefix/src/?/init.lua;;./?.lua;/usr/local/openresty/luajit/share/luajit-2.1.0-beta3/?.lua;/usr/local/share/lua/5.1/?.lua;/usr/local/share/lua/5.1/?/init.lua;/usr/local/openresty/luajit/share/lua/5.1/?.lua;/usr/local/openresty/luajit/share/lua/5.1/?/init.lua;";
lua_package_cpath "$prefix/deps/lib64/lua/5.1/?.so;$prefix/deps/lib/lua/5.1/?.so;;./?.so;/usr/local/lib/lua/5.1/?.so;/usr/local/openresty/luajit/lib/lua/5.1/?.so;/usr/local/lib/lua/5.1/loadall.so;";
# 简单模拟模块
init_by_lua_block {
MockPackages = {}
}
server {
listen 8222;
server_name localhost;
location /add {
# 比如替换为 request body 去做模块创建，这里为了简单就用写死的代码来模拟
# 内容为通过 loadstring 转换 lua code 字符串为函数
# 并将函数结果 当前时间存在全局变量中
access_by_lua_block {
local lua_src = [[
ngx.update_time()
return tostring(ngx.now())
]]
local f, e = loadstring(lua_src, "module xxxmodule")
MockPackages['xxxmodule'] = f()
ngx.say('add function success')
}
}
location /run {
# 这里获取缓存结果并输出出来
access_by_lua_block {
if MockPackages['xxxmodule'] then
ngx.say(MockPackages['xxxmodule'])
else
ngx.say('no function')
end
}
}
}
}启动并测试
mkdir -p logs && /usr/bin/openresty -p ./ -c nginx.conf -g 'daemon off;'
call http://127.0.0.1:8222/run return no function
call http://127.0.0.1:8222/add return add function success
call http://127.0.0.1:8222/run return 1624022896.703
call http://127.0.0.1:8222/add return add function success
call http://127.0.0.1:8222/run return 1624022918.674可以看到值已经被改变了
这种severless function demo的问题
管理以及定位问题
实际环境会有很多机器实例，对应的severless function 在哪几台机器哪几个nginx中的哪些worker 进程上加载，加载多久， 需要完整规划方案
资源隔离
所有的severless function 其实都是在worker内, 所以内存cpu等于是共享，一个特耗性能的代码必然影响其他
安全问题
由于多个函数会同在一个worker 进程，无论性能和资源都会收到相互影响 别人可以在其中轻松加入恶意代码
所以如果在公用的api gateway中，大家还是不要把它当成云计算中的 severless function 使用，只是当成一个 动态filter function 就好。
