本文準備圍繞七個點來講網關，分別是網關的基本概念、網關設計思路、網關設計重點、流量網關、業務網關、常見網關對比，對基礎概念熟悉的朋友可以根據目錄查看自己感興趣的部分。

什麼是網關

網關，很多地方將網關比如成門， 沒什麼問題， 但是需要區分網關與網橋的區別，

網橋工作在數據鏈路層，在不同或相同類型的LAN之間存儲並轉發數據幀，必要時進行鏈路層上的協議轉換。可連接兩個或多個網絡，在其中傳送信息包。

網關是一個大概念，不具體特指一類產品，只要連接兩個不同的網絡都可以叫網關，網橋一般只轉發信息，而網關可能進行包裝。

網關通俗理解

根據網關的特性，舉個例子:

假如你要去找集團老闆(這兒只是舉個例子)， 大家都知道老闆肯定不是誰想見就能見的， 也怕壞人嘛， 那麼你去老闆所在的辦公樓，假如是集團總部， 大樓這個門就充當了網關的角色， 大門一般都有看門員，看門員會做哪些事情呢?

首先所有想見老闆的人肯定都得從這個門進(統一入口)， 這個門相當於將辦公室和外界隔離了，主要為了保護裡面的安全以及正常工作， 來到這個門之後， 門衛肯定會讓你出示相關證件(鑑權檢驗)， 意思就是判斷你要見老闆這個請求是否合理， 如果不合理直接就拒絕了， 讓你回家等消息， 如果鑑權之後， 發現你找老闆其實只是為了和他談談兩元店的生意， 門衛會跟你說這個用不著找老闆， 你去集團投資部就行了(動態路由， 將請求路由到不同的後端集群中)， 此時會對你進行一些包裝，例如給你出具一個訪問證類似的，然後告訴你路該怎麼走，等等。

你看看，網關的作用是不是就是這三個， 最終目的就是減少你與集團的耦合，具體到計算機上就是減少客戶端與服務端的耦合，如果沒有網關意味著所有請求都會直接調用服務器上的資源，這樣耦合太強了，服務器出了問題，客戶端會直接報錯， 例如老闆換工作的地方了，如果沒有網關你直接去原來的地方找， 肯定會被告知老闆不在這兒。

為什麼需要網關

當使用單體應用程序架構時，客戶端（Web 或移動端）通過向後端應用程序發起一次REST 調用來獲取數據。負載均衡器將請求路由給N 個相同的應用程序實例中的一個。然後應用程序會查詢各種數據庫表，並將響應返回給客戶端。微服務架構下，單體應用被切割成多個微服務，如果將所有的微服務直接對外暴露，勢必會出現安全方面的各種問題，另外內外耦合嚴重。關注公眾號：“碼猿技術專欄”，回復關鍵詞：“1111” 獲取阿里內部調優手冊

• 客戶端可以直接向每個微服務發送請求，其問題主要如下：
• 客戶端需求和每個微服務暴露的細粒度API 不匹配。
• 部分服務使用的協議不是Web友好協議。可能使用Thrift 二進制RPC，也可能使用AMQP 消息傳遞協議。

微服務難以重構。如果合併兩個服務，或者將一個服務拆分成兩個或更多服務，這類重構就非常困難了。

服務端的各個服務直接暴露給客戶端調用勢必會引起各種問題。同時，服務端的各個服務可擴展和伸縮性很差。API 網關是微服務架構中的基礎組件，位於接入層之下和業務服務層之上，如前所述的這些功能適合在API 網關實現。

網關與服務器集群

回到我們服務器上，下面圖介紹了網關(Gateway)作用，可知Gateway 方式下的架構，可以細到為每一個服務的實例配置一個自己的Gateway，也可以粗到為一組服務配置一個，甚至可以粗到為整個架構配置一個接入的Gateway。於是，整個系統架構的複雜度就會變得簡單可控起來。

這張圖展示了一個多層Gateway 架構，其中有一個總的Gateway 接入所有的流量(流量網關)，並分發給不同的子系統，還有第二級Gateway 用於做各個子系統的接入Gateway(業務網關)。可以看到，網關所管理的服務粒度可粗可細。通過網關，我們可以把分佈式架構組織成一個星型架構，由網絡對服務的請求進行路由和分發。下面來聊聊好的網關應該具備哪些功能，也就是網關設計模式。

