原始碼地址:https://gitee.com/fighter3/eshop-project.git
持續更新中……
大家好,我是三分惡。
在前面的章節中,我們已經完成了服務間的呼叫、統一配置等等,在這一章節裡,我們會引入微服務體系的一個重要元件——閘道器。
閘道器概述
為什麼要引入閘道器
大家都知道,我們服務端的各個服務呼叫是從服務註冊中心拉取服務列表,再由負載均衡策略去呼叫對應的服務提供方。
那麼,在什麼都不做的情況下,看看我們的客戶端,包括PC、移動端等等是怎麼訪問我們的服務端的呢?
這麼辦有什麼問題呢?
-
客戶端需要維護後端服務的地址,如果我們叢集部署,一個服務有數十上百個節點呢?
-
日誌、鑑權等等邏輯,我們每個服務都得搞一套。
-
服務端的服務都得能被客戶端訪問,所以需要外網ip,但是ip資源實在太寶貴了。
……
這時候就需要在客戶端和服務端之間加一個統一的入口,而在微服務的體系中,承擔這個角色的就是閘道器。
我們加入一個閘道器,來作為請求的統一接入。我們只需要將閘道器的機器ip配置到DNS,或者接入層負載,那麼客戶端的服務最終通過我們的閘道器,再轉發給對應的服務端服務。
常見微服務閘道器
目前市面上根據技術棧實現的不同大概有如下一些閘道器:
簡單介紹一下這些閘道器:
- Nginx: Nginx由核心和模組組成,核心的設計非常微小和簡潔,完成的工作也非常簡單,僅僅通過查詢配置檔案與客戶端請求進行 URL 匹配,用於啟動不同的模組去完成相應的工作。
- Kong: Kong是一款基於OpenResty(Nginx + Lua模組)編寫的高可用、易擴充套件的,由Mashape公司開源的API Gateway專案。Kong是基於NGINX和Apache Cassandra或PostgreSQL構建的,能提供易於使用的RESTful API來操作和配置API管理系統,所以它可以水平擴充套件多個Kong伺服器,通過前置的負載均衡配置把請求均勻地分發到各個Server,來應對大批量的網路請求。
- Netfilx Zuul:Zuul 是 Netflix 開源的微服務閘道器元件,它可以和 Eureka、Ribbon、Hystrix 等元件配合使用。社群活躍,融合於 SpringCloud 完整生態,是構建微服務體系前置閘道器服務的最佳選型之一。
- Spring Cloud GetWay:Spring Cloud Gateway 是Spring Cloud的一個全新的API閘道器專案,目的是為了替換掉Zuul1。Gateway可以與Spring Cloud Discovery Client(如Eureka)、Ribbon、Hystrix等元件配合使用,實現路由轉發、負載均衡、熔斷等功能,並且Gateway還內建了限流過濾器,實現了限流的功能。
Spring Cloud GetWay實踐
在上面我們已經簡單介紹了各種常見的微服務閘道器,接下來引入我們今天的主角——SpringCloud Gateway。
建立閘道器服務
- 建立閘道器子module
esop-gateway
- 引入相關依賴,注意啊,因為閘道器服務作為一個服務,同樣需要配置中心和註冊中心,所以,我們也引入了相關依賴
<!--Spring Cloud Alibaba-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
<version>0.2.2.RELEASE</version>
</dependency>
<dependency>
<groupId>com.alibaba.nacos</groupId>
<artifactId>nacos-client</artifactId>
</dependency>
<!-- spring cloud alibaba nacos config 依賴 -->
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
</dependency>
<!--gateway閘道器-->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>
- bootstap.yml:在配置檔案裡除了應用名稱,我們還配置了Nacos的相關配置,不太清楚的同學可以檢視上一節。
spring:
application:
name: gateway-service # 應用名稱
profiles:
active: dev # 當前環境對應的 profile
cloud:
nacos:
config:
enabled: true # 如果不想使用 Nacos 進行配置管理,設定為 false 即可
server-addr: 127.0.0.1:8848 # Nacos Server 地址
group: DEFAULT_GROUP # 組,預設為 DEFAULT_GROUP
file-extension: yaml # 配置內容的資料格式,預設為 properties
namespace: dev_space # 指定名稱空間,預設為public
路由配置
我們在nacos中來完成gateway的相關路由的配置。
server:
port: 9000
spring:
cloud:
nacos:
discovery:
server-addr: 127.0.0.1:8848
gateway:
discovery:
locator:
enabled: true
routes:
- id: user-service
uri: lb://user-service
predicates:
- Path=/user/**
filters:
- StripPrefix=1
我們在裡面進行了路由轉發的配置,也就是routes
,我們來看一看這些配置項都是什麼意思:
- id: 路由的
唯一
標識,用以和其它Route區分 - uri: 請求要轉發到的地址,lb 指的是從nacos中按照名稱獲取微服務,並遵循負載均衡策略
- predicates: 路由需要滿足的條件,也是個陣列(這裡是
或
的關係) - filters: 過濾器,請求在傳遞過程中可以通過過濾器對其進行一定的修改
在這個配置項裡,我們定義了user
開頭的請求,分發到user-service
這個服務。
接下來我們看看效果吧!
路由轉發效果
回憶一下,在使用者服務裡有一個get請求的根據 id 獲取使用者的介面,訪問一下:
OK,我們現在不直接訪問使用者服務的介面,而是改成訪問閘道器服務,我們來看看效果:
我們訪問的地址是:http://localhost:9000/user/shop-user/user/get-by-id?id=1 ,簡單解析一下:
到此,我們已經引入了Spring Cloud Gateway作為微服務閘道器,並完成了基本的路由轉發的功能。
除了基本的路由轉發,服務閘道器還可以完成許可權校驗、限流、API校驗等功能,後續我們會繼續深入,敬請期待!
"簡單的事情重複做,重複的事情認真做,認真的事情有創造性地做!"——
我是三分惡,可以叫我老三/三分/三哥/三子,一個能文能武的全棧開發,我們們下期見!
參考:
【1】:SpringCloud Cloud Gateway官方文件
【2】:微服務下的閘道器如何選擇
【3】:小專欄 SpringCloudAlibaba微服務實戰
【4】: SpringCloud gateway (史上最全)