Nginx之子產品處理流程nginx的4種角色子產品子產品是如何被調用的？nginx子產品處理流程

    nginx的内部結構是由核心部分和一系列的功能子產品所組成。這樣劃分是為了使得每個子產品的功能相對簡單，便于開發，同時也便于對系統進行功能擴充。這樣的子產品化設計類似于面向對象中的接口類，它增強了nginx源碼的可讀性、可擴充性和可維護性。

Nginx子產品主要有4種角色： 

    (1) core(核心子產品)：建構nginx基礎服務、管理其他子產品。 

    (2) handlers(處理子產品)： 用于處理HTTP請求，然後産生輸出。 

    (3) filters（過濾子產品）： 過濾handler産生的輸出。 

    (4) load-balancers（負載均衡子產品）：當有多于一台的後端備選伺服器時，選擇一台轉發HTTP請求。

Nginx的核心子產品主要負責建立nginx服務模型、管理網絡層和應用層協定、以及啟動針對特定應用的一系列候選子產品。

其他子產品負責配置設定給web伺服器的實際工作：

當Nginx發送檔案或者轉發請求到其他伺服器，由handlers(處理子產品)或load-balancers(負載均衡子產品)提供服務；

當需要Nginx把輸出壓縮或者在服務端加一些東西，由filters(過濾子產品) 提供服務。 

當伺服器啟動，每個handlers(處理子產品)都有機會映射到配置檔案中定義的特定位置（location）； 

如果有多個handlers(處理子產品)映射到特定位置時，隻有一個會“赢”（說明配置檔案有沖突項，應該避免發生）。 

處理子產品以三種形式傳回：

OK、

ERROR、

或者放棄處理這個請求而讓預設處理子產品來處理（主要是用來處理一些靜态檔案，事實上如果是位置正确而真實的靜态檔案，預設的處理子產品會搶先處理）。

如果handlers(處理子產品)把請求反向代理到後端的伺服器，就變成另外一類的子產品：load-balancers（負載均衡子產品）。 

負載均衡子產品的配置中有一組後端伺服器，當一個HTTP請求過來時，它決定哪台伺服器應當獲得這個請求。 

Nginx的負載均衡子產品采用兩種方法：

輪轉法，它處理請求就像紙牌遊戲一樣從頭到尾分發；

IP哈希法，在衆多請求的情況下，它確定來自同一個IP的請求會分發到相同的後端伺服器。

如果handlers(處理子產品)沒有産生錯誤，filters（過濾子產品）将被調用。 

多個filters（過濾子產品）能映射到每個位置，是以（比如）每個請求都可以被壓縮成塊。它們的執行順序在編譯時決定。 

filters（過濾子產品）是經典的“接力連結清單（CHAIN OF RESPONSIBILITY）”模型：一個filters（過濾子產品）被調用，完成其工作，然後調用下一個filters（過濾子產品），直到最後一個filters（過濾子產品）。Nginx完成這個回複。 

過濾子產品鍊的特别之處在于，

每個filters（過濾子產品）不會等上一個filters（過濾子產品）全部完成；

它能把前一個過濾子產品的輸出作為其處理内容；有點像Unix中的流水線。

過濾子產品能以buffer（緩沖區）為機關進行操作，這些buffer一般都是一頁（4K）大小，當然你也可以在nginx.conf檔案中進行配置。這意味着，比如，子產品可以壓縮來自後端伺服器的回複，然後像流一樣的到達用戶端，直到整個回複發送完成。 

總之，過濾子產品鍊以流水線的方式高效率地向用戶端發送響應資訊。

  是以總結下上面的内容，一個典型的處理周期是這樣的： 

  用戶端發送HTTP請求 –> Nginx基于配置檔案中的位置選擇一個合适的處理子產品 ->（如果有）負載均衡子產品選擇一台後端伺服器 –> 處理子產品進行處理并把輸出緩沖放到第一個過濾子產品上 –> 第一個過濾子產品處理後輸出給第二個過濾子產品 –> 然後第二個過濾子產品又到第三個 –> 依此類推 –> 最後把回複發給用戶端。   

下圖展示了nginx子產品處理流程。

本文轉自 于學康 51CTO部落格，原文連結：http://blog.51cto.com/blxueyuan/1928710，如需轉載請自行聯系原作者