Zuul Retry-Konfiguration funktioniert nicht mit Eureka

Question

Ich habe ein Szenario mit Spring Boot Zuul als externes Gateway und Eureka als Service Discovery, alles in Kubernetes läuft.

Die Sache ist, ich möchte die Verfügbarkeit meines Dienstes garantieren, wenn also die Instanzen meines Dienstes ausfallen, erwarte ich, dass Zuul wieder versucht, einen der anderen Instanzen durch Eureka anzurufen.

Ich habe versucht, dies zu tun, indem Sie diese Ryan Baxter's post folgen. Plus, ich habe versucht, die Tipps von here zu folgen.

Das Problem ist, dass, was auch immer ich mache, sieht aus wie Zuul nicht erneut versuchen, den Anruf zu tätigen. Wenn ich eine meiner Instanzen lösche, wird immer ein Timeout für diese Instanz zurückgegeben, bis die Eureka-Adressen synchronisiert sind.

Mein application.yaml sieht wie folgt aus:

spring: 
    cloud: 
    loadbalancer: 
     retry: 
     enabled: true 

zuul: 
    stripPrefix: true 
    ignoredServices: '*' 
    routes: 
    my-service: 
     path: /my-service/** 
     serviceId: my-service-api 
    retryable: true 

my-service: 
    ribbon: 
    maxAutoRetries: 3 
    MaxAutoRetriesNextServer: 3 
    OkToRetryOnAllOperations: true 
    ReadTimeout: 5000 
    ConnectTimeout: 3000 

Mein Service ist Camden SR7 mit (Ich habe auch versucht SR6):

"org.springframework.cloud:spring-cloud-dependencies:Camden.SR7" 

Und auch SPRING-Wiederholungs:

org.springframework.retry:spring-retry:1.1.5.RELEASE 

Meine Anwendungsklasse sieht so aus:

@SpringBootApplication 
@EnableEurekaClient 
@EnableZuulProxy 
@EnableRetry 
public class MyZuulApplication 

EDIT:

ein durch Postman bekommen zu machen, es

{ 
    "timestamp": 1497959364819, 
    "status": 500, 
    "error": "Internal Server Error", 
    "exception": "com.netflix.zuul.exception.ZuulException", 
    "message": "TIMEOUT" 
}. 

einen Blick auf die Zuul Protokolle Unter bringt, es gedruckt {"level":"WARN","logger_name":"org.springframework.cloud.netflix.zuul.filters.post.SendErrorFilter","appName":...,"message":"Error during filtering","stack_trace":"com.netflix.zuul.exception.ZuulException: Forwarding error [... Stack Trace ...] Caused by: com.netflix.hystrix.exception.HystrixRuntimeException: my-service-api timed-out and no fallback available [... Stack Trace ...] Caused by: java.util.concurrent.TimeoutException: null

Ein weiteres interessantes Protokoll, das ich gefunden:

{"level":"INFO" [...] current list of Servers=[ip_address1:port, ip_address2:port, ip_address3:port],Load balancer stats=Zone stats: {defaultzone=[Zone:[ ... ]; Instance count:3; Active connections count: 0; Circuit breaker tripped count: 0; Active connections per server: 0.0;] 
},Server stats: [[Server:ip_address1:port; [ ... ] Total Requests:0; Successive connection failure:0; Total blackout seconds:0; [ ... ] 
, [Server:ip_address2:port; [ ... ] Total Requests:0; Successive connection failure:0; Total blackout seconds:0; [ ... ] 
, [Server:ip_address3:port; [ ... ] Total Requests:0; Successive connection failure:0; Total blackout seconds:0; [ ... ] 

Answer 1

Das Problem scheint von Hystrix verursacht zu werden Auszeit. Das Standard-Timeout von HystrixCommand ist 1000ms und es ist nicht genug für das Ribbon, die HTTP-Anfrage erneut zu versuchen. Versuchen Sie, das Timeout der Hystrix wie folgt zu erhöhen.

hystrix: 
    command: 
    default: 
     execution: 
     isolation: 
      thread: 
      timeoutInMilliseconds: 20000 

Die Zeitüberschreitung des gesamten Hystrix-Befehls wird auf 20 Sekunden erhöht. Wenn es funktioniert, passen Sie den Wert für Ihre Umgebung an. Sie verwenden einen ziemlich großen Timeout-Wert für das Lese- und Verbindungstimeout. Daher müssen Sie diese Werte bei Bedarf mit dem Hystrix-Timeout anpassen.