[[407688]]

什么是網關

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

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

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

網關通俗理解

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

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

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

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

為什么需要網關

當使用單體應用程序架構時，客戶端（Web 或移動端）通過向后端應用程序發起一次 REST 調用來獲取數據。負載均衡器將請求路由給 N 個相同的應用程序實例中的一個。然后應用程序會查詢各種數據庫表，并將響應返回給客戶端。微服務架構下，單體應用被切割成多個微服務，如果將所有的微服務直接對外暴露，勢必會出現安全方面的各種問題，另外內外耦合嚴重。

客戶端可以直接向每個微服務發送請求，其問題主要如下：

• 客戶端需求和每個微服務暴露的細粒度API不匹配。
• 部分服務使用的協議不是Web友好協議。可能使用Thrift 二進制 RPC，也可能使用AMQP消息傳遞協議。
• 微服務難以重構。如果合并兩個服務，或者將一個服務拆分成兩個或更多服務，這類重構就非常困難了。

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

網關與服務器集群

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

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

網關設計思路

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

請求路由

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

服務注冊

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

負載均衡

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

彈力設計

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

安全方面

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

灰度發布

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

API 聚合

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

API編排

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

網關設計重點

網關設計重點主要是三個：

高性能

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

高可用

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

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

高擴展

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

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

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

網關設計注意事項

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

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

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

流量網關

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

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

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

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

業務網關

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

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

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

業務網關主要職責以及所做的事情，目前業務網關比較成熟的API網關框架產品有三個，分別是：Zuul 1、Zuul 2和Spring Cloud Gateway后面再進行對比。

常見網關對比

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

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

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

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

• OpenResty
• Kong
• Zuul/Zuul 2
• Spring Cloud Gateway

OpenResty

相關連接：

• 官網： https://openresty.org/cn/
• B站： https://space.bilibili.com/457424101
• GitHub： https://github.com/openresty/

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

OpenResty基于 Nginx 與Lua的高性能Web平臺，其內部集成了大量精良的Lua庫、第三方模塊以及大多數的依賴項。用于方便地搭建能夠處理超高并發、擴展性極高的動態Web應用、Web服務和動態網關。

通過揉和眾多設計良好的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 目前有兩大應用目標：

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

Kong

相關連接：

• 官網： https://konghq.com/
• GitHub： https://github.com/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的一些插件庫以及如何配置，可以參考簡書： https://www.jianshu.com/p/a68e45bcadb6

Zuul 1.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原本采用同步阻塞架構，轉型后叫作Zuul 2，采用異步非阻塞架構。Zuul 2和Zuul 1在架構方面的主要區別在于，Zuul 2運行在異步非阻塞的框架上，比如Netty。Zuul 1依賴多線程來支持吞吐量的增長，而Zuul 2使用的Netty框架依賴事件循環和回調函數。

Zuul 2.0

Zuul 2.0架構圖：

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

• 前端用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是運行在一個事件循環之上的，因此從來不要在過濾中阻塞。如果你非要阻塞，可以在一個異步過濾器中這樣做，并且在一個單獨的線程池上運行，否則可以使用同步過濾器。

上文提到過 Zuul 2開始采用了異步模型 。

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

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

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

Zuul與Zuul 2性能對比

圖片來源： https://www.slideshare.net/art ... cking

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

Spring Cloud Gateway

相關鏈接：

• 官網： https://spring.io/projects/spring-cloud-gateway
• 中文官方文檔： https://cloud.tencent.com/deve ... 03887

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

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

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

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

SpringCloud Gateway特征

Spring Cloud官方，對Spring Cloud Gateway特征介紹如下：

• 基于Spring Framework 5，Project Reactor和Spring Boot 2.0
• 集成Hystrix斷路器
• 集成Spring Cloud DiscoveryClient
• Predicates和Filters作用于特定路由，易于編寫的Predicates和Filters
• 具備一些網關的高級功能：動態路由、限流、路徑重寫

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

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

Filter（過濾器）

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

Route（路由）

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

Predicate（斷言）

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

幾種網關的對比