網關設計思路

一個網關需要有以下的功能:

1. 請求路由

網關一定要有請求路由的功能。這樣一來，對於調用端來說，也是一件非常方便的事情。因為調用端不需要知道自己需要用到的其它服務的地址，全部統一地交給Gateway 來處理。

2. 服務註冊

為了能夠代理後面的服務，並把請求路由到正確的位置上，網關應該有服務註冊功能，也就是後端的服務實例可以把其提供服務的地址註冊、取消註冊。一般來說，註冊也就是註冊一些API 接口。比如，HTTP 的Restful 請求，可以註冊相應API 的URI、方法、HTTP 頭。這樣，Gateway 就可以根據接收到的請求中的信息來決定路由到哪一個後端的服務上。

3. 負載均衡

因為一個網關可以接收多個服務實例，所以網關還需要在各個對等的服務實例上做負載均衡策略。簡單點就是直接Round-Robin 輪詢，複雜點的可以設置上權重進行分發，再复雜一點還可以做到session 粘連。

4. 彈力設計

網關還可以把彈力設計中的那些異步、重試、冪等、流控、熔斷、監視等都可以實現進去。這樣，同樣可以像Service Mesh 那樣，讓應用服務只關心自己的業務邏輯（或是說數據面上的事）而不是控制邏輯（控制面）。

5. 安全方面

SSL 加密及證書管理、Session 驗證、授權、數據校驗，以及對請求源進行惡意攻擊的防範。錯誤處理越靠前的位置就是越好，所以，網關可以做到一個全站的接入組件來對後端的服務進行保護。當然，網關還可以做更多更有趣的事情，比如：灰度發布、API聚合、API編排。

灰度發布

網關完全可以做到對相同服務不同版本的實例進行導流，還可以收集相關的數據。這樣對於軟件質量的提升，甚至產品試錯都有非常積極的意義。

API 聚合

使用網關可以將多個單獨請求聚合成一個請求。在微服務體系的架構中，因為服務變小了，所以一個明顯的問題是，客戶端可能需要多次請求才能得到所有的數據。這樣一來，客戶端與後端之間的頻繁通信會對應用程序的性能和規模產生非常不利的影響。於是，我們可以讓網關來幫客戶端請求多個後端的服務（有些場景下完全可以並發請求），然後把後端服務的響應結果拼裝起來，回傳給客戶端（當然，這個過程也可以做成異步的，但這需要客戶端的配合）。

API 編排

同樣在微服務的架構下，要走完一個完整的業務流程，我們需要調用一系列API，就像一種工作流一樣，這個事完全可以通過網頁來編排這個業務流程。我們可能通過一個DSL 來定義和編排不同的API，也可以通過像AWS Lambda 服務那樣的方式來串聯不同的API。

網關設計重點

網關設計重點主要是三個， 高性能、高可用、高擴展:

1. 高性能

在技術設計上，網關不應該也不能成為性能的瓶頸。對於高性能，最好使用高性能的編程語言來實現，如C、C++、Go 和Java。網關對後端的請求，以及對前端的請求的服務一定要使用異步非阻塞的I/O 來確保後端延遲不會導致應用程序中出現性能問題。C 和C++ 可以參看Linux 下的epoll 和Windows 的I/O Completion Port 的異步IO 模型，Java 下如Netty、Spring Reactor 的NIO 框架。

2. 高可用

因為所有的流量或調用經過網關，所以網關必須成為一個高可用的技術組件，它的穩定直接關係到了所有服務的穩定。網關如果沒有設計，就會成變一個單點故障。因此，一個好的網關至少要做到以下幾點。

• 集群化。網關要成為一個集群，其最好可以自己組成一個集群，並可以自己同步集群數據，而不需要依賴於一個第三方系統來同步數據。
• 服務化。網關還需要做到在不間斷的情況下修改配置，一種是像Nginx reload 配置那樣，可以做到不停服務，另一種是最好做到服務化。也就是說，得要有自己的Admin API 來在運行時修改自己的配置。
• 持續化。比如重啟，就是像Nginx 那樣優雅地重啟。有一個主管請求分發的主進程。當我們需要重啟時，新的請求被分配到新的進程中，而老的進程處理完正在處理的請求後就退出。

