OpenResty实战系列 | 执行流程与阶段详解-51CTO.COM

场景

我们先定义一个location块级指令phase_echo来处理客户端发过来请求URI处理。

location /phase_echo {
    set $name "Tinywan";
    echo $name;
    set $name "开源技术小栈";
    echo $name;
    set $name "Tinywan 开源技术小栈";
    echo $name;
}

请求访问输出结果：

PS C:\Users\Tinywan\Desktop> curl -i http://openresty.tinywan.com/phase_echo
HTTP/1.1 200 OK
Server: openresty/1.17.8.2
Date: Sun, 14 Jul 2024 00:31:18 GMT
Content-Type: application/octet-stream
Transfer-Encoding: chunked
Connection: keep-alive

Tinywan 开源技术小栈
Tinywan 开源技术小栈
Tinywan 开源技术小栈

为什么输出全部是Tinywan 开源技术小栈。也就是最后一个设置的变量值呢？前面设置的怎么都没生效吗？

这是因为Nginx处理每一个用户请求时，都是按照若干个不同阶段依次处理的，而不是根据配置文件上的顺序。以上配置涉及到了两个阶段 rewrite和content阶段。

set属于rewrite阶段
echo属于content阶段

而实际执行执行是 rewrite阶段的指令在 content阶段指令之前执行。实际的执行顺序应当是以下这样子的。

set $name "Tinywan";
set $name "开源技术小栈";
set $name "Tinywan 开源技术小栈";
echo $name;
echo $name;
echo $name;

所以这就是为什么最终会输出Tinywan 开源技术小栈。带着以上配置文件中执行的指令，让我们进入Nginx执行流程与阶段详解。

Nginx执行阶段

Nginx处理请求的过程一共划分为11个阶段，按照执行顺序依次是post-read、server-rewrite、find-config、rewrite、post-rewrite、 preaccess、access、post-access、try-files、content、log。

所以整个请求的过程，是按照不同的阶段执行的，在某个阶段执行完该阶段的指令之后，再进行下一个阶段的指令执行。

执行阶段示例

图片

post-read：读取请求内容阶段，nginx读取并解析完请求头之后就立即开始运行。例如模块 ngx_realip 就在 post-read 阶段注册了处理程序。它的功能是迫使 Nginx 认为当前请求的来源地址是指定的某一个请求头的值。
server-rewrite：server请求地址重写阶段，当ngx_rewrite模块的set配置指令直接书写在server配置块中时，基本上都是运行在server-rewrite阶段。
find-config：配置查找阶段，这个阶段并不支持Nginx模块注册处理程序，而是由Nginx核心来完成当前请求与location配置块之间的配对工作。
rewrite：location请求地址重写阶段，当ngx_rewrite指令用于location中，就是再这个阶段运行的。另外ngx_set_misc(设置md5、encode_base64等)模块的指令，还有ngx_lua模块的set_by_lua指令和rewrite_by_lua指令也在此阶段。
post-rewrite：请求地址重写提交阶段，当nginx完成rewrite阶段所要求的内部跳转动作，如果rewrite阶段有这个要求的话。
preaccess：访问权限检查准备阶段，ngx_limit_req和ngx_limit_zone在这个阶段运行，ngx_limit_req可以控制请求的访问频率，ngx_limit_zone可以控制访问的并发度；
access：访问权限检查阶段，标准模块ngx_access、第三方模块ngx_auth_request以及第三方模块ngx_lua的access_by_lua 指令就运行在这个阶段。配置指令多是执行访问控制相关的任务，如检查用户的访问权限，检查用户的来源IP是否合法。
post-access：访问权限检查提交阶段；主要用于配合access阶段实现标准ngx_http_core模块提供的配置指令satisfy的功能。satisfy all(与关系)，satisfy any(或关系)
try-files：配置项try_files处理阶段；专门用于实现标准配置指令try_files的功能，如果前N-1个参数所对应的文件系统对象都不存在，try-files 阶段就会立即发起内部跳转到最后一个参数(即第 N 个参数)所指定的URI.
content：内容产生阶段，是所有请求处理阶段中最为重要的阶段，因为这个阶段的指令通常是用来生成HTTP响应内容并输出 HTTP 响应的使命.
log：日志模块处理阶段，记录日志

OpenResty 的运行机制

图片

图片来源：https://yxudong.github.io。

OpenResty 执行阶段

OpenResty发起一个请求时，会有相应的执行流程，Nginx与Lua编写脚本的基本构建块是指令执行顺序的。

从图中可知OpenResty 处理请求大致分为4个大阶段，11个小阶段。

四个大阶段

初始化阶段（Initialization Phase） master进程启动预加载／生成worker进程预加载
重写、转发、访问阶段（Rewrite / Access Phase） url转发，权限判断
内容处理/生成阶段（Content Phase）内容生成
日志阶段（Log Phase）日志记录

