解剖Nginx服務器架構-服務器運維

2020-05-27 17:37 作者：艾銻無限 瀏覽量：

解剖Nginx服務器架構-服務器運維

IT服務 一.Nginx的模塊化
模塊化結構的思想是一個很久的概念，但也正是成熟的思想造就了Nginx的巨大優越性。
我們知道Nginx從總體上來講是有許多個模塊構成的。習慣將Nginx分為5大模塊分別為：核心模塊，標準HTTP模塊，可選HTTP模塊，郵件服務模塊和第三方模塊。 這5個模塊由上到下重要性一次遞減。

(1)核心模塊;
核心模塊是Nginx服務器正常運行必不可少的模塊，如同操作系統的內核。它提供了Nginx最基本的核心服務。像進程管理、權限控制、錯誤日志記錄等;

(2)標準HTTP模塊;
標準HTTP模塊支持標準的HTTP的功能;

(3)可選HTTP模塊;
可選HTTP模塊主要用于擴展標準的HTTP功能，讓Nginx能處理一些特殊的服務;

(4)郵件服務模塊;
郵件服務模塊主要用于支持Nginx的郵件服務;
(5)第三方模塊;
第三方模塊是為了擴展Nginx服務器應用，完成開發者想要的功能;
*******Nginx中的模塊命名有自己的習慣*********
一般以Ngx_作為前綴，——module作為后綴，中間使用一個或者多個英文單詞描述模塊的工能，例如Ngx_core_module表示該模塊提供Nginx的核心功能等;
具體各個模塊中包含哪些模塊可以自己去源碼中查詢，這里略過;

二.Nginx的web請求處理機制
從架構設計上說，Nginx服務器是與眾不同的。其一在于它的模塊化設計;其二也是更重要的一點在于它對與客戶端請求的處理機制上;
web服務器和客戶端是一對多的關系，Web服務器必須有能力同時為多個客戶端提供服務。一般來說完成并行處理請求工作有三種方式：
1.多進程方式;
2.多線程方式;
3.異步方式;
這里簡單說明一下這三種方式：
(1)多進程方式
多進程方式指，服務器每當收到一個客戶端時。就有服務器主進程生成一個子進程出來和客戶端建立連接進行交互。指導連接斷開。該子進程就結束了。
多進程方式的優點是設計簡單，各個子進程相對獨立，處理客戶端請求時彼此不受干擾;缺點是操作系統生成一個子進程需要進行內存復制等操作，在資源和時間上會產生一定的開銷;當有大量請求時，會導致系統性能下降;
(2)多線程方式
多線程方式指每當服務器接收到一個請求后，會由服務器主進程派生出一個線程出來和客戶端進行交互。由于操作系統產生出一個線程的開銷遠遠小于一個進程的開銷。故多線程方式在很大程度上減輕了Web服務器對系統資源的要求。但同時由于多個線程位于一個進程內，可以訪問同樣的內存空間。所以需要開發者自己對內存進程管理，增大了難度。

(3)異步方式
異步方式適合多進程和多線程完全不同的一種處理客戶端請求的方式。這里有幾個概念我們需要熟悉一下：同步，異步，阻塞，非阻塞;
在網絡通信中同步和異步是描述通信模式的概念。
同步：發送方發送完請求后，需要等待接收到接收方發回的響應，才能發送下一個請求;所有請求在服務端得到同步，發送方和接收方的步調是一致的;
異步：和同步機制相反，在異步機制中，發送方發出一個請求后，不等接收方響應這個請求，就繼續發送下一個請求;所有來自發送方的請求形成一個隊列，接收方處理完成后通知發送方;
在進程處理調度方式上用阻塞與非阻塞。在網絡通信中主要指套接字socket的阻塞和非阻塞，而socket的實質就是IO操作。
阻塞：調用結果返回之前，當前線程從運行狀態被掛起，一直等到調用結果返回之后，才進入就緒狀態，獲取CPU后繼續執行。
非阻塞：和阻塞方式正好相反，如果調用結果不能馬上返回，當前線程也不會馬上返回，而是立即返回執行下一個調用。
因此就衍生出4中方式：同步阻塞，同步非阻塞，異步阻塞，異步非阻塞
這里簡單解釋一下異步非阻塞：發送方向接收方發送請求后，不用等待響應，可以繼續其他工作;接收方處理請求時進行的IO操作如果不能馬上得到結果，也不必等待，而是馬上返回去去做其他事情。當IO操作完成以后，將完成狀態和結果通知接收方，接收方再響應發送方。