3. 高擴展

因為網關需要承接所有的業務流量和請求，所以一定會有或多或少的業務邏輯。而我們都知道，業務邏輯是多變和不確定的。比如，需要在網關上加入一些和業務相關的東西。因此，一個好的Gateway 還需要是可以擴展的，並能進行二次開發的。當然，像Nginx 那樣通過Module 進行二次開發的固然可以。

另外，在運維方面，網關應該有以下幾個設計原則。

• 業務松耦合，協議緊耦合。在業務設計上，網關不應與後面的服務之間形成服務耦合，也不應該有業務邏輯。網關應該是在網絡應用層上的組件，不應該處理通訊協議體，只應該解析和處理通訊協議頭。另外，除了服務發現外，網關不應該有第三方服務的依賴。
• 應用監視，提供分析數據。網關上需要考慮應用性能的監控，除了有相應後端服務的高可用的統計之外，還需要使用Tracing ID 實施分佈式鏈路跟踪，並統計好一定時間內每個API 的吞吐量、響應時間和返回碼，以便啟動彈力設計中的相應策略。
• 用彈力設計保護後端服務。網關上一定要實現熔斷、限流、重試和超時等彈力設計。如果一個或多個服務調用花費的時間過長，那麼可接受超時並返回一部分數據，或是返回一個網關里的緩存的上一次成功請求的數據。你可以考慮一下這樣的設計。
• DevOps。因為網關這個組件太關鍵了，所以需要DevOps 這樣的東西，將其發生故障的概率降到最低。這個軟件需要經過精良的測試，包括功能和性能的測試，還有浸泡測試。還需要有一系列自動化運維的管控工具。

網關設計注意事項

• 不要在網關中的代碼里內置聚合後端服務的功能，而應考慮將聚合服務放在網關核心代碼之外。可以使用Plugin 的方式，也可以放在網關後面形成一個Serverless 服務。關注公眾號：“碼猿技術專欄”，回復關鍵詞：“1111” 獲取阿里內部調優手冊
• 網關應該靠近後端服務，並和後端服務使用同一個內網，這樣可以保證網關和後端服務調用的低延遲，並可以減少很多網絡上的問題。這裡多說一句，網關處理的靜態內容應該靠近用戶（應該放到CDN 上），而網關和此時的動態服務應該靠近後端服務。
• 網關也需要做容量擴展，所以需要成為一個集群來分擔前端帶來的流量。這一點，要么通過DNS 輪詢的方式實現，要么通過CDN 來做流量調度，或者通過更為底層的性能更高的負載均衡設備。
• 對於服務發現，可以做一個時間不長的緩存，這樣不需要每次請求都去查一下相關的服務所在的地方。當然，如果你的系統不復雜，可以考慮把服務發現的功能直接集成進網關中。
• 為網關考慮bulkhead 設計方式。用不同的網關服務不同的後端服務，或是用不同的網關服務前端不同的客戶。

另外，因為網關是為用戶請求和後端服務的橋接裝置，所以需要考慮一些安全方面的事宜。具體如下：

• 加密數據。可以把SSL 相關的證書放到網關上，由網關做統一的SSL 傳輸管理。
• 校驗用戶的請求。一些基本的用戶驗證可以放在網關上來做，比如用戶是否已登錄，用戶請求中的token 是否合法等。但是，我們需要權衡一下，網關是否需要校驗用戶的輸入。因為這樣一來，網關就需要從只關心協議頭，到需要關心協議體。而協議體中的東西一方面不像協議頭是標準的，另一方面解析協議體還要耗費大量的運行時間，從而降低網關的性能。對此，我想說的是，看具體需求，一方面如果協議體是標準的，那麼可以乾；另一方面，對於解析協議所帶來的性能問題，需要做相應的隔離。
• 檢測異常訪問。網關需要檢測一些異常訪問，比如，在一段比較短的時間內請求次數超過一定數值；還比如，同一客戶端的4xx 請求出錯率太高……對於這樣的一些請求訪問，網關一方面要把這樣的請求屏蔽掉，另一方面需要發出警告，有可能會是一些比較重大的安全問題，如被黑客攻擊。

