1.1 網關簡介
大家都知道在微服務架構中,一個系統會拆分為多個微服務。那么作為客戶端要如何去調用這么多的微服務,如果沒有網關存在,我們只能在客戶端記錄每個微服務的地址,然后去分別用。
這樣的架構,會存在着諸多的問題:
- 每個業務都會需要鑒權、限流、權限校驗、跨域等邏輯,如果每個業務都各自為戰,自己造輪子實現一遍,會很蛋疼,完全可以抽出來,放到一個統一的地方去做。
- 如果業務量比較簡單的話,這種方式前期不會有什么問題,但隨着業務越來越復雜,比如淘寶、亞馬遜打開一個頁面可能會涉及到數百個微服務協同工作,如果每一個微服務都分配一個域名的話,一方面客戶端代碼會很難維護,涉及到數百個域名,另一方面是連接數的瓶頸,想象一下你打開一個APP,通過抓包發現涉及到了數百個遠程調用,這在移動端下會顯得非常低效。
- 后期如果需要對微服務進行重構的話,也會變的非常麻煩,需要客戶端配合你一起進行改造,比如商品服務,隨着業務變的越來越復雜,后期需要進行拆分成多個微服務,這個時候對外提供的服務也需要拆分成多個,同時需要客戶端配合你進行改造,非常蛋疼。
上面的這些問題可以借助API網關來解決。
所謂的API網關,就是指系統的統一入口,它封裝了應用程序的內部結構,為客戶端提供統一服務,一些與業務本身功能無關的公共邏輯可以在這里實現,諸如認證、鑒權、監控、路由轉發等等。
添加上API網關之后,系統的架構圖變成了如下所示:
我們也可以觀察下,我們現在的整體架構圖:
1.2 什么是Spring Cloud Gateway
網關作為流量的入口,常用的功能包括路由轉發,權限校驗,限流等。
Spring Cloud Gateway 是Spring Cloud官方推出的第二代網關框架,定位於取代 Netflix Zuul1.0。相比 Zuul 來說,Spring Cloud Gateway 提供更優秀的性能,更強大的有功能。
Spring Cloud Gateway 是由 WebFlux + Netty + Reactor 實現的響應式的 API 網關。它不能在傳統的 servlet 容器中工作,也不能構
建成 war 包。
Spring Cloud Gateway 旨在為微服務架構提供一種簡單且有效的 API 路由的管理方式,並基於 Filter 的方式提供網關的基本功能,例如
說安全認證、監控、限流等等。
1.2.1 其他的網關組件:
在SpringCloud微服務體系中,有個很重要的組件就是網關,在1.x版本中都是采用的Zuul網關;但在2.x版本中,zuul的升級一直跳票,SpringCloud最后自己研發了一個網關替代Zuul,那就是SpringCloud Gateway,網上很多地方都說Zuul是阻塞的,Gateway是非阻塞的,這么說是不嚴謹的,准確的講Zuul1.x是阻塞的,而在2.x的版本中,Zuul也是基於Netty,也是非阻塞的,如果一定要說性能,其實這個真沒多大差距。
而官方出過一個測試項目,創建了一個benchmark的測試項目:spring-cloud-gateway-bench,其中對比了:
性能強勁:是第一代網關Zuul的1.6倍
官網文檔:https://docs.spring.io/spring-cloud-gateway/docs/current/reference/html/#gateway-request-predicates-factories
1.2.2 Spring Cloud Gateway 功能特征
- 基於Spring Framework 5, Project Reactor 和 Spring Boot 2.0 進行構建;
- 動態路由:能夠匹配任何請求屬性;
- 支持路徑重寫;
- 集成 Spring Cloud 服務發現功能(Nacos、Eruka);
- 可集成流控降級功能(Sentinel、Hystrix);
- 可以對路由指定易於編寫的 Predicate(斷言)和 Filter(過濾器);
1.3 Spring Cloud Gateway核心概念和原理
1.3.1 核心概念
- 路由(route)
路由是網關中最基礎的部分,路由信息包括一個ID、一個目的URI、一組斷言工廠、一組Filter組成。如果斷言為真,則說明請求的URL和配置的路由匹配。 - 斷言(predicates)
Java8中的斷言函數,SpringCloud Gateway中的斷言函數類型是Spring5.0框架中的ServerWebExchange。斷言函數允許開發者去定義匹配Http request中的任何信息,比如請求頭和參數等。 - 過濾器(Filter)
SpringCloud Gateway中的filter分為Gateway FilIer和Global Filter。Filter可以對請求和響應進行處理。