一、前言
Zuul
的功能：
-
Zuul
Eureka
Ribbon
- 功能豐富的路由功能，解放運維。
- 具有過濾器，是以鑒權、驗簽都可以內建。
在項目中使用到
Zuul
這塊主要是用在了結合
Eureka
實作負載均衡反向代理。這裡記錄一下
Zuul
的路由的使用。
通過服務發現自動映射路由
Eureka
配合
Zuul
使用的優美之處在于，不僅可以通過單個端點來通路應用的所有服務，而且，在添加或移除服務執行個體的時候不用修改
Zuul
的路由配置。另外，也可以添加一個新的服務到
Eureka
，而
Zuul
會對通路新添加的服務自動路由，因為
Zuul
是通過與
Eureka
通信然後從
Eureka
擷取微服務執行個體真正實體位址，隻要服務托管在
Eureka
中。
二、路由
路由是網關的核心功能之一，可以使系統有一個統一的對外接口，下面來看看具體的應用。
1 傳統路由
傳統路由非常簡單，和 Nginx 類似，由開發、運維人員來維護請求位址和對應服務的映射關系，類似于:
zuul.routes.user-service.path=/user-service/**
zuul.routes.user-sercice.url=http://localhost:8080/
這樣當我們通路
http://localhost:8383/user-service/getUserInfo/1
網關就會自動給我們路由到
http://localhost:8080/getUserInfo/1
上。
可見隻要我們維護好這個映射關系即可自由的配置路由資訊(user-sercice 可自定義)，但是很明顯這種方式不管是對運維還是開發都不友好。由于實際這種方式用的不多就再過多展開。
2 服務路由
對此
Zuul
提供了一種基于服務的路由方式。我們隻需要維護請求位址與服務 ID 之間的映射關系即可，并且由于內建了
Ribbon
,
Zuul
還可以在路由的時候通過
Eureka
實作負載調用。
具體配置：
zuul.routes.sbc-user.path=/api/user/**
zuul.routes.sbc-user.serviceId=sbc-user
這樣當輸入
http://localhost:8383/api/user/getUserInfo/1
時就會路由到注冊到
Eureka
中服務 ID 為
sbc-user
的服務節點，如果有多節點就會按照
Ribbon
的負載算法路由到其中一台上。
這樣讓我們通路
http://127.0.0.1:8383/api/user/userService/getUserByHystrix
時候就會根據負載算法幫我們路由到
sbc-user
應用上，如下圖所示:
啟動了兩個
sbc-user
服務。
請求結果:
一次路由就算完成了。
在上面的配置中有看到
/api/user/**
這樣的通配符配置，具體有以下三種配置需要了解:
-
?
/api/user/?
/api/user/x /api/user/y /api/user/z
-
*
/api/user/x /api/user/xy /api/user/xyz
-
**
/api/user/**
/api/user/x /api/user/x/y /api/user/x/y/zzz
談到通配符比對就不得不提到一個問題，如上面的
sbc-user
服務由于後期疊代更新，将
sbc-user
中的一部分邏輯抽成了另一個服務
sbc-user-pro
。新應用的路由規則是
/api/user/pro/**
，如果我們按照:
zuul.routes.sbc-user=/api/user/**
zuul.routes.sbc-user-pro=/api/user/pro/**
進行配置的話，我們想通過
/api/user/pro/
來通路
sbc-user-pro
應用，卻由于滿足第一個路由規則，是以會被 Zuul 路由到
sbc-user
這個應用上，這顯然是不對的。
解決方法：隻需要将優先比對的路由規則放前即可解決。
參考：
sbc(六) Zuul GateWay 網關應用
服務網關——Spring Cloud Zuul