spring cloud zuul閘道器服務重試請求配置
我們一般部署服務的時候,都會部署一個閘道器服務,內部所有的其他微服務的呼叫,都將通過閘道器路由過去,不對外直接暴露,對外只暴露閘道器服務。而且一般內部服務會部署多個例項,zuul集成了ribbon,會自動負載均衡的方式去呼叫內部服務。
當內部服務滾動重啟的時候,通過閘道器的一個請求剛好路由到重啟的那個例項的話,因為預設沒有開啟zuul的請求重試策略,該請求將會報錯,其實理想的方式可以通過重試路由到另外一個活動的服務例項上去。
要開啟zuul閘道器請求重試,首先需要新增spring-retry依賴:
<dependency> <groupId>org.springframework.retry</groupId> <artifactId>spring-retry</artifactId> </dependency>
然後配置:
zuul.retryable=true
這樣,所有路由都將會進行重試。(此屬性預設是false,所以不會重試)
有時候我們不希望所有路由都有重試機制,我們可以配置指定路由進行重試:
zuul.routes.<routename>.retryable=true
這裡的routename預設情況下就是你的服務名(我們可以通過管理端點/routes看到都有哪些路由,也可以檢視更詳細的路由資訊:/routes?format=details,端點實現類:org.springframework.cloud.netflix.zuul.RoutesMvcEndpoint)。例如我有一個rcmd-service-data的服務,我可以這樣配置:
zuul.retryable=false
zuul.routes.rcmd-service-data.retryable=true
這樣,就只有rcmd-service-data這個服務開啟了重試機制。我們通過/routes?format=details端點也可以看到:
我們知道zuul請求也是通過Ribbon負載均衡客戶端去呼叫其他服務的,所以我們的重試策略也是在具體的ribbon配置中指定:
rcmd-service-data: ribbon: # Max number of retries on the same server (excluding the first try) MaxAutoRetries: 1 # Max number of next servers to retry (excluding the first server) #當允許在其他伺服器上重試的時候,會呼叫IRule.choose選擇可用服務例項中的 #其他一臺服務例項進行呼叫 MaxAutoRetriesNextServer: 2 # Whether all operations can be retried for this client OkToRetryOnAllOperations: true #預設為false,則只允許GET請求被重試 ReadTimeout: 5000 ConnectTimeout: 2000
重試的時候還有補償策略,例如重試時間間隔(預設是沒有間隔:org.springframework.retry.backoff.NoBackOffPolicy),我們可以實現自己的補償策略,也可以用內部實現的一些補償策略(需要定義一個bean),如指數級的補償策略(1秒,2秒,4秒類似這種指數級睡眠間隔增長,不超過10秒):
@Configuration
public class MyConfiguration {
@Bean
LoadBalancedBackOffPolicyFactory backOffPolciyFactory() {
return new LoadBalancedBackOffPolicyFactory() {
@Override
public BackOffPolicy createBackOffPolicy(String service) {
return new ExponentialBackOffPolicy();
}
};
}
}
也可以正對某些響應狀態碼進行重試(當呼叫rcmd-service-data返回404,502的時候,進行重試,其他狀態碼不重試):
rcmd-service-data:
ribbon:
retryableStatusCodes: 404,502
以上差不多就是閘道器重試相關的能夠配置的點了.
相關推薦
spring cloud zuul閘道器服務重試請求配置
我們一般部署服務的時候,都會部署一個閘道器服務,內部所有的其他微服務的呼叫,都將通過閘道器路由過去,不對外直接暴露,對外只暴露閘道器服務。而且一般內部服務會部署多個例項,zuul集成了ribbon,會自動負載均衡的方式去呼叫內部服務。 當內部服務滾動重啟的時候,通過閘道
Spring Cloud zuul閘道器服務 一
上一篇進行Netflix Zuul 1.0 與 gateway的對比。今天來介紹一下 zuul的搭建及應用 Zuul 工程建立 工程建立 cloud-gateway-zuul。還是基於之前的工程 pom檔案匯入 <parent> <artifactId>spring-
Spring Cloud---Zuul閘道器篇( 一)-----Zuul請求流程解析(簡化)
前述:Spring Zuul是Spring微服務的閘道器,作為微服務的入口,用來統一管理請求。Zuul不是把閘道器的所有事情都做了,而是暴露了當前請求的整個過程生命週期的處理。實際閘道器的實現邏輯還是需要我們自己處理,在解析完Zuul後我會提供一個閘道器限流的方案例項,並對其做擴充套件,以為
Spring Cloud zuul閘道器配置api-gateway
zuul閘道器,主要功能用於 限流,驗證 zuul可以通過載入動態過濾機制,從而實現以下各項功能: 驗證與安全保障: 識別面向各類資源的驗證要求並拒絕那些與要求不符的請求。 審查與監控: 在邊緣位置追蹤有意義資料及統計結果,從而為我們帶來準確的生產狀態結論。 動態路由:
第十二天:浪跡天涯網上商城(1.0版本)--spring cloud zuul閘道器搭建
1、需求我們都知道專案中的服務是越來越多的,如果沒有一個統一的閘道器來做分發,那麼就會將複雜度帶到客戶端,所以我們必須搭建閘道器。2、實現步驟1、建立一個專案langjitianya-gateway2、準備好pom.xml檔案3、準備好配置檔案4、準備好啟動類5、run 起來
Spring Cloud Zuul閘道器
前面已經簡單介紹了搭建Eureka註冊中心,Feign消費,Service提供者,那麼外部呼叫的時候是直接走Feign來呼叫服務麼?其實不然,後端介面並不會直接開方,而是通過一個統一閘道器服務,來對映請求的api,路由到相對應的服務.沿用之前的服務來完成Zuul的測試.一 :
Spring Cloud gateway 閘道器服務二 斷言、過濾器
微服務當前這麼火爆的程度,如果不能學會一種微服務框架技術。怎麼能升職加薪,增加簡歷的籌碼?spring cloud 和 Dubbo 需要單獨學習。說沒有時間?沒有精力?要學倆個框架?而Spring Cloud alibaba只需要你學會一個就會擁有倆種微服務治理框架技術。何樂而不為呢?加油吧!騷猿年 上一篇我
Spring Cloud 2-Zuul 閘道器服務(六)
Spring Cloud Zuul 1.pom.xml 2.application.yml Application.java &nb
SpringCloud工作筆記038---spring cloud-簡單閘道器許可權控制_直接在zuul裡面做
這樣也是一種方式吧,比較Low的一種吧,應該是, 在閘道器裡,判斷,是否有token,當然不能攔截登入啊,登入的時候本來就沒有token, 登入以後,判斷如果有token,就轉發,轉發以後就到了,對應的微服務中的controller中了,這樣 在controller
Spring Cloud alibaba閘道器 sentinel zuul 四 限流熔斷
spring cloud alibaba 集成了 他內部開源的 Sentinel 熔斷限流框架 Sentinel 介紹 官方網址 隨著微服務的流行,服務和服務之間的穩定性變得越來越重要。Sentinel 以流量為切入點,從流量控制、熔斷降級、系統負載保護等多個維度保護服務的穩定性。 Sentinel 具有以下
springcloud之Zuul閘道器服務
Zuul是Netflix開源的微服務閘道器,它的核心是一系列的過濾器,這些過濾器可以完成以下功能: 身份認證與安全:識別每個資源的驗證要求,並拒絕那些與要求不符的請求。 審查與監控:在邊緣位置追蹤有意義的資料和統計結果,從而帶來精確的生產檢視。 動態路由:動態的請求路由到不同的後端叢集。
Spring Cloud之閘道器
介面的分類: 開放介面:可以授權一些介面口OAuth2.0協議方式 第三方聯合登入 內部介面: 一般只能在區域網中進行訪問,服務與服務之間關係都在同一個微服務系統中。目的是為了保證安全問題 介面設計: 介面許可權
Spring boot zuul 閘道器
Zuul作為微服務系統的閘道器元件,用於構建邊界服務,致力於動態的路由、過濾、監控、彈性伸縮和安全。 其中Zuul、Ribbon以及Eureka的結合使用可以實現智慧路由和負載均衡的功能,閘道器將所有的服務的API介面統一聚合,統一對外暴露,外界呼叫API的介面的時候,不需要知道微服務系統中各服
SpringCloud實戰6-Zuul閘道器服務
為什麼需要閘道器呢? 我們知道我們要進入一個服務本身,很明顯我們沒有特別好的辦法,直接輸入IP地址+埠號,我們知道這樣的做法很糟糕的,這樣的做法大有問題,首先暴露了我們實體機器的IP地址,別人一看你的IP地址就知道服務部署在哪裡,讓別人很方便的進行攻擊操作。 第二,我
spring cloud---------- gateway閘道器
一提閘道器的時候,可能大家第一個想到的就是我們網路中的閘道器,其實在微服務體系中閘道器的作用是什麼的明顯的,閘道器負責統一接收所有請求,然後根據不同的規則進行轉發到不同的服務。使用閘道器能夠統一的管理請求日誌、進行許可權控制、過濾等,這樣就能避免在每個單體應用中
Zuul閘道器服務使用詳解
1)在SpringBoot工程 part-1-website 中新增依賴,如下 <!-- spring-cloud-starter-hystrix --> <dependency> <groupId>org.springframework.cloud<
spring cloud gateway閘道器
先記錄一個錯誤再說,在啟動的時候報錯 Description: Parameter 0 of method modifyReq
從零搭建Spring Cloud Gateway閘道器(一)
# 新建Spring Boot專案 怎麼新建Spring Boot專案這裡不再具體贅述,不會的可以翻看下之前的部落格或者直接百度。這裡直接貼出對應的pom檔案。 pom依賴如下: ```xml 4.0.0 org.springframework.boot
從零搭建Spring Cloud Gateway閘道器(二)—— 列印請求響應日誌
作為閘道器,日誌記錄是必不可少的功能,可以在網關出增加requestId來查詢整個請求鏈的呼叫執行情況等等。 # 列印請求日誌 列印請求日誌最重要的就是列印請求引數這些東西,不過RequestBody通常情況下在被讀取一次之後就會失效,這樣的話,下游的服務就不能正常獲取到請求引數了。所以我們需要重寫下請求體
從零搭建Spring Cloud Gateway閘道器(三)——報文結構轉換
## 背景 作為閘道器,有些時候可能報文的結構並不符合前端或者某些服務的需求,或者因為某些原因,其他服務修改報文結構特別麻煩、或者需要修改的地方特別多,這個時候就需要走閘道器單獨轉換一次。 ## 實現 話不多說,直接上程式碼。 首先,我們定義好配置: ```java package com.lifeng