作者回复: 👍
作者回复: 1. OpenResty 的版本号是跟着它所使用的 Nginx 来确定的,比如 OpenResty 的 1.15.8.1,使用的 Nginx 版本号就是 1.15.8,最后的 1 是 OpenResty 自己的小版本号;
2. OpenResty 的版本号是往上增加的,不太清楚越来越小是怎么看出来的呢?
3. 热升级步骤和 nginx 一致;
4. 这里的外部程序是指:你需要一个 nginx 之外的进程给 nginx 本身发送信号量,nginx 才能升级;而 OpenResty 有了特权进程之后,可以自己给master 进程发送信号量;
5. 相当于其他 worker 进程都已经加载过这个模块,不用重复加载;一个模块只会被加载一次,不管有多少请求来访问,和阶段无关;
6. 二进制热升级是很少用到的功能,但 nginx 支持了热部署;修改配置文件是常用的功能,但却需要 reload 才能生效。没有把常用的功能做到极致,所以我觉得有些本末倒置。
作者回复: 没错,除了 njs,还有 PHP 嵌入 nginx 的尝试,这些语言的普及度和生态比 Lua 好很多。OpenResty 要加油
作者回复: 需要 reload
作者回复: body_filter_by_lua 执行多次是正常的,因为响应体可能是 chunked 返回的。所以,如果你要对响应体整体加密的话,就要改为一次性返回,而不是 chunked 模式。
作者回复: 感觉这个不用序列化存储,你可以在 access 阶段调用风控服务的 API 接口,把 request 内容传过去,等风控返回后,根据结果在决定是发送到上游,还是拒绝。
你可以看下本章节 OpenResty 11 个 `*_by_lua` 指令的图片。
作者回复: 最好不要怎么做,这样无法和开源的主线保持一致,而且不能保证所有功能是正常的。最好的方法是给官方提交 PR,合并到主线去。
作者回复: 我的意思是配置文件的修改是一个更频繁的操作,而二进制热升级并不频繁。应该优先实现前者的热更新。
作者回复: 是的,多谢指正
作者回复: OpenResty 可以无痛的替换 nginx,同时提供了 Lua API 来做动态的控制,这个是它最大的优势。nginx unit 是为了微服务出的产品,两个感觉不在一个层面上。
作者回复: 保留旧的 master 进程是为了方便回滚。旧的 worker 进程是不保留的。
作者回复: 你想实现类似 cloudflare 的 Keyless 功能?不在 Nginx 中配置的话,就要增加代码逻辑,并在远端服务器配置,不然 https 握手就失败了。
作者回复: 多谢指正
作者回复: 至少方向是对的
作者回复: 果然,看来是官网链接出问题了。你可以谷歌搜索标题找下其他地方的资源。
作者回复: 百花齐放