A record production of retries on the issue SpringCloudFeign

　　Feign retry when last week in the micro for several projects (Data Products), need docking enterprise micro-channel third-party applications, get access_token and factory information code micro-channel in the user module using Feign to invoke micro services timeout error, the problem-solving process by recording this article.

　　A recurring problems:

　　　　1.SpringCloud partially dependent follows

    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>1.5.3.RELEASE</version>
    </parent>

    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.springframework.cloud</groupId>
                <artifactId>spring-cloud-dependencies</artifactId>
                <version>Dalston.SR1</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>
    </dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-eureka</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-feign</artifactId>
        </dependency>

　　　　2. The micro-channel interface documentation relating to:

　　　　The front end through corporate id, domain name after the configured callback, call Api micro-channel to acquire code

　　　　See document https://work.weixin.qq.com/api/doc/90000/90135/91022

　　　　note:

　　　　　　code can only be used once, see the document, and therefore need to get to the access_token cached, the project is cached in redis for subsequent messages push function, etc.

　　　　3. Request flowchart

　　Two. Cause Analysis

　　　　1. The entire link request, Phase 2 is the location feign request, but yml profile is not configured feign, feign therefore can be concluded that use of the default configuration, when problems occur, see the documentation found feign, feign retry The default timeout is 1s,

　　　　So now reconfigured feign timeout, the conventional configuration as feign

feign:
  client:
    config:
      organization:
        connectTimeout: 5000
        readTimeout: 5000

　　　　其实organization表示的就是feign所调用的服务名称

　　　　connectTimeout表示建立请求连接的连接的时间（这里面包括获取请求eureka中保存的服务列表-推测）

　　　　readTimeout表示连接建立以后请求调用的时间

　　　　2.在上述配置中，通过查看organization和data服务的请求日志，发现请求都能顺利的建立，但是当阶段三去请求微信的接口一旦延迟，则会触发feign的重试进行第二次调用；

　　　　由于阶段三请求微信的接口并不是没有调用，而是由于网络或者其他原因导致的微信没有响应，但是code又已经被消费了，当阶段二携带同样的code去调用微信的接口，这时就会出现

　　　　code已经被消费

　　　　3.此时有另外一个问题就是，项目中的服务都是单实例部署，springcloud组件中feign和ribbon都有重试的功能，

　　　　Spring Cloud中Feign整合了Ribbon，但Feign和Ribbon都有重试的功能，Spring Cloud为了统一两者的行为，在C版本以后，将Feign的重试策略默认设置为 feign.Retryer#NEVER_RETRY（即永不重试）

　　　　因此Feign的调用本质还是通过ribbon去实现

A record production of retries on the issue SpringCloudFeign

Guess you like