在《SpringCloud Alibaba實(shí)戰(zhàn)》專欄前面的文章中，我們實(shí)現(xiàn)了用戶微服務(wù)、商品微服務(wù)和訂單微服務(wù)之間的遠(yuǎn)程調(diào)用，并且實(shí)現(xiàn)了服務(wù)調(diào)用的負(fù)載均衡。也基于阿里開源的Sentinel實(shí)現(xiàn)了服務(wù)的限流與容錯，并詳細(xì)介紹了Sentinel的核心技術(shù)與配置規(guī)則 。今天，我們正式進(jìn)入服務(wù)網(wǎng)關(guān)章節(jié)的學(xué)習(xí)，首先，我們對服務(wù)網(wǎng)關(guān)進(jìn)行簡要的概述并對其核心架構(gòu)進(jìn)行簡要的剖析。

本章總覽

網(wǎng)關(guān)概述

當(dāng)采用分布式、微服務(wù)的架構(gòu)模式開發(fā)系統(tǒng)中，服務(wù)網(wǎng)關(guān)是整個系統(tǒng)中必不可少的一部分。

沒有網(wǎng)關(guān)的弊端

當(dāng)一個系統(tǒng)使用分布式、微服務(wù)架構(gòu)后，系統(tǒng)會被拆分為一個個小的微服務(wù)，每個微服務(wù)專注一個小的業(yè)務(wù)。那么，客戶端如何調(diào)用這么多微服務(wù)的接口呢?如果不做任何處理，沒有服務(wù)網(wǎng)關(guān)，就只能在客戶端記錄下每個微服務(wù)的每個接口地址，然后根據(jù)實(shí)際需要去調(diào)用相應(yīng)的接口。

這種直接使用客戶端記錄并管理每個微服務(wù)的每個接口的方式，存在著太多的問題。比如，這里我列舉幾個常見的問題。

• 由客戶端記錄并管理所有的接口缺乏安全性。
• 由客戶端直接請求不同的微服務(wù)，會增加客戶端程序編寫的復(fù)雜性。
• 涉及到服務(wù)認(rèn)證與鑒權(quán)規(guī)則時，需要在每個微服務(wù)中實(shí)現(xiàn)這些邏輯，增加了代碼的冗余性。
• 客戶端調(diào)用多個微服務(wù)，由于每個微服務(wù)可能部署的服務(wù)器和域名不同，存在跨域的風(fēng)險。
• 當(dāng)客戶端比較多時，每個客戶端上都管理和配置所有的接口，維護(hù)起來相對比較復(fù)雜。

引入API網(wǎng)關(guān)

API網(wǎng)關(guān)，其實(shí)就是整個系統(tǒng)的統(tǒng)一入口。網(wǎng)關(guān)會封裝微服務(wù)的內(nèi)部結(jié)構(gòu)，為客戶端提供統(tǒng)一的入口服務(wù)，同時，一些與具體業(yè)務(wù)邏輯無關(guān)的通用邏輯可以在網(wǎng)關(guān)中實(shí)現(xiàn)，比如認(rèn)證、授權(quán)、路由轉(zhuǎn)發(fā)、限流、監(jiān)控等。引入API網(wǎng)關(guān)后，如下所示。

可以看到，引入API網(wǎng)關(guān)后，客戶端只需要連接API網(wǎng)關(guān)，由API網(wǎng)關(guān)根據(jù)實(shí)際情況進(jìn)行路由轉(zhuǎn)發(fā)，將請求轉(zhuǎn)發(fā)到具體的微服務(wù)，同時，API網(wǎng)關(guān)會提供認(rèn)證、授權(quán)、限流和監(jiān)控等功能。

主流的API網(wǎng)關(guān)

當(dāng)系統(tǒng)采用分布式、微服務(wù)的架構(gòu)模式后，API網(wǎng)關(guān)就成了整個系統(tǒng)不可分割的一部分。業(yè)界通過不斷的探索與創(chuàng)新，實(shí)現(xiàn)了多種API網(wǎng)關(guān)的解決方案。目前，比較主流的API網(wǎng)關(guān)有：Nginx+Lua、Kong官網(wǎng)、Zuul網(wǎng)關(guān)、Apache Shenyu網(wǎng)關(guān)、SpringCloud Gateway網(wǎng)關(guān)。

Nginx+Lua

Nginx的一些插件本身就實(shí)現(xiàn)了限流、緩存、黑白名單和灰度發(fā)布，再加上Nginx的反向代理和負(fù)載均衡，能夠?qū)崿F(xiàn)對服務(wù)接口的負(fù)載均衡和高可用。而Lua語言可以實(shí)現(xiàn)一些簡單的業(yè)務(wù)邏輯，Nginx又支持Lua語言。所以，可以基于Nginx+Lua腳本實(shí)現(xiàn)網(wǎng)關(guān)。

Kong網(wǎng)關(guān)

Kong網(wǎng)關(guān)基于Nginx與Lua腳本開發(fā)，性能高，比較穩(wěn)定，提供多個限流、鑒權(quán)等插件，這些插件支持熱插拔，開箱即用。Kong網(wǎng)關(guān)提供了管理頁面，但是，目前基于Kong網(wǎng)關(guān)二次開發(fā)比較困難。

