摘要：反向代理反向代理反向代理負載均衡鑒權限流等邏輯架構在邏輯上分為入口層，模塊化的功能處理層，系統(tǒng)調(diào)用層。多個共同監(jiān)聽事件并處理，反向代理會把請求轉發(fā)給后端服務。

本文將深入剖析nginx的架構。

第一部分介紹nginx現(xiàn)有框架，用典型的4+1視圖闡述，包括邏輯架構，開發(fā)架構，運行架構，物理架構，功能用例，nginx為單機服務，不考慮物理架構。其中功能用例概述nginx功能；邏輯架構主要介紹nginx高度模塊化中各個模塊的分層和依賴關系；開發(fā)架構主要描述nginx的代碼結構和代碼內(nèi)容簡介；重點是運行架構，nginx一主多從的進程模型架構和通信，高并發(fā)進程和IO并發(fā)的選型等。

第二部分對比nginx運行架構和其他開源運行架構，總結nginx為何要這樣選型；介紹nginx邏輯架構中的優(yōu)點。

本文適合閱讀對象：1）已經(jīng)看過nginx代碼，本文幫你高度抽象總結了nginx的架構和與我自己設計相比較，nginx哪里設計的優(yōu)點，試著從架構層來重新看下代碼；2）研究各種系統(tǒng)架構的人，本文從統(tǒng)一的架構視圖介紹，無需知道nginx的代碼細節(jié)，列出了與其他架構比，nginx架構的亮點。3）還未看過nginx的代碼，關注第二章，可以看四個視圖忽略對特性的分析和架構的思考，幫助了解nginx有什么功能、如何組織代碼、如何運行。

nginx最核心的功能是web服務器和反向代理服務器，web服務器完成對 http請求協(xié)議的解析 和 以http協(xié)議格式響應請求、緩存、日志處理這些 基本web服務器 功能，反向代理服務器完成對請求的轉發(fā)、負載均衡、鑒權、限流、緩存、日志處理等代理常用功能。nginx在這方面提供了豐富的功能，包括對http2,ssl等等的支持。除了http外，nginx還支持mail服務和普通的tcp,udp協(xié)議的反向代理功能。一下列出了常用功能，詳細所有功能見參考1
### http服務器/反向代理服務器

靜態(tài)文件，fastcgi,uwsgi,scgi,memcached 服務

緩存

負載均衡

SSL/TLS

HTTP2

鑒權/限流

虛擬servers

功能用例舉例：web服務器和反向代理服務器的功能（第一個locatiion為服務器，后面是反向代理）。在nginx中配置如圖配置，啟動nginx加載配置后，發(fā)起http請求，獲取服務器響應。

server{
    listen 8091;
    root /home/xiaoju/yyl/;
    index index.php;
    location /
    {
        root html;
        index index.html index.htm;
    }
    location  ~ .php$
    {
        rewrite /(.*)$ /index.php/$1 break;
        fastcgi_index index.php;
        fastcgi_pass 127.0.0.1:9000;
        include fastcgi.conf;
    }
}

