這個要理解為什麼做閘道器。簡單扼要來講，就是為了處理每個服務都要做的事情。你可以認為是切面變成了服務。

路由，協議轉換，鑑權認證，熔斷，限流。這些邏輯和你實際的業務程式碼沒太大關係，但是每個業務服務都要搞一個，顯得很累贅重複。那怎麼辦呢？

兩種解決思路。

一，使用gateway服務，所有的服務均接入和呼叫這個gateway，由gateway把這些通用問題處理了，再去請求實際的業務邏輯。gateway是關鍵節點，瓶頸節點。spring cloud gateway也是這樣。它連線了系統的所有方方面面，是個大管家。除了spring cloud gateway，其他的代表還有netty，kong，zuul等

圖侵刪

二，整合到本地，可以用sidecar，類似一個代理伺服器。sidecar就是那種有拖斗的三輪摩托車，旁邊的那個人輔助給你觀察。下面是sidecar的架構。

圖侵刪

啊不對，放錯了。應該是下面這個。

圖侵刪

其實萬變不離其宗。首先，你確認有一些邏輯是通用的（鑑權，限流，路由），再是你提取了出來（變成了AOP切面邏輯），然後你把他寫成一個單獨的服務給這個服務用（sidecar），最後，你把這個服務給所有服務用（gateway）。

淺顯的理解就是這樣。

先讓我們看這樣一個場景吧，一個電商網站做了服務化，後端服務分別拆成了使用者服務、商品服務、支付服務、物流服務（為了舉例，做了簡化，實際場景會遠比這個複雜）；前端有網頁版和 APP，前端的所有操作都需要呼叫後端的各個服務。

在這個過程中，可能會有這樣的問題：

前端應用需要知道後端每個服務的地址，或者必須接入服務中心；但是服務的地址和埠可能會動態變化。

每個服務的技術棧必須相同，遵守相同的介面規範，介面協議必須相同，否則對於前度極度不友好。

網頁版和 APP 展示相同的內容時，可能粒度不同，要麼服務端提供粗粒度和細粒度兩種 API，要麼只提供一組最細粒度的 API，前者增加了後端的開發量，後者可能會導致一次前端需要多次呼叫細粒度的 API，才能得到想要的資料。

不同的客戶端裝置展示的資料不同，比如網頁版能展示的資料更詳細一些，APP 展示的資料少，那麼也會有“提供一個大而全的介面”還是“為不同的呼叫方提供不同介面”的問題。

日誌、認證和鑑權、計費、監控等等功能，需要各個後端來完善，或者接入到對應的公共元件中（接入也是需要開發的），這就多多少少增加了後端服務的工作。

API Gateway 就是為了解決以上種種問題的；API Gateway 是系統的唯一入口，它遮蔽掉了系統的內部架構，為呼叫方定製了統一的 API。

把後端各個服務的 API 聚合起來，提供統一且唯一規範的入口，這樣使得內部的架構對於呼叫方透明，客戶端和服務端的耦合度降低；各個後端服務之間，可以採用不同的實現方案，而 API Gateway 會遮蔽掉這些差異；

後端的每個服務也都是在不斷迭代和升級的，API Gateway 可以將請求路由到不同的介面版本上，可以實現灰度釋出；

API Gateway 可以進行服務編排，實現資料聚合，也就是呼叫方一次請求，API Gateway 呼叫多個服務拿到資料後返回；

API Gateway 知道所有服務例項的地址，可以對不同的服務採用不同的路由策略；

日誌、認證和鑑權、計費、監控等等功能都可以在 API Gateway 上實現；

API Gateway 還可以對流量進行控制，通過熔斷、降級、限流等方式，保護後端服務。

一、微服務和Spring Cloud介紹

微服務，關鍵其實不僅僅是微服務本身，而是系統要提供一套基礎的架構，這種架構使得微服務可以獨立的部署、執行、升級，不僅如此，這個系統架構還讓微服務與微服務之間在結構上“鬆耦合”，而在功能上則表現為一個統一的整體。這種所謂的“統一的整體”表現出來的是統一風格的介面，統一的許可權管理，統一的安全策略，統一的上線過程，統一的日誌和審計方法，統一的排程方式，統一的訪問入口等。微服務的目的是有效的拆分應用，實現敏捷開發和部署 。

Spring Cloud是一系列框架的有序集合。它利用Spring Boot的開發便利性巧妙地簡化了分散式系統基礎設施的開發，如服務發現註冊、配置中心、訊息匯流排、負載均衡、斷路器、資料監控等，都可以用Spring Boot的開發風格做到一鍵啟動和部署。Spring Cloud並沒有重複製造輪子，它只是將各家公司開發的比較成熟、經得起實際考驗的服務框架組合起來，通過Spring Boot風格進行再封裝遮蔽掉了複雜的配置和實現原理，最終給開發者留出了一套簡單易懂、易部署和易維護的分散式系統開發工具包。

採用API閘道器，實現一個API閘道器接管所有的入口流量，是系統的唯一入口，將所有使用者的請求轉發給後端的伺服器，但閘道器做的不僅僅只是簡單的轉發，也會針對流量做一些擴充套件。從面向物件設計的角度看，它與外觀模式類似。API閘道器封裝了系統內部架構，為每個客戶端提供一個定製的API。

