為什么要有服務(wù)網(wǎng)關(guān)?

我們都知道在微服務(wù)架構(gòu)中，系統(tǒng)會被拆分為很多個微服務(wù)。那么作為客戶端要如何去調(diào)用這么多的微服務(wù)呢？難道要一個個的去調(diào)用嗎？很顯然這是不太實際的，我們需要有一個統(tǒng)一的接口與這些微服務(wù)打交道，這就是我們需要服務(wù)網(wǎng)關(guān)的原因。

我們已經(jīng)知道，在微服務(wù)架構(gòu)中，不同的微服務(wù)可以有不同的網(wǎng)絡(luò)地址，各個微服務(wù)之間通過互相調(diào)用完成用戶請求，客戶端可能通過調(diào)用N個微服務(wù)的接口完成一個用戶請求。比如：用戶查看一個商品的信息，它可能包含商品基本信息、價格信息、評論信息、折扣信息、庫存信息等等，而這些信息獲取則來源于不同的微服務(wù)，諸如產(chǎn)品系統(tǒng)、價格系統(tǒng)、評論系統(tǒng)、促銷系統(tǒng)、庫存系統(tǒng)等等，那么要完成用戶信息查看則需要調(diào)用多個微服務(wù)，這樣會帶來幾個問題：

客戶端多次請求不同的微服務(wù)，增加客戶端代碼或配置編寫的復(fù)雜性 認證繁雜，訪問每個服務(wù)都要進行一次認證 每個服務(wù)都通過http訪問，導(dǎo)致http請求增加，效率不高拖慢系統(tǒng)性能 多個服務(wù)存在跨域請求問題，處理起來比較復(fù)雜

我們該如何解決這些問題呢？我們可以嘗試想一下，不要讓前端直接知道后臺諸多微服務(wù)的存在，我們的系統(tǒng)本身就是從業(yè)務(wù)領(lǐng)域的層次上進行劃分，形成多個微服務(wù)，這是后臺的處理方式。對于前臺而言，后臺應(yīng)該仍然類似于單體應(yīng)用一樣，一次請求即可，于是我們可以在客戶端和服務(wù)端之間增加一個API網(wǎng)關(guān)，所有的外部請求先通過這個微服務(wù)網(wǎng)關(guān)。它只需跟網(wǎng)關(guān)進行交互，而由網(wǎng)關(guān)進行各個微服務(wù)的調(diào)用。

這樣的話，我們就可以解決上面提到的問題，同時開發(fā)就可以得到相應(yīng)的簡化，還可以有如下優(yōu)點：

減少客戶端與微服務(wù)之間的調(diào)用次數(shù)，提高效率 便于監(jiān)控，可在網(wǎng)關(guān)中監(jiān)控數(shù)據(jù)，可以做統(tǒng)一切面任務(wù)處理 便于認證，只需要在網(wǎng)關(guān)進行認證即可，無需每個微服務(wù)都進行認證 降低客戶端調(diào)用服務(wù)端的復(fù)雜度 這里可以聯(lián)想到一個概念，面向?qū)ο笤O(shè)計中的門面模式，即對客戶端隱藏細節(jié)，API網(wǎng)關(guān)也是類似的東西，只不過叫法不同而已。它是系統(tǒng)的入口，封裝了應(yīng)用程序的內(nèi)部結(jié)構(gòu)，為客戶端提供統(tǒng)一服務(wù)，一些與業(yè)務(wù)本身功能無關(guān)的公共邏輯可以在這里實現(xiàn)，諸如認證、鑒權(quán)、監(jiān)控、緩存、負載均衡、流量管控、路由轉(zhuǎn)發(fā)等等。示意圖

SpringCloud Gateway網(wǎng)關(guān)介紹

• SpringCloud Gateway是Spring Cloud 的一個全新項目，該項目是基于 Spring 5.0，Spring Boot 2.0 和 Project Reactor 等技術(shù)開發(fā)的網(wǎng)關(guān)，它旨在為微服務(wù)架構(gòu)提供一種簡單有效的統(tǒng)一的 API 路由管理方式。
• SpringCloud Gateway作為Spring Cloud 生態(tài)系統(tǒng)中的網(wǎng)關(guān)，目標是替代 Zuul，在Spring Cloud 2.0以上版本中，沒有對新版本的Zuul 2.0以上最新高性能版本進行集成，仍然還是使用的Zuul 2.0之前的非Reactor模式的老版本。而為了提升網(wǎng)關(guān)的性能，SpringCloud Gateway是基于WebFlux框架實現(xiàn)的，而WebFlux框架底層則使用了高性能的Reactor模式通信框架Netty。

總結(jié)一下，服務(wù)網(wǎng)關(guān)大概就是四個功能：統(tǒng)一接入、流量管控、協(xié)議適配、安全維護。而在目前的網(wǎng)關(guān)解決方案里，有Nginx+ Lua、Spring Cloud Zuul以及Spring Cloud Gateway等等。這里以Spring Cloud Gateway為例進行說明。

Spring Cloud Gateway 的目標，不僅提供統(tǒng)一的路由方式，并且基于 Filter 鏈的方式提供了網(wǎng)關(guān)基本的功能，例如：安全，監(jiān)控/指標，和限流。

提前聲明：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. 具備一些網(wǎng)關(guān)的高級功能：動態(tài)路由、限流、路徑重寫

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

