前面講過zuul的閘道器實現，那為什麼今天又要講Spring Cloud Gateway呢？原因很簡單。就是Spring Cloud已經放棄Netflix Zuul了。現在Spring Cloud中引用的還是Zuul 1.x版本，而這個版本是基於過濾器的，是阻塞IO，不支援長連線。Zuul 2.x版本跟1.x的架構大一樣，效能也有所提升。既然Spring Cloud已經不再整合Zuul 2.x了，那麼我今天也就再講解一下Spring Cloud Gateway了。
1. API閘道器
API閘道器是一個伺服器，是系統的唯一入口。從物件導向設計的角度看，它與外觀模式類似。API閘道器封裝了系統內部架構，為每個客戶端提供一個定製的API。它可能還具有其它職責，如身份驗證、監控、負載均衡、快取、請求分片與管理、靜態響應處理。API閘道器方式的核心要點是，所有的客戶端和消費端都通過統一的閘道器接入微服務，在閘道器層處理所有的非業務功能。通常，閘道器也是提供REST/HTTP的訪問API。
閘道器應當具備以下功能：
-
效能：API高可用，負載均衡，容錯機制。
-
安全：許可權身份認證、脫敏，流量清洗，後端簽名（保證全鏈路可信呼叫）,黑名單（非法呼叫的限制）。
-
日誌：日誌記錄（spainid,traceid）一旦涉及分散式，全鏈路跟蹤必不可少。
-
快取：資料快取。
-
監控：記錄請求響應資料，api耗時分析，效能監控。
-
限流：流量控制，錯峰流控，可以定義多種限流規則。
-
灰度：線上灰度部署，可以減小風險。
-
路由：動態路由規則。
2，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主要的區別，還是在底層的通訊框架上。
簡單說明一下上文中的三個術語：
**1）Filter（過濾器）**：
和Zuul的過濾器在概念上類似，可以使用它攔截和修改請求，並且對上游的響應，進行二次處理。過濾器為org.springframework.cloud.gateway.filter.GatewayFilter類的例項。
**2）Route（路由）**：
閘道器配置的基本組成模組，和Zuul的路由配置模組類似。一個Route模組由一個 ID，一個目標 URI，一組斷言和一組過濾器定義。如果斷言為真，則路由匹配，目標URI會被訪問。
**3）Predicate（斷言）**：
這是一個 Java 8 的 Predicate，可以使用它來匹配來自 HTTP 請求的任何內容，例如 headers 或引數。斷言的輸入型別是一個 ServerWebExchange。
3，搭建配置
首先我們基於之前的演示專案，再建立一個gateway-service模組，新增依賴：
然後建立啟動類：
配置Gateway路由資訊：
1，通過yml配置實現
2，通過程式碼實現，在啟動類裡建立Route例項的配置類GatewayRoutes
然後啟動服務測試，按順序啟動，依次啟動eureka-server、customer-service、order-service、gateway-service。然後登入eureka客戶端。
所有服務正常啟動，請求介面測試。
1，測試customer服務介面
2，測試order服務介面
今天由於時間關係，先說到這裡，接下來會繼續詳細講一些配置，熔斷、限流、監控等系列內容。以及redis、MQ等接入應用。
推薦閱讀：
SpringCloud微服務專案實戰 - 閘道器zuul詳解及搭建
SpringCloud微服務專案實戰 - 微服務呼叫詳解（附面試題）
SpringCloud微服務專案實戰，服務註冊與發現（附面試題）
Spring Cloud微服務專案實戰--Eureka服務搭建
掃碼關注公眾號，傳送關鍵詞獲取相關資料：
-
發“Springboot”領取電商專案實戰原始碼;
-
發“SpringCloud”領取學習實戰資料;
