一、Gateway簡介
?
1、官網
上一代zuul 1.X：https://github.com/Netflix/zuul/wiki
?
當前gateway：https://cloud.spring.io/spring-cloud-static/spring-cloud-gateway/2.2.1.RELEASE/reference/html/
?
2、是什么
SpringCloud Gateway是SpringCloud的一個全新項目，基于Spring5.O+Springboot 2.0和ProjectReactor等技術開發的網關，它旨在為微服務架構提供一種簡單有效的統一的API路由管理方式。
?
SpringCloudGateway作為SpringCloud生態系統中的網關，目標是替代Zuul,在SpringCloud2.0以上版本中，沒有對新版本的zuul2.0以上最新高性能版本進行集成，仍然還是使用的Zuul 1.x非Reactor模式的老版本。而為了提升網關的性能，SpringCloud Gateway是基于WebFlux框架實現的，而webFlux框架底層則使用了高性能的Reactor模式通信框架Netty。
?
springCloudGateway的目標提供統一的路由方式且基于Filter鏈的方式提供了網關基本的功能，例如：安全，監控/指標，和限流。
?
img
?
3、能干嘛
反向代理
鑒權
流量控制
熔斷
日志監控
微服務架構中網關在哪里？
?
img
?
4、有Zuul了怎么又出來了gateway
neflix不太靠譜，zuul2.0一直跳票，遲遲不發布，一方面因為Zuul1.0已經進入了維護階段，而且Gateway是SpringCloud團隊研發的，是親兒子產品，值得信賴。而且很多功能Zuul都沒有用起來也非常的簡單便捷。Gateway是基于異步非阻塞模型上進行開發的，性能方面不需要擔心。雖然Netflix早就發布了最新的 Zuul 2.x，但 Spring Cloud 貌似沒有整合計劃。而且Netflix相關組件都宣布進入維護期；不知前景如何？多方面綜合考慮Gateway是很理想的網關選擇。
?
5、Gateway特征
基于Spring Framework 5, Project Reactor 和 Spring Boot 2.0 進行構建
動態路由：能夠匹配任何請求屬性
可以對路由指定 Predicate（斷言）和 Filter（過濾器）
集成Hystrix的斷路器功能
集成 Spring Cloud 服務發現功能
易于編寫的 Predicate（斷言）和 Filter（過濾器）
請求限流功能
支持路徑重寫
6、SpringCloudGateway與Zuul的區別：
在SpringCloudFinchley正式版之前，SpringCloud推薦的網關是Netflix提供的Zuul：
Zuul 1.x是一個基于阻塞I/O的APIGateway
Zuul 1.x基于ServIet2.5使用阻塞架構，它不支持任何長連接（如WebSocket)，Zuul的設計模式和Nginx較像，每次I/O操作都是從工作線程中選擇一個執行，請求線程阻塞到工作線程完成，但是差別是Nginx用C++實現，Zuul用Java實現，而JVM本身會有第一次加載較慢的情況，使得Zuul的性能相對較差。
Zuul 2.x理念更先進想基于Netty非阻塞和支持長連接，但SpringCloud目前還沒有整合。Zuul2.x的性能較Zuul1.x有較大提升。在性能方面，根據官方提供的基準測試，SpringCloudGateway的RPS（每秒請求數）是Zuul的1.6倍。
SpringCloudGateway建立在SpringFramework5、ProjectReactor和SpringB00t2．之上，使用非阻塞API
SpringCloudGateway還支持WebSocket,并且與Spring緊密集成擁有更好的開發體驗
7、Zuul1.x模型
springcloud中所集成的zuul版本，采用的是tomcat容器，使用的是傳統的servlet IO處理模型。
?
Servlet的生命周期？servlet由servlet container進行生命周期管理。
?
container啟動時構造servlet對象并調用servlet init()進行初始化，
container運行時接受請求，并為每個請求分配一個線程（一般從線程池中獲取空閑線程）然后調用service()
container關閉時調用servlet destory()銷毀servlet
img
?
上述模式的缺點
servlete—個簡單的網絡IO模型，當請求進入servlet container時，servlet container就會為其綁定一個線程在并發不高的場景下這種模型是適用的。但是一旦高并發（比如抽風用jemeter壓),線程數量就會上漲，而線程資源代價是昂貴的（上線文切換，內存消耗大）嚴重影響請求的處理時間。
?
在一些簡單業務場景下，不希望為每個request分配一個線程，只需要1個或幾個線程就能應對極大并發的請求，這種業務場景下servlet模型沒有優勢。
?
所以Zuul 1.x是基于servlet之上的一個阻塞式處理模型，即spring實現了處理所有request請求的一個servlet(DispatcherServlet)并由該servlet阻塞式處理處理。所以springcloudzuul無法擺脫servlet模型的弊端。
?
8、GateWay模型
image-20220307223911740
?
傳統的Web框架比如說：struts2,springmvc等都是基于Servlet API與Servlet容器基礎之上運行的。
?
但是，在Servlet3.1之后有了異步非阻塞的支持。而WebFlux是一個典型非阻塞異步的框架，它的核心是基于Reactor的相關API實現的。相對于傳統的web框架來說，它可以運行在諸如Netty，Undertow及支持Servlet3.1的容器上。非阻塞式+函數式編程(Spring5必須讓你使用java8)
?
SpringWebFlux是Spring5.0引入的新的響應式框架區別于SpringMVC,它不需要依賴ServletAPI，它是完全異步非阻塞的，并且基于Reactor來實現響應式流規范。
?
二、Gateway工作流程
1、三大核心概念
（1）Route(路由)
路由是構建網關的基本模塊，它由ID，目標URI，一系列的斷言和過濾器組成，如果斷言為true則匹配該路由
?
（2）Predicate(斷言)
參考的是Java8的java.util.function.Predicate，開發人員可以匹配HTTP請求中的所有內容(例如請求頭或請求參數)，如果請求與斷言相匹配則進行路由
?
（3）Filter(過濾)
指的是Spring框架中GatewayFilter的實例，使用過濾器，可以在請求被路由前或者之后對請求進行修改。
?
image-20220307225907461
?
web請求通過一些匹配條件，定位到真正的服務節點。并在這個轉發過程的前后，進行一些精細化控制。
?
predicate就是我們的匹配條件；而filter，就可以理解為一個無所不能的攔截器。有了這兩個元素，再加上目標uri，就可以實現一個具體的路由了。
?
2、Gateway工作流程
官網總結
?
img
?
客戶端向 Spring Cloud Gateway 發出請求。然后在 Gateway Handler Mapping 中找到與請求相匹配的路由，將其發送到 Gateway Web Handler。
?
Handler 再通過指定的過濾器鏈來將請求發送到我們實際的服務執行業務邏輯，然后返回。
?
過濾器之間用虛線分開是因為過濾器可能會在發送代理請求之前（“pre”）或之后（“post”）執行業務邏輯。
?
Filter在“pre”類型的過濾器可以做參數校驗、權限校驗、流量監控、日志輸出、協議轉換等，在“post”類型的過濾器中可以做響應內容、響應頭的修改，日志的輸出，流量監控等有著非常重要的作用。
?
核心邏輯：路由轉發+執行過濾器鏈
)
