深入 Nginx 之架構(gòu)篇

zhangrxiang 發(fā)布于2019-07-25 14:39 / 2876人閱讀

摘要：請求的多階段異步處理多階段異步處理請求與事件驅(qū)動架構(gòu)是密切相關(guān)的，也就是說，請求的多階段異步處理只能基于事件驅(qū)動架構(gòu)實現(xiàn)。

前言

最近在讀 Nginx 相關(guān)的書籍，做一下讀書筆記。

Nginx 作為業(yè)界知名的高性能服務(wù)器，被廣泛的應(yīng)用。它的高性能正是由于其優(yōu)秀的架構(gòu)設(shè)計，其架構(gòu)主要包括這幾點(diǎn)：模塊化設(shè)計、事件驅(qū)動架構(gòu)、請求的多階段異步處理、管理進(jìn)程與多工作進(jìn)程設(shè)計、內(nèi)存池的設(shè)計，以下內(nèi)容依次進(jìn)行說明。

模塊化設(shè)計

高度模塊化的設(shè)計是 Nginx 的架構(gòu)基礎(chǔ)。在 Nginx 中，除了少量的核心代碼，其他一切皆為模塊。

所有模塊間是分層次、分類別的，Nginx 官方共有五大類型的模塊：核心模塊、配置模塊、事件模塊、HTTP 模塊、mail 模塊。它們之間的關(guān)系如下：

在這 5 種模塊中，配置模塊和核心模塊是與 Nginx 框架密切相關(guān)的。而事件模塊則是 HTTP 模塊和 mail 模塊的基礎(chǔ)。HTTP 模塊和 mail 模塊的“地位”類似，它們都是更關(guān)注于應(yīng)用層面。

事件驅(qū)動架構(gòu)

事件驅(qū)動架構(gòu)，簡單的說就是由一些事件發(fā)生源來產(chǎn)生事件，由事件收集器來收集、分發(fā)事件，然后由事件處理器來處理這些事件（事件處理器需要先在事件收集器里注冊自己想處理的事件）。

對于 Nginx 服務(wù)器而言，一般由網(wǎng)卡、磁盤產(chǎn)生事件，Nginx 中的事件模塊將負(fù)責(zé)事件的收集、分發(fā)操作；而所有的模塊都可能是事件消費(fèi)者，它們首先需要向事件模塊注冊感興趣的事件類型，這樣，在有事件產(chǎn)生時，事件模塊會把事件分發(fā)到相應(yīng)的模塊中進(jìn)行處理。

對于傳統(tǒng) web 服務(wù)器（如 Apache）而言，采用的所謂事件驅(qū)動往往局限在 TCP 連接建立、關(guān)閉事件上，一個連接建立以后，在其關(guān)閉之前的所有操作都不再是事件驅(qū)動，這時會退化成按順序執(zhí)行每個操作的批處理模式，這樣每個請求在連接建立后都將始終占用著系統(tǒng)資源，直到關(guān)閉才會釋放資源。這種請求占用著服務(wù)器資源等待處理的模式會造成服務(wù)器資源極大的浪費(fèi)。如下圖所示，傳統(tǒng) web 服務(wù)器往往把一個進(jìn)程或線程作為時間消費(fèi)者，當(dāng)一個請求產(chǎn)生的事件被該進(jìn)程處理時，直到這個請求處理結(jié)束時，進(jìn)程資源都將被這一請求所占用。比較典型的例子如 Apache 同步阻塞的多進(jìn)程模式就是這樣的。

傳統(tǒng) web 服務(wù)器處理事件的簡單模型（矩形代表進(jìn)程）:

Nginx 采用事件驅(qū)動架構(gòu)處理業(yè)務(wù)的方式與傳統(tǒng)的 web 服務(wù)器是不同的。它不使用進(jìn)程或者線程來作為事件消費(fèi)者，所謂的事件消費(fèi)者只能是某個模塊。只有事件收集、分發(fā)器才有資格占用進(jìn)程資源，它們會在分發(fā)某個事件時調(diào)用事件消費(fèi)模塊使用當(dāng)前占用的進(jìn)程資源，如下圖所示，該圖中列出了 5 個不同的事件，在事件收集、分發(fā)者進(jìn)程的一次處理過程中，這 5 個事件按照順序被收集后，將開始使用當(dāng)前進(jìn)程分發(fā)事件，從而調(diào)用相應(yīng)的事件消費(fèi)者來處理事件。當(dāng)然，這種分發(fā)、調(diào)用也是有序的。

Nginx 處理事件的簡單模型：

由上圖可以看出，處理請求事件時，Nginx 的事件消費(fèi)者只是被事件分發(fā)者進(jìn)程短期調(diào)用而已，這種設(shè)計使得網(wǎng)絡(luò)性能、用戶感知的請求時延都得到了提升，每個用戶的請求所產(chǎn)生的事件會及時響應(yīng)，整個服務(wù)器的網(wǎng)絡(luò)吞吐量都會由于事件的及時響應(yīng)而增大。當(dāng)然，這也帶來一定的要求，即每個事件消費(fèi)者都不能有阻塞行為，否則將會由于長時間占用事件分發(fā)者進(jìn)程而導(dǎo)致其他事件得不到及時響應(yīng)，Nginx 的非阻塞特性就是由于它的模塊都是滿足這個要求的。

