[[281978]]

Nginx是Envoy出現之前網絡通信中間件領域非常有代表性的開源系統，功能強大，性能出色，擴展性很強，已經形成了強大的生態，成為HTTP流量管理領域事實上的標桿。Envoy作為后起之秀，雖然定位和目標上與Nginx有不少差異，但架構設計層面，Envoy和Nginx都有很多的可取之處。

下面會從功能定位、整體網絡模型、連接處理、請求解析、插件機制等維度，對Envoy和Nginx進行詳細剖析和比較，通過與Nginx功能和架構層面的全方位對比，大家也可以對Envoy的架構設計有更立體的認識。

1. 功能與定位

Nginx最核心的功能是Web服務器和反向代理服務器，Web服務器完成對HTTP請求協議的解析和以HTTP協議格式響應請求、緩存、日志處理這些基本Web服務器功能;反向代理服務器完成對請求的轉發、負載均衡、鑒權、限流、緩存、日志處理等代理常用功能。

除了對Nginx協議的支持外，Nginx還支持普通的TCP、UDP反向代理功能，同時以stream方式支持通用的基于4層協議的反向代理，比如MySQL代理、Memcached代理等。

Envoy的目標比較遠大，定位是透明接管微服務之間的通信流量，將通信和服務治理功能從微服務中解耦，通過Envoy可以方便地增加對自定義協議的支持。

概括起來，Nginx的關鍵詞是Web服務器和反向代理，Envoy是透明接管流量，更加體現對流量的控制和掌控力。另外，從使用方式上看，微服務對Nginx是顯式調用，通過Nginx完成負載均衡等相關功能，對Envoy是隱式調用，業務微服務不需要感知Envoy的存在，和使用Envoy使用相同的方式進行通信，只不過不再需要關注通信和鏈路治理的細節。

2. 網絡模型

網絡模型上，Nginx采用的是經典的多進程架構，由master進程和worker進程組成。其中，master進程負責對worker進程進行管理，具體包含監控worker進程的運行狀態，根據外部輸入的一些管理命令向worker進程發送處理信號以及worker進程退出時啟動新的worker進程。worker進程負責處理各種網絡事件，各個worker進程之間相互獨立，一同競爭來自客戶端的新的連接和請求，為了保證請求處理的高效，一個請求處理的全部過程在同一個worker進程中。worker進程的個數推薦配置為與當前環境的CPU核數相同。

自從Nginx誕生以來，一直使用上述經典的多進程架構。這種架構下，請求處理過程中如果遇到特別耗時的操作，比如磁盤訪問、第三方服務同步訪問等，會導致處理該請求的進程被夯住，不僅CPU資源沒有得到充分利用，夯住時間比較長時不僅會影響當前請求，嚴重時會導致本進程的待處理請求大量超時。為了解決這種問題，Nginx從1.7.11版本開始引入了線程池的概念，如果遇到耗時特別長的邏輯，可以增加線程池配置，放到線程池中進行處理。線程池機制的引入對Nginx架構來說是個很好的補充，通過針對性地解決耗時特別長的一些阻塞場景，使得Nginx的性能達到一個新的高度。

和Nginx不同，Envoy采用了多線程的網絡架構，Envoy一般會根據當前CPU核數創建相同個數的worker線程，所有worker線程同時對Envoy配置的監聽器進行監聽，接受新的連接，為每個新連接實例化相應的過濾器處理鏈，處理該連接上的所有請求。和Nginx類似，Envoy的每個請求的處理全流程都在同一個線程下進行。

從上面的分析看，Envoy和Nginx的網絡處理方式大體類似。這兩種方式都是全異步的編程模式，所有的操作都是異步進行，每個執行上下文使用一個單獨的事件調度器，對該執行上下文的異步事件進行調度和觸發，只是承載網絡的執行上下文有差異，Nginx通過多進程的方式承載，Envoy使用的是多線程方式。

Nginx通過線程池的方式，從設計上解決了異步編程中的阻塞問題，但仍然沒有從根本上解決這個問題，如果遇到設計或者代碼層面沒有注意到的問題場景，仍然會出現因為當前請求阻塞導致后續等待的請求得不到處理而超時的現象。由于都是全異步的編程模式，Envoy也會遇到同樣的問題，不過Envoy開始嘗試著進行解決，具體的解決方式是：為每個worker線程分別設置一個看門狗，并通過定時器定期更新本線程看門狗的最新更新時間，主線程會監控各個worker線程看門狗一段時間內是否有更新，如果超過一段時間沒有更新，可以認為該線程的看門狗定時更新操作得不到執行的機會，從而推斷出這個線程當前已經夯住，無法處理請求消息。Envoy通過這種機制可以檢測出worker線程是否被長時間阻塞住，在此機制的基礎上，后續可以增加相應的處理(比如將待處理請求移到其他線程，然后把該線程殺掉)，可以從機制上解決工作線程被阻塞的問題。

