1. 程式人生 > >spring cloud zuul閘道器服務重試請求配置

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