curl localhost:8091 -v
* About to connect() to localhost port 8091 (#0)
*   Trying 127.0.0.1... connected
* Connected to localhost (127.0.0.1) port 8091 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.27.1 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Host: localhost:8091
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx/1.13.11
< Date: Sun, 02 Dec 2018 06:29:01 GMT
< Content-Type: text/html; charset=utf-8
< Content-Length: 612
< Last-Modified: Tue, 10 Apr 2018 15:32:02 GMT
< Connection: keep-alive
< ETag: "5accd8f2-264"
< Accept-Ranges: bytes
<




...

* Connection #0 to host localhost left intact
* Closing connection #0

mail反向代理

SSL; STARTTLS/STLS

SSL/TLS, 負載均衡, 鑒權/限流等

nginx在邏輯上分為入口層，模塊化的功能處理層，系統(tǒng)調(diào)用層。入口調(diào)用配置模塊和核心模塊，各核心模塊分別調(diào)用各自功能模塊，系統(tǒng)調(diào)用層封裝了各個操作系統(tǒng)的功能被功能處理層使用。邏輯架構最明顯主要的特征就是高度模塊化，所有功能都是模塊，每個模塊都統(tǒng)一結構，下面先看下這個統(tǒng)一結構，然后分別介紹各個模塊。

nginx除了main等少量代碼，其他全都是模塊，所有模塊都是Ngx_module_t的抽象，只有初始化，退出，對配置項的處理;每個模塊內(nèi)部也都有自己模塊ngx_xx_module_t的抽象；配置也高度抽象統(tǒng)一的結構ngx_command_t。如圖：

核心流程會只會調(diào)用核心模塊和配置模塊。
核心模塊調(diào)用各個其他模塊的core_module完成各自模塊的加載工作。配置模塊為其他模塊的基礎，負責解析配置文件。

負責請求連接的建立，分發(fā)等網(wǎng)絡事件及定時器事件，其中所有模塊封裝到ngx_events_module_t接口中供其他模塊直接調(diào)用。

對應nginx用戶功能的三個主體。以Http模塊為例，初始化，退出，對配置項的處理等工作也統(tǒng)一封裝在ngx_http_module_t中。http請求的處理過程各模塊可插拔，為固定的11個階段，模塊想介入，只需在ngx_http_module_t中定義回調(diào)函數(shù)，http協(xié)議內(nèi)容多，對結果的處理也高度模塊化，根據(jù)配置項將模塊選擇性插入到輸出過濾鏈中。

nginx對各種操作系統(tǒng)的調(diào)用做了一層封裝，使模塊代碼無需區(qū)分。

http,stream,mail依賴事件模塊，事件模塊依賴核心模塊和配置模塊，上層模塊依賴底層的系統(tǒng)調(diào)用。

開發(fā)架構主要關注現(xiàn)有的代碼結構和開發(fā)代碼時如何擴展。先介紹代碼結構然后列舉一下如何新增模塊

包含core,event,http,mail,misc,os,stream這幾個文件夾

core

為nginx的核心源代碼，包括main函數(shù)/整體控制，基本數(shù)據(jù)結構封裝，配置管理，內(nèi)存管理，日志管理，文件讀寫網(wǎng)絡套接字功能，系統(tǒng)參數(shù)資源通用管理等

event

module子目錄實現(xiàn)了Nginx支持的事件驅(qū)動模型：AIOepollkqueueselectpoll等，其他提供了事件驅(qū)動模型相關數(shù)據(jù)結構的定義、初始化、事件接收傳遞管理功能以及時間驅(qū)動模型調(diào)用功能

http

module文件實現(xiàn)了http模塊的功能，perl為對perl的支持，v2為對http2.0的支持，其他提供結構定義、初始化、網(wǎng)絡連接建立、管理、關閉、數(shù)據(jù)報解析、upstream等通用功能

mail 郵件功能的實現(xiàn)

misc

os 根據(jù)操作系統(tǒng)對系統(tǒng)調(diào)用的封裝

stream 為對TCP/UDP反向代理的支持

編輯新的模塊步驟：

在自定義文件夾下，創(chuàng)建conf文件，說明名字和目錄。

編寫代碼。

編譯入nginx：
在configure腳本執(zhí)行時加入?yún)?shù)--add-module=PATH,執(zhí)行后會生成objs/Makefile,objs/ngx_modules.c（也可以直接修改）。會執(zhí)行conf文件，生成的ngx_modules.c包含nginx啟動時加載的所有模塊，nginx核心代碼中全局modules從這里獲取。這個模塊就被編譯到nginx程序中了。

首先給出nginx的整體架構圖，然后介紹運行架構中關注的運行模式，通信方式，IO處理選型。再總結下nginx運行架構的特性：事件驅(qū)動+碎片化+異步處理

說明：因為精力有限，只看了epoll的運行時架構，以下所有分析均只考慮linux并使用epoll的情況。
啟動后，有一個主進程，多個worker進行，兩個cache相關進程。多個worker共同監(jiān)聽事件并處理，反向代理會把請求轉發(fā)給后端服務。

master: 管理worker等子進程實現(xiàn)重啟服務，平滑升級，更換日志文件，配置文件實時生效等

worker: 簡單的負載均衡（高負載等待），搶鎖，監(jiān)聽處理事件，接收master命令

cache: nginx開啟緩存功能，會創(chuàng)建cache的兩個進程，cache loader在nginx啟動后將磁盤上次緩存的對象加載到內(nèi)存后自動退出，cache管理進程清理超時緩存文件，限制緩存文件總大小，這個過程反反復復，直到Nginx整個進程退出。

nginx的進程間通信，在不同應用場景下采取不同的形式：

linux與master/worker/cache進程通信：信號

master啟動時先把感興趣的信號注冊；
在主進程fork子進程之前要把所有信號調(diào)用sigprocmask阻塞住，等待fork成功后再將阻塞信號清除；
主進程之后就掛起在sigsuspend中，等待信號；

主進程與子進程通信：socketpair

這里每個子進程和父進程之間使用的是socketpair系統(tǒng)調(diào)用建立起來的全雙工的socket channel[]在父子進程中各有一套，channel[0]為寫端，channel[1]為讀端
父進程關閉socket[0], 子進程關閉socket[1]，父進程從sockets[1]中讀寫，子進程從sockets[0]中讀寫，還是全雙工形態(tài)

子進程也會監(jiān)督部分信號，是master通過socketpair發(fā)送過去的。linux關閉worker后，worker也會通過socketpair把信號發(fā)送給主進程