比如鑑權、限流、許可權、熔斷、協議轉換、錯誤碼統一、快取、日誌、監控、告警等，這樣將通用的邏輯抽出來，由閘道器統一去做，業務方也能夠更專注於業務邏輯，提升迭代的效率。

通過引入API閘道器，客戶端只需要與API閘道器互動，而不用與各個業務方的介面分別通訊，但多引入一個元件就多引入了一個潛在的故障點，因此要實現一個高效能、穩定的閘道器，也會涉及到很多點。

API閘道器方式的核心要點是，所有的客戶端和消費端都通過統一的閘道器接入微服務，在閘道器層處理所有的非業務功能。通常，閘道器也是提供REST/HTTP的訪問API。服務端通過API-GW註冊和管理服務。

使用一個元件時，尤其是這種比較流行的架構，元件肯定存在開源的，我們不必自己去從零開始去實現一個閘道器，自己開發一個閘道器的工作量是相當可觀的，現在比較流行的開源 API：

Spring Cloud Gateway

Spring Cloud Gateway是一款非常實用的微服務閘道器，在Spring Cloud微服務架構體系中發揮非常大的作用。Spring Cloud Gateway 是 Spring Cloud 微服務平臺的一個子專案，屬於 Spring 開源社群，依賴名叫：spring-cloud-starter-gateway。

https://spring.io/projects/spring-cloud-gateway

Spring Cloud Gateway構建於 Spring 5+，基於 Spring Boot 2.x 響應式的、非阻塞式的 API。同時，它支援 websockets，和 Spring 框架緊密整合，開發體驗相對來說十分不錯。

Zuul

Zuul 是 Netflix 公司的開源專案，Spring Cloud 在 Netflix 專案中也已經集成了 Zuul，依賴名叫：spring-cloud-starter-netflix-zuul。

https://github.com/Netflix/zuul

Spring Cloud Gateway閘道器和Zuul閘道器對比

閘道器提供API全託管服務，豐富的API管理功能，輔助企業管理大規模的API，以降低管理成本和安全風險，包括協議適配、協議轉發、安全策略、防刷、流量、監控日誌等貢呢。一般來說閘道器對外暴露的URL或者介面資訊，我們統稱為路由資訊。如果研發過閘道器中介軟體或者使用過Zuul的人，會知道閘道器的核心是Filter以及Filter Chain（Filter責任鏈）。Sprig Cloud Gateway也具有路由和Filter的概念。

Spring Cloud Gateway主要特性：

基於Spring Framework 5、Project Reactor和Spring Boot 2.0構建

能夠在任意請求屬性上匹配路由

predicates（謂詞） 和 filters（過濾器）是特定於路由的

集成了Hystrix斷路器

集成了Spring Cloud DiscoveryClient

易於編寫謂詞和過濾器

請求速率限制

路徑重寫

下面介紹一下Spring Cloud Gateway中幾個重要的概念。

路由。路由是閘道器最基礎的部分，路由資訊有一個ID、一個目的URL、一組斷言和一組Filter組成。如果斷言路由為真，則說明請求的URL和配置匹配

斷言。Java8中的斷言函式。Spring Cloud Gateway中的斷言函式輸入型別是Spring5.0框架中的ServerWebExchange。Spring Cloud Gateway中的斷言函式允許開發者去定義匹配來自於http request中的任何資訊，比如請求頭和引數等。

過濾器。一個標準的Spring webFilter。Spring cloud gateway中的filter分為兩種型別的Filter，分別是Gateway Filter和Global Filter。過濾器Filter將會對請求和響應進行修改處理。

如上圖所示，Spring Cloud Gateway發出請求。然後再由Gateway Handler Mapping中找到與請求相匹配的路由，將其傳送到Gateway web handler。Handler再通過指定的過濾器鏈將請求傳送到我們實際的服務執行業務邏輯，然後返回。

SpringCloudGateway和SpringCloudZuul一樣是微服務閘道器，不過Gateway是SpringCloud官方推出的，而Zuul是Netflix推出的。

看其他人的一些文章說是Gateway是用於取代Zuul的第二代閘道器，這個我在官方找不到資料說明。

主要術語

default-filters: 裡面可以定義一些共同的filter，對所有路由都起作用

routes：具體的路由資訊，是一個數組，每一個路由基本包含部分：

id：這個路由的唯一id，不定義的話為一個uuid

uri：http請求為lb://字首 + 服務id；ws請求為lb:ws://字首 + 服務id；表示將請求負載到哪一個服務上

predicates：表示這個路由的請求匹配規則，只有符合這個規則的請求才會走這個路由。為一個數組，每個規則為並且的關係。

order：這個路由的執行order

閘道器請求

SpringCloudGateway限流原理與實踐

