## 场景 我们先定义一个`location`块级指令`phase_echo`来处理客户端发过来请求URI处理 ``` location /phase_echo { set $name "Tinywan"; echo $name; set $name "开源技术小栈"; echo $name; set $name "Tinywan 开源技术小栈"; echo $name; } ``` 请求访问输出结果 ```ts 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。 所以整个请求的过程，是按照不同的阶段执行的，在某个阶段执行完该阶段的指令之后，再进行下一个阶段的指令执行。 > 执行阶段示例  1. **post-read**：读取请求内容阶段，nginx读取并解析完请求头之后就立即开始运行。例如模块 `ngx_realip` 就在 `post-read` 阶段注册了处理程序。它的功能是迫使 Nginx 认为当前请求的来源地址是指定的某一个请求头的值。 2. **server-rewrite**：`server`请求地址重写阶段，当`ngx_rewrite`模块的`set`配置指令直接书写在`server`配置块中时，基本上都是运行在`server-rewrite`阶段。 3. **find-config**：配置查找阶段，这个阶段并不支持Nginx模块注册处理程序，而是由Nginx核心来完成当前请求与location配置块之间的配对工作。 4. **rewrite**：`location`请求地址重写阶段，当`ngx_rewrite`指令用于`location`中，就是再这个阶段运行的。另外`ngx_set_misc(设置md5、encode_base64等)`模块的指令，还有`ngx_lua`模块的`set_by_lua`指令和`rewrite_by_lua`指令也在此阶段。 5. **post-rewrite**：请求地址重写提交阶段，当nginx完成rewrite阶段所要求的内部跳转动作，如果rewrite阶段有这个要求的话。 6. **preaccess**：访问权限检查准备阶段，`ngx_limit_req`和`ngx_limit_zone`在这个阶段运行，`ngx_limit_req`可以控制请求的访问频率，`ngx_limit_zone`可以控制访问的并发度； 7. **access**：访问权限检查阶段，标准模块`ngx_access`、第三方模块`ngx_auth_request`以及第三方模块`ngx_lua`的`access_by_lua` 指令就运行在这个阶段。配置指令多是执行访问控制相关的任务，如检查用户的访问权限，检查用户的来源IP是否合法。 8. **post-access**：访问权限检查提交阶段；主要用于配合`access`阶段实现标准`ngx_http_core`模块提供的配置指令`satisfy`的功能。 `satisfy all`(与关系)，`satisfy any`(或关系) 9. **try-files**：配置项`try_files`处理阶段；专门用于实现标准配置指令`try_files`的功能，如果前`N-1`个参数所对应的文件系统对象都不存在，`try-files` 阶段就会立即发起`内部跳转`到最后一个参数(即第 N 个参数)所指定的URI. 10. **content**：内容产生阶段，是所有请求处理阶段中最为重要的阶段，因为这个阶段的指令通常是用来生成HTTP响应内容并输出 HTTP 响应的使命. 11. **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" ``` 通过日志文件记录可以看到执行是按照阶段顺序进行输出