其他進程間共享數(shù)據(jù)：共享內(nèi)存

nginx中所有共享內(nèi)存都是以list鏈表的形式組織在全局變量cf->cycle->shared_memory下,在創(chuàng)建新的共享內(nèi)存之前會先對該鏈表進行遍歷查找以及沖突檢測，對于已經(jīng)存在且不存在沖突的共享內(nèi)存可直接返回引用。

函數(shù)ngx_shm_alloc()時共享內(nèi)存的實際分配,針對當前系統(tǒng)可提供的接口,可以是mmap,shmget等
應用于進程(如子進程之間，在進程重啟時新舊主進程需要搶鎖等)間需要共享的數(shù)據(jù)，比如連接數(shù)/互斥鎖等，另外提下鎖有多重互斥方式，在操作系統(tǒng)支持的情況下用優(yōu)先用原子操作。

這部分為了并發(fā)需要考慮多進程，多線程，IO阻塞，IO非阻塞，每個進程處理一個還是多個事件 等典型的IO網(wǎng)絡選型中的這幾個問題。

nginx在操作系統(tǒng)支持的情況下（不支持根據(jù)不同操作系統(tǒng)和配置，事件模型中選擇不同IO處理方式）采取多進程，每個進程可以同時接收多個請求，IO多路復用非阻塞的方式。詳細的運行架構如圖。簡單抽象過程：主進程創(chuàng)建監(jiān)聽socket后所有worker子進程繼承共同監(jiān)聽，通過搶鎖的方式?jīng)Q定同一時刻哪個worker是請求的acceptor方，accept請求后在本子進程中處理。

多進程

為了并發(fā)和利用多核處理，首先啟用多進程的模式，在主進程創(chuàng)建所有監(jiān)聽的socket，為了所有worker都可以繼承并監(jiān)聽該socket的fd。

多acceptor,多handler 采取多acceptor,多handler的模式，每個進程在自己內(nèi)部acceptor后分配給自己內(nèi)部的handler處理。為了防止多acceptor同時accept的驚群現(xiàn)象，只有搶到鎖的才把事件加入到監(jiān)聽，喚醒只會喚醒當前進程accept事件（新版的nginx采取reuseport可以一個端口被多個進程監(jiān)聽，支持的4.3的accept相關特征也不需要搶鎖）

進程accept多個 每個進程可以accept多個連接的模式，每次只處理accept，為三次握手完成的請求建立連接后就將其他事件放入延遲隊列，釋放鎖后才處理這部分隊列，以便其他進程可以繼續(xù)搶鎖

worker監(jiān)聽處理的過程如圖所示，在master啟動的時候，為每個端口創(chuàng)建監(jiān)聽套接字listen socked（以下簡稱lss），然后fork出worker進程，所有worker進程繼承同一份lss，為每個ls創(chuàng)建連接和事件結構，每個空閑worker搶鎖獲取這些lss的處理權。持有鎖就將ls的讀事件加入到epoll中等待，把接收事件分為兩類：優(yōu)先處理accept,延時處理非建立連接事件。accept后就釋放鎖。

worker會有三種情況，一種是空閑但沒有搶到鎖，就等待事件后繼續(xù)搶鎖。另一種是在處理隊列中請求，空閑后去搶鎖。第三種是空閑并且搶到鎖，則持有鎖并監(jiān)聽和分配給hander后釋放鎖，處理隊列請求

nginx所有需要等待的全都盡可能的碎片化，并加入到事件中，當事件ready后根據(jù)回調(diào)調(diào)用消費者處理，在Nginx里，Listen后是不需要循環(huán)等待accept，把他加入到epoll中，統(tǒng)一在epoll_wait中處理，當有返回直接調(diào)用accept。包括后續(xù)與客戶端建立的主動連接（非Listen的）的所有事件也都統(tǒng)一在epoll_wait中等待，有事件直接調(diào)用事件的消費回調(diào)函數(shù)。在調(diào)用epoll_wait時也是一直循環(huán)等待事件沒有退出，所以就要把事件拆分成特別細小的單元，這些單元都是可以異步執(zhí)行的，有了epoll這個模型可以把任何涉及到磁盤讀寫的小粒度事件加入到監(jiān)控中，比如讀過了頭第一行就去處理headline把其他的再加入到epoll中。

考慮如果沒有nginx，自己實現(xiàn)，是如何實現(xiàn)。

先聊運行架構

