nginx的模塊化體系結(jié)構(gòu)

nginx的內(nèi)部結(jié)構(gòu)是由核心部分和一系列的功能模塊所組成。這樣劃分是為了使得每個(gè)模塊的功能相對(duì)簡單，便于開發(fā)，同時(shí)也便于對(duì)系統(tǒng)進(jìn)行功能擴(kuò)展。為了便于描述，下文中我們將使用nginx core來稱呼nginx的核心功能部分。

nginx提供了web服務(wù)器的基礎(chǔ)功能，同時(shí)提供了web服務(wù)反向代理，email服務(wù)反向代理功能。nginx core實(shí)現(xiàn)了底層的通訊協(xié)議，為其他模塊和nginx進(jìn)程構(gòu)建了基本的運(yùn)行時(shí)環(huán)境，并且構(gòu)建了其他各模塊的協(xié)作基礎(chǔ)。除此之外，或者說大部分與協(xié)議相關(guān)的，或者應(yīng)用相關(guān)的功能都是在這些模塊中所實(shí)現(xiàn)的。

模塊概述

nginx將各功能模塊組織成一條鏈，當(dāng)有請(qǐng)求到達(dá)的時(shí)候，請(qǐng)求依次經(jīng)過這條鏈上的部分或者全部模塊，進(jìn)行處理。每個(gè)模塊實(shí)現(xiàn)特定的功能。例如，實(shí)現(xiàn)對(duì)請(qǐng)求解壓縮的模塊，實(shí)現(xiàn)SSI的模塊，實(shí)現(xiàn)與上游服務(wù)器進(jìn)行通訊的模塊，實(shí)現(xiàn)與FastCGI服務(wù)進(jìn)行通訊的模塊。

有兩個(gè)模塊比較特殊，他們居于nginx core和各功能模塊的中間。這兩個(gè)模塊就是http模塊和mail模塊。這2個(gè)模塊在nginx core之上實(shí)現(xiàn)了另外一層抽象，處理與HTTP協(xié)議和email相關(guān)協(xié)議(SMTP/POP3/IMAP)有關(guān)的事件，并且確保這些事件能被以正確的順序調(diào)用其他的一些功能模塊。

目前HTTP協(xié)議是被實(shí)現(xiàn)在http模塊中的，但是有可能將來被剝離到一個(gè)單獨(dú)的模塊中，以擴(kuò)展nginx支持SPDY協(xié)議。

模塊的分類

nginx的模塊根據(jù)其功能基本上可以分為以下幾種類型：

event module:搭建了獨(dú)立于操作系統(tǒng)的事件處理機(jī)制的框架，及提供了各具體事件的處理。包括ngx_events_module， ngx_event_core_module和ngx_epoll_module等。nginx具體使用何種事件處理模塊，這依賴于具體的操作系統(tǒng)和編譯選項(xiàng)。

phase handler:此類型的模塊也被直接稱為handler模塊。主要負(fù)責(zé)處理客戶端請(qǐng)求并產(chǎn)生待響應(yīng)內(nèi)容，比如ngx_http_static_module模塊，負(fù)責(zé)客戶端的靜態(tài)頁面請(qǐng)求處理并將對(duì)應(yīng)的磁盤文件準(zhǔn)備為響應(yīng)內(nèi)容輸出。

output filter:也稱為filter模塊，主要是負(fù)責(zé)對(duì)輸出的內(nèi)容進(jìn)行處理，可以對(duì)輸出進(jìn)行修改。例如，可以實(shí)現(xiàn)對(duì)輸出的所有html頁面增加預(yù)定義的footbar一類的工作，或者對(duì)輸出的圖片的URL進(jìn)行替換之類的工作。

upstream:upstream模塊實(shí)現(xiàn)反向代理的功能，將真正的請(qǐng)求轉(zhuǎn)發(fā)到后端服務(wù)器上，并從后端服務(wù)器上讀取響應(yīng)，發(fā)回客戶端。upstream模塊是一種特殊的handler，只不過響應(yīng)內(nèi)容不是真正由自己產(chǎn)生的，而是從后端服務(wù)器上讀取的。

