您好,登錄后才能下訂單哦!
a、單例serverId映射
zuul: ??routes: ????client-a: ??????path:?/client/** ??????serviceId:?client-a
意思是,以/client/**為端點路徑的服務都映射到client-a,這種配置還可以簡寫成下面的格式,二者效果完全一致:
官網?www.1b23.com zuul: ??routes: ????client-a:?/client/**
還有一種更粗暴的方式,就是映射的serverId都不用寫,如下:
zuul: ??routes: ????client-a:
這種配置,zuul會為client-a添加一個默認的映射規則,即:/client/**,相當于上面的第一種配置方式。
b、單例URL映射
這種配置意思就是,網關路由到具體的服務地址,即:將serverId替換成url,如下:
zuul: ??routes: ????client-a: ??????path:?/client/** ??????url:?http://localhost:7070?#client-a的地址
c、多實例路由
默認情況下zuul會使用eureka中集成的負載均衡功能,如果要使用ribbon的負載均衡,就需要指定serverId,這個操作一定要禁用掉ribbon使用eureka,具體操作如下:
zuul: ??routes: ????ribbon-route: ??????path:?/ribbon/** ??????serviceId:?ribbon-routeribbon: ??eureka: ????enabled:?false??#禁止Ribbon使用Eurekaribbon-route:??ribbon: ????NIWSServerListClassName:?com.netflix.loadbalancer.ConfigurationBasedServerList?#定義獲取服務列表方法 ????NFLoadBalancerRuleClassName:?com.netflix.loadbalancer.RandomRule?????#Ribbon?LB?Strategy?使用隨機負載策略 ????listOfServers:?localhost:7070,localhost:7071?????#client?services?for?Ribbon?LB?指定服務地址
d、forword本地跳轉
假如在網關服務中,需要做一些邏輯處理,可以在配置url時,添加forword選項:
zuul: ??routes: ????client-a: ??????path:?/client/** ??????url:?forward:/client?#跳轉到網關服務中@GetMapping("/client")端點
e、相同路徑加載
zuul: ??routes:????client-b: ??????path:?/client/** ??????serviceId:?client-b????client-a: ??????path:?/client/** ??????serviceId:?client-a
從上面的配置文件,可以看出,配置了兩個工程的路由,即:client-a工程,client-b工程,但是二者的path路徑是一致的,這種情況下,在加載訪問的時候,后者會覆蓋前者。
f、路由通配符
規則 | 說明 | 示例 |
/** | 匹配任意數量的路徑與字符 | /client/add, /client/update, client/a, client/add/a, client/update/a/b |
/* | 匹配任意數的字符 | /client/add, /client/update, client/a |
/? | 匹配單個字符 | /client/a |
2、功能配置
a、屏蔽服務、屏蔽路徑
zuul:??ignored-services:?client-b????#忽略的服務,防止服務侵入??ignored-patterns:?/**/div/**??#忽略的接口,屏蔽接口 ??routes: ????client-a:?/client/**
加上?ignored-services 與?ignored-patterns?之后,zuul在拉取服務列表的時候,創建映射規則的時候,就會忽略掉client-b服務和/**/div/**接口。
b、過濾掉敏感請求頭
正常我們使用HTTP請求服務,在header添加值進行傳遞,是很正常的一件事,協議的一些基本認證也都在header,比如cookie,或者把登錄認證通過后的用戶信息base64編碼后,放在authorization里面,在系統內這種傳遞是沒有問題的,但是如果系統與外部進行交互,這種可能就會出現異常,畢竟也要防患于未然,這時可以在zuul里邊指定敏感頭信息,切斷它與下游的交互,如下:
zuul: routes: client-a: path: /client/** sensitiveHeaders: Cookie,Set-Cookie,Authorization serviceId: client-a
c、重定向
在實際企業級項目中,很多操作都是需要用戶登錄后,才可以進行操作的,為了防止用戶登錄成功后,在重定向的時候,將對應的服務地址暴露給用戶,可以設置一個頭,如下:
zuul: ??add-host-header:?true?????????#重定向header問題 ??routes: ????client-a:?/client/**
d、重試機制
在生產環境中,可能由于各種原因,導致偶然請求失敗,可以使用zuul結合ribbon做重試操作,如下:
zuul: retryable: true #開啟重試 ribbon: MaxAutoRetries: 1 #同一個服務重試的次數(除去首次) MaxAutoRetriesNextServer: 1 #切換相同服務數量
但是,這個功能要慎用,因為有些接口需要保證冪等性。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。