請求的多階段異步處理

多階段異步處理請求與事件驅(qū)動架構(gòu)是密切相關(guān)的，也就是說，請求的多階段異步處理只能基于事件驅(qū)動架構(gòu)實現(xiàn)。多階段異步處理就是把一個請求的處理過程按照事件的觸發(fā)方式劃分為多個階段，每個階段都可以由事件收集、分發(fā)器來觸發(fā)。

處理獲取靜態(tài)文件的 HTTP 請求時切分的階段及各階段的觸發(fā)事件如下所示：

這個例子中，該請求大致分為 7 個階段，這些階段是可以重復(fù)發(fā)生的，因此，一個下載靜態(tài)資源請求可能會由于請求數(shù)據(jù)過大，網(wǎng)速不穩(wěn)定等因素而被分解為成百上千個上圖所列出的階段。

異步處理和多階段是相輔相成的，只有把請求分為多個階段，才有所謂的異步處理。當(dāng)一個時間被分發(fā)到事件消費(fèi)者中進(jìn)行處理時，事件消費(fèi)者處理完這個事件只相當(dāng)于處理完 1 個請求的階段。什么時候可以處理下一個階段呢？這只能等待內(nèi)核的通知，即當(dāng)下一次事件出現(xiàn)時，epoll 等事件分發(fā)器將會獲取到通知，然后去調(diào)用事件消費(fèi)者進(jìn)行處理。

管理進(jìn)程、多工作進(jìn)程設(shè)計

Nginx 在啟動后，會有一個 master 進(jìn)程和多個 worker 進(jìn)程。master 進(jìn)程主要用來管理worker 進(jìn)程，包括接收來自外界的信號，向各 worker 進(jìn)程發(fā)送信號，監(jiān)控 worker 進(jìn)程的運(yùn)行狀態(tài)以及啟動 worker 進(jìn)程。 worker 進(jìn)程是用來處理來自客戶端的請求事件。多個 worker 進(jìn)程之間是對等的，它們同等競爭來自客戶端的請求，各進(jìn)程互相獨(dú)立，一個請求只能在一個 worker 進(jìn)程中處理。worker 進(jìn)程的個數(shù)是可以設(shè)置的，一般會設(shè)置與機(jī)器 CPU 核數(shù)一致，這里面的原因與事件處理模型有關(guān)。Nginx 的進(jìn)程模型，可由下圖來表示：

在服務(wù)器上查看 Nginx 進(jìn)程：

這種設(shè)計帶來以下優(yōu)點(diǎn)：

1）利用多核系統(tǒng)的并發(fā)處理能力

現(xiàn)代操作系統(tǒng)已經(jīng)支持多核 CPU 架構(gòu)，這使得多個進(jìn)程可以分別占用不同的 CPU 核心來工作。Nginx 中所有的 worker 工作進(jìn)程都是完全平等的。這提高了網(wǎng)絡(luò)性能、降低了請求的時延。

2）負(fù)載均衡

多個 worker 工作進(jìn)程通過進(jìn)程間通信來實現(xiàn)負(fù)載均衡，即一個請求到來時更容易被分配到負(fù)載較輕的 worker 工作進(jìn)程中處理。這也在一定程度上提高了網(wǎng)絡(luò)性能、降低了請求的時延。

3）管理進(jìn)程會負(fù)責(zé)監(jiān)控工作進(jìn)程的狀態(tài)，并負(fù)責(zé)管理其行為

管理進(jìn)程不會占用多少系統(tǒng)資源，它只是用來啟動、停止、監(jiān)控或使用其他行為來控制工作進(jìn)程。首先，這提高了系統(tǒng)的可靠性，當(dāng) worker 進(jìn)程出現(xiàn)問題時，管理進(jìn)程可以啟動新的工作進(jìn)程來避免系統(tǒng)性能的下降。其次，管理進(jìn)程支持 Nginx 服務(wù)運(yùn)行中的程序升級、配置項修改等操作，這種設(shè)計使得動態(tài)可擴(kuò)展性、動態(tài)定制性較容易實現(xiàn)。

內(nèi)存池的設(shè)計

為了避免出現(xiàn)內(nèi)存碎片，減少向操作系統(tǒng)申請內(nèi)存的次數(shù)、降低各個模塊的開發(fā)復(fù)雜度，Nginx 設(shè)計了簡單的內(nèi)存池，它的作用主要是把多次向系統(tǒng)申請內(nèi)存的操作整合成一次，這大大減少了 CPU 資源的消耗，同時減少了內(nèi)存碎片。

因此，通常每一個請求都有一個簡易的獨(dú)立內(nèi)存池（如每個 TCP 連接都分配了一個內(nèi)存池），而在請求結(jié)束時則會銷毀整個內(nèi)存池，把曾經(jīng)分配的內(nèi)存一次性歸還給操作系統(tǒng)。這種設(shè)計大大提高了模塊開發(fā)的簡單些，因為在模塊申請內(nèi)存后不用關(guān)心它的釋放問題；而且因為分配內(nèi)存次數(shù)的減少使得請求執(zhí)行的時延得到了降低。同時，通過減少內(nèi)存碎片，提高了內(nèi)存的有效利用率和系統(tǒng)可處理的并發(fā)連接數(shù)，從而增強(qiáng)了網(wǎng)絡(luò)性能。