3. 連接處理

Nginx通過worker_connections參數來控制每個worker能夠建立的最大連接數，從Nginx網絡模型可以看出，客戶端連接到來時，所有空閑的進程都會去競爭這個新連接。這種競爭如果導致某個進程得到的新連接比較多，同時該進程的空閑連接也會很快用完，如果不進行控制，后續該進程獲取新連接時會遇到沒有空閑連接而丟棄，而有的進程有空閑連接卻獲取不到新連接。那么直接按照均等的方式將連接分配給各個進程是否可行呢?這種方式其實也是有問題的，不同連接上可能承載的請求QPS差異很大，可能會出現兩個進程處理相同連接數，但一個特別忙另外一個特別閑的現象，因此為了保證各個工作進程都能夠最大限度地提供自己的計算能力，需要對連接進行精細化管理，Nginx采取的方式是各工作進程根據自身的忙閑程度，動態調整獲取新連接的時機，具體實現是：當本進程當前連接數達到最大worker_connections的7/8時，本worker進程不會去試圖拿accept鎖，也不會去處理新連接，這樣其他worker進程就更有機會去處理監聽句柄，建立新連接。而且，由于超時時間的設定，使得沒有拿到鎖的worker進程去拿鎖的頻率更高，通過這種方式，Nginx解決了worker進程之間的負載均衡問題。

Envoy也會遇到和Nginx類似的負載不均問題，Envoy當前發展很快，同時需要解決的問題很多，Envoy社區的人覺得這個問題當前的優先級還不夠高，后續會根據具體情況對這個問題進行討論和解決。

4. 插件機制

Nginx擁有強大的插件擴展能力，基于Nginx的插件擴展機制，業務可以非常方便地完成差異化和個性化定制，Nginx 插件通過模塊的方式提供，具體來說，Nginx主要提供如下幾種形式的插件擴展：

1)通過stream機制進行協議擴展，比如增加memcached協議代理和負載均衡等;

2)以Handler方式處理HTTP請求;

3)對HTTP請求和響應消息進行過濾，比如可以修改和定制消息內容等;

4)訪問Upstream時的負載均衡，可以提供自定義的負載均衡機制。

對于最成熟的HTTP協議來說，Nginx把整個請求處理過程劃分為多個階段，當前一共有包含讀取請求內容、請求地址改寫等一共11個處理階段，業務需要在某個階段進行擴展和定制處理時，只需要掛載該階段對應的回調函數，Nginx核心處理HTTP請求到這個階段時，會回調之前注冊的回調函數進行處理。

Nginx對模塊的支持總體來說不算靈活，Nginx模塊必須和Nginx自身源碼一塊編譯，并且只能在編譯期間選擇當前支持的模塊，不支持運行時進行模塊動態選取和加載，大家一直以來吐槽比較多。為了解決這個問題，Nginx在1.9.11版本引入了模塊動態加載支持，從此不再需要替換Nginx文件即可增加第三方模塊擴展。Nginx也支持Lua擴展，利用Lua語言的簡單易用和強大的協程機制，可以非常方便地實現很多擴展機制，并且性能也能夠基本滿足需求。

Envoy也提供了強大的插件擴展機制，當前使用最多的地方是監聽過濾插件和網絡處理過濾插件。和Nginx相比，Envoy網絡插件定位在協議層面，以HTTP協議為例，Envoy并沒有那么細粒度的插件擴展機制，如果想對Envoy的HTTP協議處理進行擴展，當前并沒有提供特別多的擴展點。

Envoy的插件當前采用的是靜態注冊的方式，插件代碼和Envoy代碼一塊進行編譯，和Nginx不同，Envoy從最開始就支持插件的動態加載，Envoy通過獨特的XDS API設計，可以隨時對Envoy的XDS插件進行定制修改，Istio將修改后的XDS配置通過Grpc的方式推送給Envoy動態加載和生效。

此外，當前Envoy社區和Cilium社區一塊探索利用，利用eBPF提供的用戶態網絡定制能力，對Envoy的流量進行精細化的管理和擴展定制。Cilium從1.3版本開始，引入了Envoy的Go擴展，通過Go擴展實現Filter插件向Envoy注冊，主要實現的還是OnData()函數，當Envoy接收到流量時，就會調用插件的OnData函數進行處理。

Envoy在Lua擴展支持方面也進行了一些探索性的工作，當前已經試驗性地支持使用Lua腳本對HTTP請求進行過濾和調整。Lua腳本HTTP過濾器當前仍處于實驗階段，不建議直接在生產環境中使用，后續待驗證成熟后才能在生產環境使用。成熟后可以在更多的場景下通過Lua腳本機制增強Envoy的擴展性。