Zuul網(wǎng)關(guān)

Zuul網(wǎng)關(guān)是Netflix開源的網(wǎng)關(guān)，功能比較豐富，主要基于Java語言開發(fā)，便于在Zuul網(wǎng)關(guān)的基礎(chǔ)上進(jìn)行二次開發(fā)。但是Zuul網(wǎng)關(guān)無法實(shí)現(xiàn)動態(tài)配置規(guī)則，依賴的組件相對來說也比較多，在性能上不如Nginx。

Apache Shenyu網(wǎng)關(guān)

Dromara社區(qū)開發(fā)的網(wǎng)關(guān)框架，ShenYu 的前名是 soul，最近正式加入了 Apache 的孵化器，因此改名為 ShenYu。其是一個異步的，高性能的，跨語言的，響應(yīng)式的API網(wǎng)關(guān)，并在此基礎(chǔ)上提供了非常豐富的擴(kuò)展功能：

• 支持各種語言(http協(xié)議)，支持Dubbo, Spring-Cloud, Grpc, Motan, Sofa, Tars等協(xié)議。
• 插件化設(shè)計思想，插件熱插拔，易擴(kuò)展。
• 靈活的流量篩選，能滿足各種流量控制。
• 內(nèi)置豐富的插件支持，鑒權(quán)，限流，熔斷，防火墻等等。
• 流量配置動態(tài)化，性能極高。
• 支持集群部署，支持 A/B Test，藍(lán)綠發(fā)布。

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

Spring為了替換Zuul而開發(fā)的網(wǎng)關(guān)，SpringCloud Alibaba技術(shù)棧中，并沒有單獨(dú)實(shí)現(xiàn)網(wǎng)關(guān)的組件。在后續(xù)的案例實(shí)現(xiàn)中，我們會使用SpringCloud Gateway實(shí)現(xiàn)網(wǎng)關(guān)功能。

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

Spring Cloud Gateway是Spring公司基于Spring 5.0， Spring Boot 2.0 和 Project Reactor 等技術(shù)開發(fā)的網(wǎng)關(guān)，它旨在為微服務(wù)架構(gòu)提供一種簡單有效的統(tǒng)一的 API 路由管理方式。

它的目標(biāo)是替代Netflix Zuul，其不僅提供統(tǒng)一的路由方式，并且基于 Filter 鏈的方式提供了網(wǎng)關(guān)基本的功能，例如：安全，監(jiān)控和限流、重試等。

SpringCloud Gateway概述

Spring Cloud Gateway是Spring Cloud的一個全新項(xiàng)目，基于Spring 5.0 + Spring Boot 2.0和Project Reactor等技術(shù)開發(fā)的網(wǎng)關(guān)，它旨在為微服務(wù)架構(gòu)提供一種簡單有效的統(tǒng)一的API路由管理方式。

Spring Cloud Geteway作為Spring Cloud生態(tài)系統(tǒng)中的網(wǎng)關(guān)，目標(biāo)是替代Zuul，在Spring Cloud2.0以上版本中，沒有對新版本的Zuul 2.0以上最新高性能版本進(jìn)行集成，仍然還是使用的Zuul 1.x非Reactor模式的老版本。

為了提升網(wǎng)關(guān)性能，Spring Cloud Gateway是基于WebFlux框架實(shí)現(xiàn)的，而WebFlux框架底層則使用了高性能的Reactor模式通信框架Netty。

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

總結(jié)一句話：Spring Cloud Gateway使用的Webflux中的reactor-netty響應(yīng)式編程組件，底層使用Netty通訊框架。

SpringCloud Gateway核心架構(gòu)

客戶端請求到 Gateway 網(wǎng)關(guān)，會先經(jīng)過 Gateway Handler Mapping 進(jìn)行請求和路由匹配。匹配成功后再發(fā)送到 Gateway Web Handler 處理，然后會經(jīng)過特定的過濾器鏈，經(jīng)過所有前置過濾后，會發(fā)送代理請求。請求結(jié)果返回后，最后會執(zhí)行所有的后置過濾器。

由上圖可以看出，SpringCloud Gateway的主要流程為：客戶端請求會先打到Gateway，具體的講應(yīng)該是DispacherHandler(因?yàn)镚ateway引入了WebFlux，作用可以類比MVC的DispacherServlet)。

Gateway根據(jù)用戶的請求找到相應(yīng)的HandlerMapping，請求和具體的handler之間有一個映射關(guān)系，網(wǎng)關(guān)會對請求進(jìn)行路由，handler會匹配到RoutePredicateHandlerMapping，匹配請求對應(yīng)的Route，然后到達(dá)Web處理器。

WebHandler代理了一系列網(wǎng)關(guān)過濾器和全局過濾器的實(shí)例，這些過濾器可以對請求和響應(yīng)進(jìn)行修改，最后由代理服務(wù)完成用戶請求，并將結(jié)果返回。

注：SpringCloud Gateway部分參考鏈接：

https://www.csdn.net/tags/NtTagg0sMTk1OTItYmxvZwO0O0OO0O0O.htmlhttps://baijiahao.baidu.com/s?id=1685753662803832483。