鍍金池/ 教程/ Java/ 執(zhí)行階段概念
定時任務
函數(shù)的參數(shù)
超時
一個 openresty 內(nèi)存“泄漏”問題
獲取 uri 參數(shù)
局部變量
sleep
灰度發(fā)布
TIME_WAIT
代碼覆蓋率
連接池
CentOS 平臺安裝
稀疏數(shù)組
如何只啟動一個 timer 工作?
變量的共享范圍
break,return 關(guān)鍵字
Nginx
SQL 注入
如何引用第三方 resty 庫
不同階段共享變量
獲取請求 body
動態(tài)生成的 lua-resty-redis 模塊方法
動態(tài)加載證書和 OCSP stapling
repeat 控制結(jié)構(gòu)
編碼為 array 還是 object
Nginx 靜態(tài)文件服務
執(zhí)行階段概念
Lua 函數(shù)
日期時間函數(shù)
健康監(jiān)測
與其他 location 配合
for 控制結(jié)構(gòu)
函數(shù)定義
HTTPS 時代
點號與冒號操作符的區(qū)別
String 庫
文件操作
OpenResty 最佳實踐
<code>ngx.shared.DICT</code> 非隊列性質(zhì)
使用動態(tài) DNS 來完成 HTTP 請求
代碼規(guī)范
什么是 JIT?
Windows 平臺安裝
正確的記錄日志
LuaNginxModule
不用標準庫
C10K 編程
控制結(jié)構(gòu)
請求中斷后的處理
Lua 環(huán)境搭建
Test::Nginx 能指定現(xiàn)成的 nginx.conf,而不是自動生成一個嗎
Lua 基礎(chǔ)數(shù)據(jù)類型
動態(tài)限速
PostgresNginxModule
簡單API Server框架
API 測試
location 匹配規(guī)則
虛變量
單元測試
防止 SQL 注入
select + set_keepalive 組合操作引起的數(shù)據(jù)讀寫錯誤
阻塞操作
全動態(tài)函數(shù)調(diào)用
Web 服務
典型應用場景
Nginx 新手起步
TLS session resumption
輸出響應體
調(diào)用代碼前先定義函數(shù)
module 是邪惡的
怎樣理解 cosocket
模塊
Socket 編程發(fā)展
如何對 Nginx Lua module 添加新 api
如何在后臺開啟輕量級線程完成定時任務?
如何定位問題
table 庫
json 解析的異常捕獲
如何安裝火焰圖生成工具
lua 中如何 continue
if 是邪惡的
為什么我們的域名不能被解析
抵制使用 module() 定義模塊
測試
body 在 location 中的傳遞
Lua 入門
子查詢
pipeline 壓縮請求數(shù)量
如何發(fā)起新 HTTP 請求
Lua 簡介
緩存失效風暴
Ubuntu 平臺安裝
日志輸出
緩存
Lua 面向?qū)ο缶幊?/span>
Nginx 陷阱和常見錯誤
Redis 接口的二次封裝(發(fā)布訂閱)
日志
訪問有授權(quán)驗證的 Redis
正則表達式
lock
熱裝載代碼
調(diào)用 FFI 出現(xiàn) &quot;table overflow&quot;
數(shù)據(jù)合法性檢測
禁止某些終端訪問
控制結(jié)構(gòu) if-else
調(diào)試
與 Docker 使用的網(wǎng)絡(luò)瓶頸
PostgresNginxModule 模塊的調(diào)用方式
用 do-end 整理你的代碼
FFI
什么時候使用
簡介
環(huán)境搭建
Mac OS X 平臺安裝
火焰圖
負載均衡
while 型控制結(jié)構(gòu)
如何定位 openresty 崩潰 bug
使用 Nginx 內(nèi)置綁定變量
判斷數(shù)組大小
請求返回后繼續(xù)執(zhí)行
Redis 接口的二次封裝
KeepAlive
反向代理
協(xié)議無痛升級
數(shù)學庫
元表
Vanilla 介紹
HelloWorld
LuaCjsonLibrary
持續(xù)集成
代碼靜態(tài)分析
網(wǎng)上有大量對 Lua 調(diào)優(yōu)的推薦,我們應該如何看待?
script 壓縮復雜請求
非空判斷
性能測試
函數(shù)返回值
API 的設(shè)計
kong 介紹
表達式
不支持事務
LuaRestyDNSLibrary 簡介

執(zhí)行階段概念