流量網關

流量網關，顧名思義就是控制流量進入集群的網關，有很多工作需要在這一步做，對於一個服務集群，勢必有很多非法的請求或者無效的請求，這時候要將請求拒之門外，降低集群的流量壓力。

定義全局性的、跟具體的後端業務應用和服務完全無關的策略網關就是上圖所示的架構模型——流量網關。流量網關通常只專注於全局的Api管理策略，比如全局流量監控、日誌記錄、全局限流、黑白名單控制、接入請求到業務系統的負載均衡等，有點類似防火牆。Kong 就是典型的流量網關。

下面是kong的架構圖，來自官網：https://konghq.com

這裡需要補充一點的是，業務網關一般部署在流量網關之後、業務系統之前，比流量網關更靠近業務系統。通常API網指的是業務網關。有時候我們也會模糊流量網關和業務網關，讓一個網關承擔所有的工作，所以這兩者之間並沒有嚴格的界線。

業務網關

當一個單體應用被拆分成許許多多的微服務應用後，也帶來了一些問題。一些與業務非強相關的功能，比如權限控制、日誌輸出、數據加密、熔斷限流等，每個微服務應用都需要，因此存在著大量重複的代碼實現。而且由於系統的迭代、人員的更替，各個微服務中這些功能的實現細節出現了較大的差異，導致維護成本變高。另一方面，原先單體應用下非常容易做的接口管理，在服務拆分後沒有了一個集中管理的地方，無法統計已存在哪些接口、接口定義是什麼、運行狀態如何。

網關就是為了解決上述問題。作為微服務體系中的核心基礎設施，一般需要具備接口管理、協議適配、熔斷限流、安全防護等功能，各種開源的網關產品（比如zuul）都提供了優秀高可擴展性的架構、可以很方便的實現我們需要的一些功能、比如鑑權、日誌監控、熔斷限流等。

與流量網關相對應的就是業務網關，業務網關更靠近我們的業務，也就是與服務器應用層打交道，那麼有很多應用層需要考慮的事情就可以依託業務網關，例如在線程模型、協議適配、熔斷限流，服務編排等。下面看看業務網關體系結構:

從這個途中可以看出業務網關主要職責以及所做的事情， 目前業務網關比較成熟的API 網關框架產品有三個分別是:Zuul1、Zuul2 和SpringCloud Gateway， 後面再進行對比。

常見網關對比

既然對比，就先宏觀上對各種網關有一個了解，後面再挑一些常用的或者說應用廣泛的詳細了解。

目前常見的開源網關大致上按照語言分類有如下幾類：

• Nginx+lua：OpenResty、Kong、Orange、Abtesting gateway 等
• Java：Zuul/Zuul2、Spring Cloud Gateway、Kaazing KWG、gravitee、Dromara soul 等
• Go：Janus、fagongzi、Grpc-gateway
• Dotnet：Ocelot
• NodeJS：Express Gateway、Micro Gateway

按照使用數量、成熟度等來劃分，主流的有5個：

• OpenResty
• Kong
• Zuul、Zuul2
• Spring Cloud Gateway

1. OpenResty

OpenResty是一個流量網關，根據前面對流量網關的介紹就可以知道流量網關的指責。

OpenResty基於Nginx與Lua 的高性能Web 平台，其內部集成了大量精良的Lua 庫、第三方模塊以及大多數的依賴項。用於方便地搭建能夠處理超高並發、擴展性極高的動態Web 應用、Web 服務和動態網關。關注公眾號：“碼猿技術專欄”，回復關鍵詞：“1111” 獲取阿里內部調優手冊

通過揉和眾多設計良好的Nginx 模塊，OpenResty 有效地把Nginx 服務器轉變為一個強大的Web 應用服務器，基於它開發人員可以使用Lua 編程語言對Nginx 核心以及現有的各種Nginx C 模塊進行腳本編程，構建出可以處理一萬以上並發請求的極端高性能的Web 應用