簡單說明一下上文中的三個術(shù)語：

Filter（過濾器）：

和Zuul的過濾器在概念上類似，可以使用它攔截和修改請求，并且對上游的響應(yīng)，進行二次處理。

過濾器為org.springframework.cloud.gateway.filter.GatewayFilter類的實例。

Route（路由）：

網(wǎng)關(guān)配置的基本組成模塊，和Zuul的路由配置模塊類似。

一個Route模塊由一個 ID，一個目標 URI，一組斷言和一組過濾器定義。如果斷言為真，則路由匹配，目標URI會被訪問。

Predicate（斷言）：

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

SpringCloud Gateway的核心架構(gòu)

迎來了Webflux，Webflux的出現(xiàn)填補了Spring在響應(yīng)式編程上的空白，Webflux的響應(yīng)式編程不僅僅是編程風(fēng)格的改變，而且對于一系列的著名框架，都提供了響應(yīng)式訪問的開發(fā)包，比如Netty、Redis等等。

SpringCloud Gateway 使用的Webflux中的reactor-netty響應(yīng)式編程組件，底層使用了Netty通訊框架。

SpringCloud Zuul的核心架構(gòu)

SpringCloud Zuul的IO模型

Springcloud中所集成的Zuul版本，采用的是Tomcat容器，使用的是傳統(tǒng)的Servlet IO處理模型。

servlet由servlet container進行生命周期管理。

• container啟動時構(gòu)造servlet對象并調(diào)用servlet init()進行初始化；
• container關(guān)閉時調(diào)用servlet destory()銷毀servlet；
• container運行時接受請求，并為每個請求分配一個線程（一般從線程池中獲取空閑線程）然后調(diào)用service()。

Servlet的IO模型

servlet是一個簡單的網(wǎng)絡(luò)IO模型，當請求進入servlet container時，servlet container就會為其綁定一個線程，在并發(fā)不高的場景下這種模型是適用的，但是一旦并發(fā)上升，線程數(shù)量就會上漲，而線程資源代價是昂貴的（上線文切換，內(nèi)存消耗大）嚴重影響請求的處理時間。

在一些簡單的業(yè)務(wù)場景下，不希望為每個request分配一個線程，只需要1個或幾個線程就能應(yīng)對極大并發(fā)的請求，這種業(yè)務(wù)場景下servlet模型沒有優(yōu)勢。

Springcloud Zuul 是基于servlet之上的一個阻塞式處理模型，即spring實現(xiàn)了處理所有request請求的一個servlet（DispatcherServlet），并由該servlet阻塞式處理處理。

Springcloud Zuul無法擺脫servlet模型的弊端，雖然Zuul 2.0開始，使用了Netty，并且已經(jīng)有了大規(guī)模Zuul 2.0集群部署的成熟案例，但是，Springcloud官方已經(jīng)沒有集成改版本的計劃了。

Webflux 服務(wù)器

Webflux模式替換了舊的Servlet線程模型，用少量的線程處理request和response io操作，這些線程稱為Loop線程，而業(yè)務(wù)交給響應(yīng)式編程框架處理，響應(yīng)式編程是非常靈活的，用戶可以將業(yè)務(wù)中阻塞的操作提交到響應(yīng)式框架的work線程中執(zhí)行，而不阻塞的操作依然可以在Loop線程中進行處理，大大提高了Loop線程的利用率。官方結(jié)構(gòu)圖：

Webflux雖然可以兼容多個底層的通信框架，但是一般情況下，底層使用的還是Netty，Netty是目前業(yè)界認可的最高性能的通信框架。

而Webflux的Loop線程，正好就是著名的Reactor 模式IO處理模型的Reactor線程，如果使用的是高性能的通信框架Netty，這就是Netty的EventLoop線程。

Spring Cloud Gateway的處理流程

1. GatewayClassPathWarningAutoConfiguration 作用檢查是否配置我們webflux依賴。
2. GatewayAutoConfiguration 加載了我們Gateway需要注入的類。
3. GatewayLoadBalancerClientAutoConfiguration 網(wǎng)關(guān)需要使用的負載均衡，Lb//jarye-member// 根據(jù)服務(wù)名稱查找真實地址
4. GatewayRedisAutoConfiguration 網(wǎng)關(guān)整合Redis整合Lua實現(xiàn)限流
5. GatewayDiscoveryClientAutoConfiguration 服務(wù)注冊與發(fā)現(xiàn)功能

1. 客戶端向網(wǎng)關(guān)發(fā)送Http請求，會到達DispatcherHandler接受請求，匹配到RoutePredicateHandlerMapping。
2. 根據(jù)RoutePredicateHandlerMapping匹配到具體的路由策略。
3. FilteringWebHandler獲取的路由的GatewayFilter數(shù)組，創(chuàng)建GatewayFilterChain處理過濾請求
4. 執(zhí)行我們的代理業(yè)務(wù)邏輯訪問。

Spring Cloud Gateway的源碼流程

過濾器默認有8種，采用責(zé)任鏈模式關(guān)聯(lián)著：

SpringCloud Gateway官方資源

源碼及案例

• github.com/spring-clou…
• github.com/spring-clou…

案例

• spring.io/projects/sp…

分享資源

獲取以上資源請訪問開源項目 點擊跳轉(zhuǎn)