七个小阶段

init_by_lua_file：master-initing 阶段，初始化全局配置或模块
init_worker_by_lua_file：worker-initing 阶段，初始化进程专用功能
ssl_certificate_by_lua_file：ssl 阶段，在握手时设置安全证书
set_by_lua_file：rewrite 阶段，改写 Nginx 变量
rewrite_by_lua_file：rewrite 阶段，改写 URI ，实现跳转或重定向
access_by_lua_file：access 阶段，访问控制或限速
content_by_lua_file：content 阶段，产生响应内容
balancer_by_lua_file：content 阶段，反向代理时选择后端服务器
header_filter_by_lua_file：filter 阶段，加工处理响应头
body_filter_by_lua_file：filter 阶段，加工处理响应体
log_by_lua_file：log 阶段，记录日志或其他的收尾工作

这些指令通常有三种形式

xxx_by_lua：执行字符串形式的 Lua 代码：
xxx_by_lua_block：功能相同，但指令后是｛．．．｝的 Lua 代码块
xxx_by_lua_file：功能相同，但执行磁盘上的 Lua 源码文件。

这边推荐使用 xxx_by_lua_file，它彻底分离了配置文件与业务代码，让两者可以独立部署，而且文件形式也让我们更容易以模块的方式管理组织 Lua 程序。

OpenResty 执行阶段和 Nginx 的对照

图片

图片来源：https://blog.51cto.com/lisea/2425794。

server {
    listen 80;
    server_name openresty.tinywan.com;

    location /run_phase {
        set_by_lua_block $a {
            ngx.log(ngx.ERR, "Tinywan is set_by_lua_block phase")
        }

        rewrite_by_lua_block {
            ngx.log(ngx.ERR, "Tinywan is rewrite_by_lua_block phase")
        }

        access_by_lua_block {
            ngx.log(ngx.ERR, "Tinywan is access_by_lua_block phase")
        }

        content_by_lua_block {
            ngx.log(ngx.ERR, "Tinywan is content_by_lua_block phase")
        }

        header_filter_by_lua_block {
            ngx.log(ngx.ERR, "Tinywan is header_filter_by_lua_block phase")
        }

        body_filter_by_lua_block {
            ngx.log(ngx.ERR, "Tinywan is body_filter_by_lua_block phase")
        }

        log_by_lua_block {
            ngx.log(ngx.ERR, "Tinywan is log_by_lua_block phase")
        }
    }
}

执行请求访问：

curl -i http://openresty.tinywan.com/run_phase

查看错误日志文件内容：

2024/07/13 12:38:43 [error] 7#7: *2 [lua] set_by_lua:2: Tinywan is set_by_lua_block phase, client: 172.18.0.1, server: openresty.tinywan.com, request: "GET /run_phase HTTP/1.1", host: "openresty.tinywan.com"
2024/07/13 12:38:43 [error] 7#7: *2 [lua] rewrite_by_lua(openresty.tinywan.com.conf:18):2: Tinywan is rewrite_by_lua_block phase, client: 172.18.0.1, server: openresty.tinywan.com, request: "GET /run_phase HTTP/1.1", host: "openresty.tinywan.com"
2024/07/13 12:38:43 [error] 7#7: *2 [lua] access_by_lua(openresty.tinywan.com.conf:22):2: Tinywan is access_by_lua_block phase, client: 172.18.0.1, server: openresty.tinywan.com, request: "GET /run_phase HTTP/1.1", host: "openresty.tinywan.com"
2024/07/13 12:38:43 [error] 7#7: *2 [lua] content_by_lua(openresty.tinywan.com.conf:26):2: Tinywan is content_by_lua_block phase, client: 172.18.0.1, server: openresty.tinywan.com, request: "GET /run_phase HTTP/1.1", host: "openresty.tinywan.com"
2024/07/13 12:38:43 [error] 7#7: *2 [lua] header_filter_by_lua:2: Tinywan is header_filter_by_lua_block phase, client: 172.18.0.1, server: openresty.tinywan.com, request: "GET /run_phase HTTP/1.1", host: "openresty.tinywan.com"
2024/07/13 12:38:43 [error] 7#7: *2 [lua] body_filter_by_lua:2: Tinywan is body_filter_by_lua_block phase, client: 172.18.0.1, server: openresty.tinywan.com, request: "GET /run_phase HTTP/1.1", host: "openresty.tinywan.com"
2024/07/13 12:38:43 [error] 7#7: *2 [lua] log_by_lua(openresty.tinywan.com.conf:38):2: Tinywan is log_by_lua_block phase while logging request, client: 172.18.0.1, server: openresty.tinywan.com, request: "GET /run_phase HTTP/1.1", host: "openresty.tinywan.com"

通过日志文件记录可以看到执行是按照阶段顺序进行输出。