OpenResty 最早是順應OpenAPI 的潮流做的，所以Open 取自“開放”之意，而Resty便是REST 風格的意思。雖然後來也可以基於ngx_openresty 實現任何形式的web service 或者傳統的web 應用。

也就是說Nginx 不再是一個簡單的靜態網頁服務器，也不再是一個簡單的反向代理了。第二代的openresty 致力於通過一系列nginx 模塊，把nginx擴展為全功能的web 應用服務器。

ngx_openresty 是用戶驅動的項目，後來也有不少國內用戶的參與，從openresty.org 的點擊量分佈上看，國內和國外的點擊量基本持平。

ngx_openresty 目前有兩大應用目標：

• 通用目的的web 應用服務器。在這個目標下，現有的web 應用技術都可以算是和OpenResty 或多或少有些類似，比如Nodejs， PHP 等等。ngx_openresty 的性能（包括內存使用和CPU 效率）算是最大的賣點之一。
• Nginx 的腳本擴展編程，用於構建靈活的Web 應用網關和Web 應用防火牆。有些類似的是NetScaler。其優勢在於Lua 編程帶來的巨大靈活性。

2. Kong

Kong基於OpenResty開發，也是流量層網關， 是一個雲原生、快速、可擴展、分佈式的Api 網關。繼承了OpenResty的高性能、易擴展性等特點。Kong通過簡單的增加機器節點，可以很容易的水平擴展。同時功能插件化，可通過插件來擴展其能力。而且在任何基礎架構上都可以運行。具有以下特性：

• 提供了多樣化的認證層來保護Api。
• 可對出入流量進行管制。
• 提供了可視化的流量檢查、監視分析Api。
• 能夠及時的轉換請求和相應。
• 提供log解決方案
• 可通過api調用Serverless 函數。
• Kong解決了什麼問題

當我們決定對應用進行微服務改造時，應用客戶端如何與微服務交互的問題也隨之而來，畢竟服務數量的增加會直接導致部署授權、負載均衡、通信管理、分析和改變的難度增加。

面對以上問題，API GATEWAY是一個不錯的解決方案，其所提供的訪問限制、安全、流量控制、分析監控、日誌、請求轉發、合成和協議轉換功能，可以解放開發者去把精力集中在具體邏輯的代碼，而不是把時間花費在考慮如何解決應用和其他微服務鏈接的問題上。

圖片來自Kong官網:

可以看到Kong解決的問題。專注於全局的Api管理策略，全局流量監控、日誌記錄、全局限流、黑白名單控制、接入請求到業務系統的負載均衡等。

Kong的優點以及性能

在眾多API GATEWAY 框架中，Mashape 開源的高性能高可用API網關和API服務管理層——KONG（基於NGINX+Lua）特點尤為突出，它可以通過插件擴展已有功能，這些插件（使用lua 編寫）在API請求響應循環的生命週期中被執行。於此同時，KONG本身提供包括HTTP 基本認證、密鑰認證、CORS、TCP、UDP、文件日誌、API請求限流、請求轉發及NGINX 監控等基本功能。目前，Kong 在Mashape 管理了超過15，000 個API，為200，000 開發者提供了每月數十億的請求支持。

Kong架構

Kong提供一些列的服務，這就不得不談談內部的架構:

首先最底層是基於Nginx， Nginx是高性能的基礎層， 一個良好的負載均衡、反向代理器，然後在此基礎上增加Lua腳本庫，形成了OpenResty，攔截請求， 響應生命週期，可以通過Lua編寫腳本，所以插件比較豐富。

關於Kong的一些插件庫以及如何配置，可以參考簡書:開源API網關係統（Kong教程）入門到精通：https://www.jianshu.com/p/a68e45bcadb6

3. Zuul1.0

Zuul是所有從設備和web站點到Netflix流媒體應用程序後端請求的前門。作為一個邊緣服務應用程序，Zuul被構建來支持動態路由、監視、彈性和安全性。它還可以根據需要將請求路由到多個Amazon自動伸縮組。

Zuul使用了一系列不同類型的過濾器，使我們能夠快速靈活地將功能應用到服務中。