load-balancer:負(fù)載均衡模塊，實(shí)現(xiàn)特定的算法，在眾多的后端服務(wù)器中，選擇一個(gè)服務(wù)器出來作為某個(gè)請(qǐng)求的轉(zhuǎn)發(fā)服務(wù)器。

nginx的請(qǐng)求處理

nginx使用一個(gè)多進(jìn)程模型來對(duì)外提供服務(wù)，其中一個(gè)master進(jìn)程，多個(gè)worker進(jìn)程。master進(jìn)程負(fù)責(zé)管理nginx本身和其他worker進(jìn)程。

所有實(shí)際上的業(yè)務(wù)處理邏輯都在worker進(jìn)程。worker進(jìn)程中有一個(gè)函數(shù)，執(zhí)行無限循環(huán)，不斷處理收到的來自客戶端的請(qǐng)求，并進(jìn)行處理，直到整個(gè)nginx服務(wù)被停止。

worker進(jìn)程中，ngx_worker_process_cycle()函數(shù)就是這個(gè)無限循環(huán)的處理函數(shù)。在這個(gè)函數(shù)中，一個(gè)請(qǐng)求的簡單處理流程如下：

操作系統(tǒng)提供的機(jī)制(例如epoll, kqueue等)產(chǎn)生相關(guān)的事件。

接收和處理這些事件，如是接受到數(shù)據(jù)，則產(chǎn)生更高層的request對(duì)象。

處理request的header和body。

產(chǎn)生響應(yīng)，并發(fā)送回客戶端。

完成request的處理。

重新初始化定時(shí)器及其他事件。

請(qǐng)求的處理流程

為了讓大家更好的了解nginx中請(qǐng)求處理過程，我們以HTTP Request為例，來做一下詳細(xì)地說明。

從nginx的內(nèi)部來看，一個(gè)HTTP Request的處理過程涉及到以下幾個(gè)階段。

初始化HTTP Request(讀取來自客戶端的數(shù)據(jù)，生成HTTP Request對(duì)象，該對(duì)象含有該請(qǐng)求所有的信息)。

處理請(qǐng)求頭。

處理請(qǐng)求體。

如果有的話，調(diào)用與此請(qǐng)求(URL或者Location)關(guān)聯(lián)的handler。

依次調(diào)用各phase handler進(jìn)行處理。

在這里，我們需要了解一下phase handler這個(gè)概念。phase字面的意思，就是階段。所以phase handlers也就好理解了，就是包含若干個(gè)處理階段的一些handler。

在每一個(gè)階段，包含有若干個(gè)handler，再處理到某個(gè)階段的時(shí)候，依次調(diào)用該階段的handler對(duì)HTTP Request進(jìn)行處理。

通常情況下，一個(gè)phase handler對(duì)這個(gè)request進(jìn)行處理，并產(chǎn)生一些輸出。通常phase handler是與定義在配置文件中的某個(gè)location相關(guān)聯(lián)的。

一個(gè)phase handler通常執(zhí)行以下幾項(xiàng)任務(wù)：

獲取location配置。

產(chǎn)生適當(dāng)?shù)捻憫?yīng)。

發(fā)送response header。

發(fā)送response body。

當(dāng)nginx讀取到一個(gè)HTTP Request的header的時(shí)候，nginx首先查找與這個(gè)請(qǐng)求關(guān)聯(lián)的虛擬主機(jī)的配置。如果找到了這個(gè)虛擬主機(jī)的配置，那么通常情況下，這個(gè)HTTP Request將會(huì)經(jīng)過以下幾個(gè)階段的處理(phase handlers)：

NGX_HTTP_POST_READ_PHASE:

讀取請(qǐng)求內(nèi)容階段