OpenResty 處理一個請求,它的處理流程請參考下圖(從 Request start 開始):

http://wiki.jikexueyuan.com/project/openresty/images/openresty_phases.png" alt="openresty_phases" />

我們在這里做個測試,示例代碼如下:

location /mixed {
    set_by_lua_block $a {
        ngx.log(ngx.ERR, "set_by_lua*")
    }
    rewrite_by_lua_block {
        ngx.log(ngx.ERR, "rewrite_by_lua*")
    }
    access_by_lua_block {
        ngx.log(ngx.ERR, "access_by_lua*")
    }
    content_by_lua_block {
        ngx.log(ngx.ERR, "content_by_lua*")
    }
    header_filter_by_lua_block {
        ngx.log(ngx.ERR, "header_filter_by_lua*")
    }
    body_filter_by_lua_block {
        ngx.log(ngx.ERR, "body_filter_by_lua*")
    }
    log_by_lua_block {
        ngx.log(ngx.ERR, "log_by_lua*")
    }
}

執(zhí)行結(jié)果日志(截取了一下):

set_by_lua*
rewrite_by_lua*
access_by_lua*
content_by_lua*
header_filter_by_lua*
body_filter_by_lua*
log_by_lua*

這幾個階段的存在,應該是 OpenResty 不同于其他多數(shù) Web 平臺編程的最明顯特征了。由于 Nginx 把一個請求分成了很多階段,這樣第三方模塊就可以根據(jù)自己行為,掛載到不同階段進行處理達到目的。OpenResty 也應用了同樣的特性。所不同的是,OpenResty 掛載的是我們編寫的 Lua 代碼。

這樣我們就可以根據(jù)我們的需要,在不同的階段直接完成大部分典型處理了。

  • set_by_lua*: 流程分支處理判斷變量初始化
  • rewrite_by_lua*: 轉(zhuǎn)發(fā)、重定向、緩存等功能(例如特定請求代理到外網(wǎng))
  • access_by_lua*: IP 準入、接口權(quán)限等情況集中處理(例如配合 iptable 完成簡單防火墻)
  • content_by_lua*: 內(nèi)容生成
  • header_filter_by_lua*: 響應頭部過濾處理(例如添加頭部信息)
  • body_filter_by_lua*: 響應體過濾處理(例如完成應答內(nèi)容統(tǒng)一成大寫)
  • log_by_lua*: 會話完成后本地異步完成日志記錄(日志可以記錄在本地,還可以同步到其他機器)

實際上我們只使用其中一個階段 content_by_lua*,也可以完成所有的處理。但這樣做,會讓我們的代碼比較臃腫,越到后期越發(fā)難以維護。把我們的邏輯放在不同階段,分工明確,代碼獨立,后期發(fā)力可以有很多有意思的玩法。

舉一個例子,如果在最開始的開發(fā)中,請求體和響應體都是通過 HTTP 明文傳輸,后面需要使用 aes 加密,利用不同的執(zhí)行階段,我們可以非常簡單的實現(xiàn):

# 明文協(xié)議版本
location /mixed {
    content_by_lua_file ...;       # 請求處理
}

# 加密協(xié)議版本
location /mixed {
    access_by_lua_file ...;        # 請求加密解碼
    content_by_lua_file ...;       # 請求處理,不需要關(guān)心通信協(xié)議
    body_filter_by_lua_file ...;   # 應答加密編碼
}

內(nèi)容處理部分都是在 content_by_lua* 階段完成,第一版本 API 接口開發(fā)都是基于明文。為了傳輸體積、安全等要求,我們設(shè)計了支持壓縮、加密的密文協(xié)議(上下行),痛點就來了,我們要更改所有 API 的入口、出口么?

最后我們是在 access_by_lua* 完成密文協(xié)議解碼,body_filter_by_lua* 完成應答加密編碼。如此一來世界都寧靜了,我們沒有更改已實現(xiàn)功能的一行代碼,只是利用 OpenResty 的階段處理特性,非常優(yōu)雅的解決了這個問題。

不同的階段,有不同的處理行為,這是 OpenResty 的一大特色。學會它,適應它,會給你打開新的一扇門。這些東西不是 OpenResty 自身所創(chuàng),而是 Nginx module 對外開放的處理階段。理解了他,也能更好的理解 Nginx 的設(shè)計思維。

上一篇:LuaCjsonLibrary下一篇:不支持事務