與此同時Nginx服務器處理請求是怎樣的呢???
Nginx服務器的一個顯著的優勢就是能夠同時處理大量的并發請求。它結合多進程機制和異步機制。異步機制使用的是異步非阻塞方式。(Master-Worker)。
每個工作進程使用異步非阻塞方式，可以處理多個客戶端請求。當某個工作進程接收到客戶端的請求以后，調用IO進行處理，如果不能立即得到結果，就去處理其他的請求;而客戶端在此期間也無需等待響應，可以去處理其他事情;當IO返回時，就會通知此工作進程;該進程得到通知，暫時掛起當前處理的失誤去響應客戶端請求。
也就是：

Nginx采用異步非阻塞方式來處理請求，處理請求具體到系統底層就是讀寫事件(所謂阻塞調用方式即請求事件還沒準備好，線程只能一直去等，等事件準備好了再處理;而非阻塞即事件沒準備好，馬上返回ENGAIN,告訴你事件還沒準準備好，而在這期間可以先去做其他事，再回頭看看事件準備好了嗎，時不時會看，需要的開銷也是不小的)
異步可以理解為循環處理多個準備好的事件，不會導致無謂的資源浪費，當有更多的并發數只會占用更多的內存而已;

IT服務三.Nginx服務器的實踐驅動模型
從上面我們可以知道，Nginx服務器的工作進程調用IO后，就取進行其他工作了;當IO調用返回后，會通知工作進程。但IO調用時如何把自己的狀態通知給工作進程的呢??
一般解決這個問題有兩種方法：
(1)讓工作進程在進行其他工作的過程中間隔一段時間就去檢查一下IO的狀態，如果完成就響應客戶端，如果未完成，繼續工作。
(2)IO調用在完成后能主動通知工作進程。
當然最好的就是用第二種方法了;像select/poll/epoll等這樣的系統調用就是用來支持第二種解決方案的。這些系統調用也常被稱為事件驅動模型。他們提供了一種機制就只讓進程同時處理多個并發請求，不用關心IO調用的具體狀態。IO調用完全由事件驅動模型來管理。

Nginx中的事件驅動模型
就是用事件驅動處理庫(多路IO復用)，最常用的就是select模型，poll模型，epoll模型。
關于這三個模型的詳解在這里可以看到：https://segmentfault.com/a/1190000003063859

IT服務四.架構簡介
通過這個上面的簡單講解，再加上服務器的架構的了解，可以對Nginx有一個簡單的了解，希望對之后的源碼剖析有幫助。 大致上Nginx的架構就是這樣：
1.Nginx啟動后，會產生一個主進程，主進程執行一系列的工作后會產生一個或者多個工作進程;
2.在客戶端請求動態站點的過程中，Nginx服務器還涉及和后端服務器的通信。Nginx將接收到的Web請求通過代理轉發到后端服務器，由后端服務器進行數據處理和組織;
3.Nginx為了提高對請求的響應效率，降低網絡壓力，采用了緩存機制，將歷史應答數據緩存到本地。保障對緩存文件的快速訪問;

##工作進程##
工作進程的主要工作有以下幾項：
接收客戶端請求;
將請求一次送入各個功能模塊進行過濾處理;
IO調用，獲取響應數據;
與后端服務器通信，接收后端服務器處理結果;

數據緩存
響應客戶端請求;

##進程交互##
Nginx服務器在使用Master-Worker模型時，會涉及到主進程和工作進程的交互和工作進程之間的交互。這兩類交互都依賴于管道機制。
1.Master-Worker交互
這條管道與普通的管道不同，它是由主進程指向工作進程的單向管道，包含主進程向工作進程發出的指令，工作進程ID等;同時主進程與外界通過信號通信;
2.worker-worker交互
這種交互是和Master-Worker交互是基本一致的。但是會通過主進程。工作進程之間是相互隔離的，所以當工作進程W1需要向工作進程W2發指令時，首先找到W2的進程ID，然后將正確的指令寫入指向W2的通道。W2收到信號采取相應的措施。