# 執行階段概念 `Nginx`處理一個請求，它的處理流程請參考下圖： 我們OpenResty做個測試，示例代碼如下： ~~~ location /mixed { set_by_lua $a 'ngx.log(ngx.ERR, "set_by_lua")'; rewrite_by_lua 'ngx.log(ngx.ERR, "rewrite_by_lua")'; access_by_lua 'ngx.log(ngx.ERR, "access_by_lua")'; header_filter_by_lua 'ngx.log(ngx.ERR, "header_filter_by_lua")'; body_filter_by_lua 'ngx.log(ngx.ERR, "body_filter_by_lua")'; log_by_lua 'ngx.log(ngx.ERR, "log_by_lua")'; content_by_lua 'ngx.log(ngx.ERR, "content_by_lua")'; } ~~~ 執行結果日志(截取了一下)： ~~~ set_by_lua rewrite_by_lua access_by_lua content_by_lua header_filter_by_lua body_filter_by_lua log_by_lua ~~~ 這幾個階段的存在，應該是openresty不同于其他多數web server編程的最明顯特征了。由于nginx把一個會話分成了很多階段，這樣第三方模塊就可以根據自己行為，掛載到不同階段進行處理達到目的。 這樣我們就可以根據我們的需要，在不同的階段直接完成大部分典型處理了。 - set_by_lua: 流程分之處理判斷變量初始化 - rewrite_by_lua: 轉發、重定向、緩存等功能(例如特定請求代理到外網) - access_by_lua: IP準入、接口權限等情況集中處理(例如配合iptable完成簡單防火墻) - content_by_lua: 內容生成 - header_filter_by_lua: 應答HTTP過濾處理(例如添加頭部信息) - body_filter_by_lua: 應答BODY過濾處理(例如完成應答內容統一成大寫) - log_by_lua: 回話完成后本地異步完成日志記錄(日志可以記錄在本地，還可以同步到其他機器) 實際上我們只使用其中一個階段content_by_lua，也可以完成所有的處理。但這樣做，會讓我們的代碼比較臃腫，越到后期越發難以維護。把我們的邏輯放在不同階段，分工明確，代碼獨立，后期發力可以有很多有意思的玩法。 列舉360企業版的一個例子： ~~~ # 明文協議版本 location /mixed { content_by_lua '...'; # 請求處理 } # 加密協議版本 location /mixed { access_by_lua '...'; # 請求加密解碼 content_by_lua '...'; # 請求處理，不需要關心通信協議 body_filter_by_lua '...'; # 應答加密編碼 } ~~~ 內容處理部分都是在content_by_lua階段完成，第一版本API接口開發都是基于明文。為了傳輸體積、安全等要求，我們設計了支持壓縮、加密的密文協議(上下行)，痛點就來了，我們要更改所有API的入口、出口么？ 最后我們是在access_by_lua完成密文協議解碼，body_filter_by_lua完成應答加密編碼。如此一來世界都寧靜了，我們沒有更改已實現功能的一行代碼，只是利用ngx-lua的階段處理特性，非常優雅的解決了這個問題。 前兩天看到春哥的微博，里面說到github的某個應用里面也使用了openresty做了一些東西。發現他們也是利用階段特性+lua腳本處理了很多用戶證書方面的東東。最終在性能、穩定性都十分讓人滿意。使用者選型很準，不愧是github的工程師。 不同的階段，有不同的處理行為，這是openresty的一大特色。學會他，適應他，會給你打開新的一扇門。這些東西不是openresty自身所創，而是nginx c module對外開放的處理階段。理解了他，也能更好的理解nginx的設計思維。