NGX_HTTP_SERVER_REWRITE_PHASE:

Server請(qǐng)求地址重寫階段

NGX_HTTP_FIND_CONFIG_PHASE:

配置查找階段:

NGX_HTTP_REWRITE_PHASE:

Location請(qǐng)求地址重寫階段

NGX_HTTP_POST_REWRITE_PHASE:

請(qǐng)求地址重寫提交階段

NGX_HTTP_PREACCESS_PHASE:

訪問權(quán)限檢查準(zhǔn)備階段

NGX_HTTP_ACCESS_PHASE:

訪問權(quán)限檢查階段

NGX_HTTP_POST_ACCESS_PHASE:

訪問權(quán)限檢查提交階段

NGX_HTTP_TRY_FILES_PHASE:

配置項(xiàng)try_files處理階段

NGX_HTTP_CONTENT_PHASE:

內(nèi)容產(chǎn)生階段

NGX_HTTP_LOG_PHASE:

日志模塊處理階段

在內(nèi)容產(chǎn)生階段，為了給一個(gè)request產(chǎn)生正確的響應(yīng)，nginx必須把這個(gè)request交給一個(gè)合適的content handler去處理。如果這個(gè)request對(duì)應(yīng)的location在配置文件中被明確指定了一個(gè)content handler，那么nginx就可以通過對(duì)location的匹配，直接找到這個(gè)對(duì)應(yīng)的handler，并把這個(gè)request交給這個(gè)content handler去處理。這樣的配置指令包括像，perl，flv，proxy_pass，mp4等。

如果一個(gè)request對(duì)應(yīng)的location并沒有直接有配置的content handler，那么nginx依次嘗試:

如果一個(gè)location里面有配置 random_index on，那么隨機(jī)選擇一個(gè)文件，發(fā)送給客戶端。

如果一個(gè)location里面有配置 index指令，那么發(fā)送index指令指明的文件，給客戶端。

如果一個(gè)location里面有配置 autoindex on，那么就發(fā)送請(qǐng)求地址對(duì)應(yīng)的服務(wù)端路徑下的文件列表給客戶端。

如果這個(gè)request對(duì)應(yīng)的location上有設(shè)置gzip_static on，那么就查找是否有對(duì)應(yīng)的.gz文件存在，有的話，就發(fā)送這個(gè)給客戶端(客戶端支持gzip的情況下)。

請(qǐng)求的URI如果對(duì)應(yīng)一個(gè)靜態(tài)文件，static module就發(fā)送靜態(tài)文件的內(nèi)容到客戶端。

內(nèi)容產(chǎn)生階段完成以后，生成的輸出會(huì)被傳遞到filter模塊去進(jìn)行處理。filter模塊也是與location相關(guān)的。所有的fiter模塊都被組織成一條鏈。輸出會(huì)依次穿越所有的filter，直到有一個(gè)filter模塊的返回值表明已經(jīng)處理完成。

這里列舉幾個(gè)常見的filter模塊，例如：

server-side includes。

XSLT filtering。

圖像縮放之類的。

gzip壓縮。

在所有的filter中，有幾個(gè)filter模塊需要關(guān)注一下。按照調(diào)用的順序依次說明如下：

write:寫輸出到客戶端，實(shí)際上是寫到連接對(duì)應(yīng)的socket上。

postpone:這個(gè)filter是負(fù)責(zé)subrequest的，也就是子請(qǐng)求的。

copy:將一些需要復(fù)制的buf(文件或者內(nèi)存)重新復(fù)制一份然后交給剩余的body filter處理。

以上就是關(guān)于“Nginx模塊化概述”的介紹，大家如果想了解更多相關(guān)知識(shí)，不妨來關(guān)注一下動(dòng)力節(jié)點(diǎn)的Java視頻教程，里面的內(nèi)容通俗易懂，適合沒有基礎(chǔ)的小伙伴學(xué)習(xí)，希望對(duì)大家能夠有所幫助。