過濾器

過濾器是Zuul的核心功能。它們負責應用程序的業務邏輯，可以執行各種任務。

• Type：通常定義過濾器應用在哪個階段
• Async：定義過濾器是同步還是異步
• Execution Order：執行順序
• Criteria：過濾器執行的條件
• Action：如果條件滿足，過濾器執行的動作

Zuul提供了一個動態讀取、編譯和運行這些過濾器的框架。過濾器之間不直接通信，而是通過每個請求特有的RequestContext共享狀態。

下面是Zuul的一些過濾器:

Incoming

Incoming過濾器在請求被代理到Origin之前執行。這通常是執行大部分業務邏輯的地方。例如:認證、動態路由、速率限制、DDoS保護、指標。

Endpoint

Endpoint過濾器負責基於incoming過濾器的執行來處理請求。Zuul有一個內置的過濾器（ProxyEndpoint），用於將請求代理到後端服務器，因此這些過濾器的典型用途是用於靜態端點。例如:健康檢查響應，靜態錯誤響應，404響應。

Outgoing

Outgoing過濾器在從後端接收到響應以後執行處理操作。通常情況下，它們更多地用於形成響應和添加指標，而不是用於任何繁重的工作。例如:存儲統計信息、添加/剝離標準標題、向實時流發送事件、gziping響應。

過濾器類型

下面是與一個請求典型的生命週期對應的標準的過濾器類型：

• PRE：路由到Origin之前執行
• ROUTING：路由到Origin期間執行
• POST：請求被路由到Origin之後執行
• ERROR：發生錯誤的時候執行

這些過濾器幫助我們執行以下功能：

• 身份驗證和安全性：識別每個資源的身份驗證需求，並拒絕不滿足它們的請求
• 監控：在邊緣跟踪有意義的數據和統計數據，以便給我們一個準確的生產視圖
• 動態路由：動態路由請求到不同的後端集群
• 壓力測試：逐漸增加集群的流量，以評估性能
• 限流：為每種請求類型分配容量，並丟棄超過限制的請求
• 靜態響應處理：直接在邊緣構建一些響應，而不是將它們轉發到內部集群

Zuul 1.0 請求生命週期

Netflix宣布了通用API網關Zuul的架構轉型。Zuul原本採用同步阻塞架構，轉型後叫作Zuul2，採用異步非阻塞架構。Zuul2和Zuul1在架構方面的主要區別在於，Zuul2運行在異步非阻塞的框架上，比如Netty。Zuul1依賴多線程來支持吞吐量的增長，而Zuul 2使用的Netty框架依賴事件循環和回調函數。

4. Zuul2.0

Zuul 2.0 架構圖

上圖是Zuul2的架構，和Zuul1沒有本質區別，兩點變化：

• 前端用Netty Server代替Servlet，目的是支持前端異步。後端用Netty Client代替Http Client，目的是支持後端異步。
• 過濾器換了一下名字，用Inbound Filters代替Pre-routing Filters，用Endpoint Filter代替Routing Filter，用Outbound Filters代替Post-routing Filters。

Inbound Filters ：路由到Origin 之前執行，可以用於身份驗證、路由和裝飾請求

Endpoint Filters ：可用於返回靜態響應，否則內置的ProxyEndpoint過濾器將請求路由到Origin

Outbound Filters ：從Origin那裡獲取響應後執行，可以用於度量、裝飾用戶的響應或添加自定義header

有兩種類型的過濾器：sync 和async。因為Zuul是運行在一個事件循環之上的，因此從來不要在過濾中阻塞。如果你非要阻塞，可以在一個異步過濾器中這樣做，並且在一個單獨的線程池上運行，否則可以使用同步過濾器。

上文提到過Zuul2開始採用了異步模型

優勢是異步非阻塞模式啟動的線程很少，基本上一個CPU core上只需啟一個事件環處理線程，它使用的線程資源就很少，上下文切換(Context Switch)開銷也少。非阻塞模式可以接受的連接數大大增加，可以簡單理解為請求來了只需要進隊列，這個隊列的容量可以設得很大，只要不超時，隊列中的請求都會被依次處理。

