Configure request retry for spring Cloud Ribbon/zuul

Source:

http://www.jianshu.com/p/5246ca996360

The following configuration is based on the spring boot version 1.4.5.release,spring cloud version with CAMDEN.SR6.

As you can see, the Compute-service service contains two instances, the port number of instance 1 is 2221, and the port number of instance 2 is 2222.
When accessed through Http://localhost:3333/add, if you are using instance 1, return 30, if you are using instance 2, return 150, and return 30 and 150 alternately by repeating refresh Http://localhost:3333/add, It can be found that client load balancing has been achieved through the ribbon at this time.

At this point, turn off instance 2 and refresh Http://localhost:3333/add again, alternating the 30 and Whitelabel error page exception pages. As can be seen, when accessing to instance 2, the problem of "Connection refused" was returned directly.

To solve this problem, the retry mechanism needs to be added, when accessing to instance 2, encountering "Connection refused", the ability to initiate retry requests to instance 1 to return the correct results.

In the Application.xml file of the Ribbon project, add the following configuration:

# retry mechanism
spring.cloud.loadbalancer.retry.enabled = True

Hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds = 10000

Compute-service.ribbon.connecttimeout =
Compute-service.ribbon.readtimeout = $

# retry
all operation requests Compute-service.ribbon.oktoretryonalloperations = True

# number
of retries to switch instances Compute-service.ribbon.maxautoretriesnextserver = 2

# Number of retries for the current instance
compute-service.ribbon.maxautoretries = 1

Following the previous steps, the 30 and "Whitelabel Error page" exception pages are still alternately returned, and the retry mechanism is not effective.

At this point, add the Spring-boot-starter-actuator module to the Pom file

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId> Spring-boot-starter-actuator</artifactid>
</dependency>

Restart the Ribbon project, observe Http://localhost:3333/autoconfig, and under Negativematches, find the following configuration:
Paste_image.png

As you can see, the hints given here are: the Ribbonautoconfiguration.loadbalancedretrypolicyfactory method does not find retrytemplate dependencies.
By observing the source of the Ribbonautoconfiguration class, you can see the following code:

@Bean
@ConditionalOnClass (name = "Org.springframework.retry.support.RetryTemplate")
public Loadbalancedretrypolicyfactory loadbalancedretrypolicyfactory (springclientfactory clientFactory) {
    return new Ribbonloadbalancedretrypolicyfactory (clientfactory);
}

It can be seen that the effective ribbon load-balancing retry policy factory is obtained on the premise of the existence of retrytemplate dependency.
Next, in the Pom file, join the Spring-retry dependency:

<dependency>
    <groupId>org.springframework.retry</groupId>
    <artifactId> Spring-retry</artifactid>
</dependency>

Restart the Ribbon project, repeat Refresh Http://localhost:3333/add, in the case of Compute-service service Instance 1 and instance 2 are normal, alternately return 30 and 150;
At this point, turn off instance 2, refresh Http://localhost:3333/add again, and you will find that you have returned 30. Just, sometimes there will be a delay of about 1 seconds, visible at this time in the request to instance 2, the occurrence of "Connection refused", and then retry sending the request to instance 1.
It is visible that the retry mechanism is in effect.

At this point, observe http://localhost:3333/autoconfig, below the negativematches, you will see the following configuration:
Paste_image.png

By observing the source of the Ribbonautoconfiguration class, you can see the following code:

@Bean
@ConditionalOnMissingClass (value = "org.springframework.retry.support.RetryTemplate")
public Loadbalancedretrypolicyfactory neverretrypolicyfactory () {
    return new Loadbalancedretrypolicyfactory.neverretryfactory ();
}

It can be seen that the retry mechanism does not take effect, you need to remove the retrytemplate dependency.
Continue to track the source of Loadbalancedretrypolicyfactory

Public interface Loadbalancedretrypolicyfactory {public

    loadbalancedretrypolicy Create (String serviceId, Serviceinstancechooser serviceinstancechooser);

    Static Class Neverretryfactory implements Loadbalancedretrypolicyfactory {

        @Override
        public Loadbalancedretrypolicy Create (String serviceId, Serviceinstancechooser serviceinstancechooser) {
            return null;
        }
    }
}

The factory method of discovering Neverretryfactory directly returned null, stating that no retry policy mechanism was used.
It is visible that the retry policy does not take effect without introducing spring-retry.

Configure request retry for Zuul in exactly the same way as the Ribbon.

Author: Wu Junda
Links: http://www.jianshu.com/p/cb69bb385d24
Source: Pinterest
Copyright belongs to the author. Commercial reprint please contact the author for authorization, non-commercial reprint please specify the source.