nginx實際把請求處理流程劃分為了11個階段，這樣劃分的原因是將請求的執行邏輯細分，各階段按照處理時機定義了清晰的執行語義，開發者可以很容易分辨自己需要開發的模組應該定義在什麼階段，下面介紹一下各階段:
接收完請求頭之後的第乙個階段，它位於uri重寫之前，實際上很少有模組會註冊在該階段，預設的情況下，該階段被跳過；
server級別的uri重寫階段，也就是該階段執行處於server塊內，location塊外的重寫指令，前面的章節已經說明在讀取請求頭的過程中nginx會根據host及埠找到對應的虛擬主機配置；
尋找location配置階段，該階段使用重寫之後的uri來查詢對應的location，值得注意的是該階段可能會被執行多次，因為也可能有location級別的重寫指令；
location級別的uri重寫階段，該階段執行location基本的重寫指令，也可能會被執行多次；
location級別重寫的後一階段，用來檢查上階段是否有uri重寫，並根據結果跳轉到合適的階段；
訪問許可權控制的前一階段，該階段在許可權控制階段之前，一般也用於訪問控制，比如限制訪問頻率，鏈結數等；
訪問許可權控制階段，比如基於ip黑白名單的許可權控制，基於使用者名稱密碼的許可權控制等；
訪問許可權控制的後一階段，該階段根據許可權控制階段的執行結果進行相應處理；
try_files指令的處理階段，如果沒有配置try_files指令，則該階段被跳過；
內容生成階段，該階段產生響應，併發送到客戶端；
日誌記錄階段，該階段記錄訪問日誌；
Dockerfile多階段構建
多階段構建 之前的做法 在docker17.05版本之前，構建docker映象，通常採用兩種方式 1.全部放入乙個dockerfile 一種方式是將所有的構建過程全都包含在乙個dockerfile中，包括專案及其依賴庫的編譯 測試 打包流程，這裡會帶來的一些問題 映象層次多，映象體積較大，部署時間變...
spark多階段任務
import org.apache.spark.rdd.rdd val lines rdd string sc.parallelize list a b c a b d 3 切分壓平 val words rdd string lines.flatmap split 將單詞和1組合 val worda...
Docker多階段構建
在 docker 17.05 版本之前，我們構建 docker 映象時，通常會採用兩種方式 一種方式是將所有的構建過程編包含在乙個 dockerfile 中，包括專案及其依賴庫的編譯 測試 打包等流程，這裡可能會帶來的一些問題 package main import fmt func main 編寫...