要實現(xiàn)的簡化功能概述：服務器要持續(xù)啟動，監(jiān)聽8000端口，收到請求后解析http協(xié)議，若是靜態(tài)請求，獲取文件內(nèi)容，封裝為Http的響應協(xié)議格式，發(fā)送；若為動態(tài)請求，轉化為fastcgi協(xié)議，轉發(fā)給fastcgi程序，發(fā)送到響應的端口，獲取數(shù)據(jù)后再轉化為Http響應協(xié)議格式發(fā)送。
為了實現(xiàn)高并發(fā)，當然要開啟多個處理進程，因為要監(jiān)聽同一個端口，需要一個監(jiān)聽進程負責監(jiān)聽端口（在不考慮新的技術支持多個進程同時監(jiān)聽一個端口的情況），accept后分配給處理進程。對于單個監(jiān)聽端口最好設計是單acceptor多進程的形式，然而，這基本上是不可能實現(xiàn)的，因為多個進程處理完的數(shù)據(jù)如何返回給監(jiān)聽進程，大量的數(shù)據(jù)再進程間通信是不現(xiàn)實的。因此對于單個監(jiān)聽端口只能是單進程。或者改用線程，然而多線程不穩(wěn)定。

我可以對多個監(jiān)聽端口開啟多個進程，每個監(jiān)聽不同的端口，但端口間流量分配不均勻時，進程負載不均衡。

=》從監(jiān)聽處理進程個數(shù)上，nginx比我自己設計聰明的地方體現(xiàn)出來了，特殊的多reactor多進程結構。

再說說每個進程里的高并發(fā)，網(wǎng)絡連接肯定會有IO等待，此時若可以繼續(xù)做其他的，會更快。每次接收一個請求的情況下，可以讀完請求后，一邊請求異步磁盤一邊寫返回頭等；在有子請求和接受多個請求的情況下，可以一邊為其他請求建立連接，一邊處理本請求的事件，多個請求同時處理。因此設計為單進程可以同時accept多個，每個可以并行的操作都拆為多帶帶事件異步處理。思想和nginx一樣。

再聊聊開發(fā)架構，代碼架構可以依照開發(fā)架構

nginx因為支持反向代理，支持多平臺，支持自定義配置，所以有配置模塊，統(tǒng)一的事件模塊，有抽象的配置結構。自己開發(fā)web服務器，可能不會考慮這么多，主要考慮http的處理過程，http固定的讀取頭，解析頭，真實ip，權限，處理，輸出協(xié)議的轉換，寫日志做成固定的順序，直接調(diào)用固定函數(shù)。nginx再此之上，每個過程有自己的回調(diào)，整體階段清晰，每個模塊可以在把回調(diào)加入到各個子階段，更靈活。協(xié)議按順序也先固定輸出鏈，若沒有該協(xié)議直接跳過，對于這種運行前不知道會有哪些輸出過濾的情況，自己寫可能就在運行中判斷有就調(diào)用了，nginx是固定走，沒有直接跳過，這兩種根據(jù)不同應用各有應用吧。

模塊化

無論配置，初始化，代碼結構都是模塊化的，各個模塊要介入到主流程，根本不需要修改主流程代碼，通過在hook位置增加回調(diào)。

高度抽象

正常很難想到所有的模塊和配置全部都一個抽象結構，各個子模塊也都統(tǒng)一抽象結構，新增加功能簡單，可讀性高

輸出統(tǒng)一過濾鏈，功能可插拔

擴展容易，代碼簡潔，可讀性高

多reactor多進程結構

經(jīng)過上述分析，Nginx在并發(fā)選型上要么是單reactor單進程結構，要么是單reactor多線程結構，但多線程只要一個操作共享區(qū)域，會影響其他線程，所以在不需要共享數(shù)據(jù)的情況下，最好用多進程。nginx巧妙的雖然同一時刻只能單reactor，但在accept后立刻釋放鎖，也達到多reactor的性能，此架構不常見，可以參考。memcache,mysql等因為要共享數(shù)據(jù)都是多reactor多線程；apache舊版是一個進程處理一個請求，類似phpfpm，本質(zhì)上是單reactor單進程，后來一個進程中有多個線程，單reactor多線程，但每個線程處理一個請求；后面也加入了IO多路復用，每個線程中處理多個請求。

后續(xù)preactor+線程

本質(zhì)上epoll還是等待的，還是需要進程去詢問，利用內(nèi)核異步IO，可以做到事件自動處理，處理后通知，不需要詢問，其架構如下：

單linux的AIO還不完善，到目前為止，nginx實現(xiàn)了AIO+線程的模型，但還未應用。

內(nèi)存池，連接池

為了省去每次申請，減少內(nèi)存碎片，統(tǒng)一釋放等，提前準備好內(nèi)存池和連接池 。

nginx作為一個高性能高可用高可擴展的 http服務器和多協(xié)議反向代理服務器，其運行架構采用特殊的監(jiān)聽同一端口卻多reactor多進程的模型，值得借鑒；高度抽象和模塊化的邏輯架構使得功能龐大代碼卻清晰易懂，開發(fā)和擴展代價低。

參考

nginx功能 http://nginx.org/en/
nginx代碼結構 https://www.kancloud.cn/diges...