不足，異步模式讓編程模型變得複雜。一方面Zuul2本身的代碼要比Zuul1複雜很多，Zuul1的代碼比較容易看懂，Zuul2的代碼看起來就比較費勁。另一方面異步模型沒有一個明確清晰的請求->處理->響應執行流程(call flow)，它的流程是通過事件觸發的，請求處理的流程隨時可能被切換斷開，內部實現要通過一些關聯id機制才能把整個執行流再串聯起來，這就給開發調試運維引入了很多複雜性，比如你在IDE裡頭調試異步請求流就非常困難。另外ThreadLocal機制在這種異步模式下就不能簡單工作，因為只有一個事件環線程，不是每個請求一個線程，也就沒有線程局部的概念，所以對於CAT這種依賴於ThreadLocal才能工作的監控工具，調用鏈埋點就不好搞(實際可以工作但需要進行特殊處理)。

總體上，異步非阻塞模式比較適用於IO密集型(IO bound)場景，這種場景下系統大部分時間在處理IO，CPU計算比較輕，少量事件環線程就能處理。

Zuul 與Zuul 2 性能對比

Netflix給出了一個比較模糊的數據，大致Zuul2的性能比Zuul1好20%左右，這裡的性能主要指每節點每秒處理的請求數。為什麼說模糊呢？因為這個數據受實際測試環境，流量場景模式等眾多因素影響，你很難復現這個測試數據。即便這個20%的性能提升是確實的，其實這個性能提升也並不大，和異步引入的複雜性相比，這20%的提升是否值得是個問題。Netflix本身在其博文22和ppt11中也是有點含糊其詞，甚至自身都有一些疑問的。

5. Spring Cloud Gateway

SpringCloud Gateway 是Spring Cloud 的一個全新項目，該項目是基於Spring 5.0，Spring Boot 2.0 和Project Reactor 等技術開發的網關，它旨在為微服務架構提供一種簡單有效的統一的API 路由管理方式。

SpringCloud Gateway 作為Spring Cloud 生態系統中的網關，目標是替代Zuul，在Spring Cloud 2.0以上版本中，沒有對新版本的Zuul 2.0以上最新高性能版本進行集成，仍然還是使用的Zuul 2.0之前的非Reactor模式的老版本。而為了提升網關的性能，SpringCloud Gateway是基於WebFlux框架實現的，而WebFlux框架底層則使用了高性能的Reactor模式通信框架Netty。

Spring Cloud Gateway 的目標，不僅提供統一的路由方式，並且基於Filter 鏈的方式提供了網關基本的功能，例如：安全，監控/指標，和限流。

Spring Cloud Gateway 底層使用了高性能的通信框架Netty。

SpringCloud Gateway 特徵

SpringCloud官方，對SpringCloud Gateway 特徵介紹如下：

（1）基於Spring Framework 5，Project Reactor 和Spring Boot 2.0

（2）集成Hystrix 斷路器

（3）集成Spring Cloud DiscoveryClient

（4）Predicates 和Filters 作用於特定路由，易於編寫的Predicates 和Filters

（5）具備一些網關的高級功能：動態路由、限流、路徑重寫

從以上的特徵來說，和Zuul的特徵差別不大。SpringCloud Gateway和Zuul主要的區別，還是在底層的通信框架上。

簡單說明一下上文中的三個術語：

Filter（過濾器）

和Zuul的過濾器在概念上類似，可以使用它攔截和修改請求，並且對上游的響應，進行二次處理。過濾器為org.springframework.cloud.gateway.filter.GatewayFilter類的實例。

Route（路由）

網關配置的基本組成模塊，和Zuul的路由配置模塊類似。一個Route模塊由一個ID，一個目標URI，一組斷言和一組過濾器定義。如果斷言為真，則路由匹配，目標URI會被訪問。

Predicate（斷言）：

這是一個Java 8 的Predicate，可以使用它來匹配來自HTTP 請求的任何內容，例如headers 或參數。斷言的輸入類型是一個ServerWebExchange。

幾種網關的對比

大號好友坑位已滿，新開了一個小號，有問題諮詢或者想和陳某做朋友圈點讚之交的可以加我好友