快取、降級和限流是開發高併發系統的三把利器。快取的目的是提升系統訪問速度和增大系統能處理的容量，可謂是抗高併發流量的銀彈；降級是當服務出現問題或者影響到核心流程的效能則需要暫時遮蔽，待高峰或者問題解決後再開啟；而有些場景並不能用快取和降級來解決，比如稀缺資源、寫服務、頻繁的複雜查詢，因此需有一種手段來限制這些場景的併發/請求量，即限流。

限流的目的是通過對併發訪問/請求進行限速，或對一個時間視窗內的請求進行限速來保護系統。一旦達到限制速率則可以拒絕服務、排隊或等待、降級。

一般開發高併發系統常見的限流有：限制總併發數、限制瞬時併發數、限制時間視窗內的平均速率、限制遠端介面的呼叫速率、限制MQ的消費速率，或根據網路連線數、網路流量、CPU或記憶體負載等來限流。

本文主要就分散式限流方法，對Spring Cloud Gateway的限流原理進行分析。

分散式限流最關鍵的是要將限流服務做成原子化，常見的限流演算法有：令牌桶、漏桶等，Spring Cloud Gateway使用Redis+Lua技術實現高併發和高效能的限流方案。

令牌桶演算法

令牌桶演算法是一個存放固定容量令牌的桶，按照固定速率往桶裡新增令牌。令牌桶演算法的描述如下：

假如使用者配置的平均速率為r，則每隔1/r秒一個令牌被加入到桶中；

假設桶最多可以存發b個令牌。如果令牌到達時令牌桶已經滿了，那麼這個令牌會被丟棄；

演算法允許最長b個位元組的突發，但從長期執行結果看，資料包的速率被限制成常量r。對於在流量限制外的資料包可以以不同的方式處理：

它們可以被丟棄；

它們可以排放在佇列中以便當令牌桶中累積了足夠多的令牌時再傳輸；

它們可以繼續傳送，但需要做特殊標記，網路過載的時候將這些特殊標記的包丟棄。

漏桶演算法

漏桶作為計量工具（The Leaky Bucket Algorithm as a Meter）時，可以用於流量整形（Traffic Shaping）和流量控制（Traffic Policing），漏桶演算法的描述如下：

一個固定容量的漏桶，按照常量固定速率流出水滴；

如果桶是空的，則不需流出水滴；

可以以任意速率流入水滴到漏桶；

如果流入水滴超出了桶的容量，則流入的水滴溢位了（被丟棄），而漏桶容量是不變的。

實踐

SpringCloudGateway限流方案

Spring Cloud Gateway 預設實現 Redis限流，如果擴充套件只需要實現Ratelimter介面即可，同時也可以通過自定義KeyResolver來指定限流的Key,比如我們需要根據使用者、IP、URI來做限流等等，通過exchange物件可以獲取到請求資訊，比如：

使用者限流

public KeyResolver ipKeyResolver() {

return exchange -> Mono.just(exchange.getRequest().getRemoteAddress().getHostName());

}

SpringCloudGateway預設提供的RedisRateLimter 的核心邏輯為判斷是否取到令牌的實現，通過呼叫 META-INF/scripts/request_rate_limiter.lua 指令碼實現基於令牌桶演算法限流

閘道器閘道器，一夫當關萬夫莫開。最重要的意義就是為軟體系統提供安全保障了，人們往往把API鑑權放到閘道器上來做，因為這樣處理簡單高效，而且能夠很好的保護後端應用。這樣能夠很好的控制網路請求，而不必將所有後端服務暴露在外部環境中從而有潛在的安全風險。

其次就是為前端提供了統一的API入口，相當於規範了API路徑，這為前後端API對接提供了很大的便利。使得團隊開發變得高效。所以說這個閘道器還是非常重要滴。

Java開發者都知道大名鼎鼎的Spring，可以這樣說，目前市面上所需要的功能Spring全家桶（Spring、Spring Boot、Spring Cloud）都提供了完美的解決方案。

Spring Cloud它是基於Spring Boot的一款微服務開發框架，它提供了配置管理、服務發現、熔斷器、路由、服務跟蹤及治理等微服務開發一整套的解決方案。

閘道器（Gateway）是任何微服務架構中最為重要的一部分，閘道器就好比是一個門衛，嚴格把關外來訪客與內部微服務之間的溝通聯絡。其實，閘道器是微服務對外的唯一入口！外部發起的所有請求都是要經過閘道器的，由閘道器來決定不同的請求到不同的微服務程式去處理。

Spring Cloud中的閘道器不止一種，Spring Cloud中最早期的閘道器採用的是Zuul，後來改用了Spring Cloud Gateway。

1、Zuul不是Spring Cloud官方推出的

Zuul閘道器其實是Netflix開發的，它是阻塞式API，而且不支援長連線和Websocket，所以是有一定缺陷的。

2、Spring Cloud Gateway是用來替代Zuul閘道器的

Spring 5起就推出了自己的閘道器：Spring Cloud Gateway。它是基於Spring Boot開發的，效能上比Zuul要好，而且在配置及使用上都要比Zuul更方便。

Spring Cloud Gateway是用來替代Zuul閘道器的，是由Spring官方開發維護的，無論在效能還是操作上都優於Zuul。在新一代Spring Cloud專案中推薦使用。