feign调用超时_feign调用时间长
记一次层调用底层服务，出现参数错误的报错
本文将从 Tomcat性能优化，SpringCloud开启重试机制，Zuul性能参数优化，Ribbon性能参数优化，Feign与Hystrix性能优化等 五个方面分享在生产环境如何做好SpringCloud性能优化。具体的做法熔断机制是应对雪崩效应的一种微服务链路保户机制，当扇出链路的某个微服务不可用或者响应时间太长时，会进行服务的降级，进而熔断该微服务的调用，快速返回错误的相应信息。当检测当该微服务调用响应正常后恢复调用链路，熔断机制的注解是@HystrixCommand是：
feign调用超时_feign调用时间长
feign调用超时_feign调用时间长
Feign-Mock
SpringCloud中利用Feign发送请求时参数的传递和返回值在项目开发中，会有调用第三方接口的场景。当开发或日常测试时，对方的服务挂了，我们就一直等着服务恢复，那么这就相当影响效率了。如果我们在开发时，就定义一个mock服务，在发起调用时，不直接调到第三方接口，而是调到我们自己的mock服务，这样就可以避免这些问题了。
我这里的BaseProxy是feign调用，但是在扫描项目的时候这个类的包不在扫描路径下。如我们依赖外部一个的Fegin接口如下：
定义一个实现类实现外部接口
1、去掉SampleServFeignFallback的@Component，不让被Spring管理
2、配置Fegin接口的fallbackFactory
3、开发FallbackFactory，可以输出Feign的错误原因。
4、Mock的实现
配置说明：
配置文件加上配置参数feign.mock.sample=true(Mock时配置，加载Mock类)，feign.mock.sample=false(生产配置，不加载Mock类)
使用nacos无确引入feign
注意SampleServFeignFallback需要加@Component，被Spring去管理。正因如此，就不能使用以上方式实现mock，因为SampleServFeignApi设置了primary = false，在启用mock的时候SampleServFeignApiMock做为Primary，在不启用mock的时候，SampleServFeignFallback实现了SampleServFeignApi接口，加上Fegin自动生成的一个，SampleServFeignApi就有两个实现类并且都被Spring管理并且都没有设置Primary。查了很多资料，发现是因为Spring Cloud Feign在Hoxton.M2 RELEASED版本之后不再使用Ribbon而是使用spring-cloud-loadbalancer，所以不引入spring-cloud-loadbalancer会报错
3.接口返回参数未定义，比如定位返回结果为ResponseEntity,feign 无法识别，需要定义完整的返回类型，比如ResponseEntity这个时候还有一个坑就是当我们调用feign的时候还会抱一个错误：
也是有够坑的，不多坑了两天的空余时间，记录一下
spring cloud openFeign传参的一些总结（有错，待更新）
详细错误信息是：spring cloud openFeign 的客户端 ，即调用方，在启动类中一定要加上 @EnableFeigns 这个注解，serv接口上的@serv注解和@Feign("微服务名") 都写在一起，如果不加，会报@serv 没初始化这个serv接口。
openFeign 默认用的是jdk的UrlConnection，没有连接池，连接没复用，性能不太好，我们可以集成 或者 okHtt请求处理的超时时间p，二选一，不用指定版本号，他会自动根据你的spring cloud 的openfeign 解析出来。
错误如下：
参考：
feign请求返回值反序列LocalDateTime异常记录
openfeign get请求参数dto包含LocalDateTime的处理
本地调用Feign远程接口
请求总次数 n 为feign和ribbon配置参数的笛卡尔积：构造Feign的配置可以按需加入编码, 等, 通过的方式进行接口的调用, 具体参考Target实现类 HardCodedTarget
本地调试Feign远程接口时, 依赖注册中心, Spring上下文环境, 在项目比较庞大的时候, 调试缓慢不利于问题排查; 下面的案例用最简单的配置来实现Feign的远程调用生产级基于SpringCloud微服务架构性能优化实战，建议收藏
服务雪崩 ：当A调用微服务B，B调C，和其他微服务，这是扇出，当扇出链路上某个微服务调用响应时间过长或者不可用，对微服务的A的调用就会占用越来越多的系统资源，导致系统崩溃，所谓的雪崩效应一般基于SpringCloud的微服务能够脱离传统的tomcat，跑起来，SpringBoot功不可没，其原理是SpringBoot内嵌了tomcat（当然可以换成其他servlet容器，如jetty），能够以ja -jar形式就能跑起来。
所以针对每个springboot服务，我们需要对tomcat的一些参数进行优化，以下是楼主项目组优化的tomcat参数配置，供大家参考。
tomcat参数说明：
maxThreads，acceptCount参数应用场景
场景一
场景三
maxTja.lang.AbstractModError: org.springframework.cloudflix.ribbon.RibbonLoadBalancer.choosehreads调优
1、cpu计算型指标
2、io密集型指标
所以大部分情况下，tomcat处理io型请求比较多，比如常见的连数据库查询数据进行接口调用。
maxThreads设置多大合适？
我们知道线程过多，会导致cpu在线程切换时消耗的时间随着线程数量的增加越来越大；线程太少，的请求响应吞吐量会急剧下降，所以maxThreads的配置不是越大越好。
实际情况是设置maxThreads大小没有解，要根据具体的配置，实际的应用场景不断的调整和优化。
acceptCount设置多大合适？
尽量与maxThreads的大小保持一致 ， 这个值应该是主要根据应用的访问峰值与平均值来权衡配置的。
当使用URL进行路由时，则需要对zuul.host.connect-timeout-millis和zuul.host.socket-timeout-millis参数控制超时时间。
对所有作请求都进行重试
对当前实例的重试次数，针对同一个服务实例，重试次数（不包括首次调用）
对下个实例的重试次数，针同其它的服务实例，重试次数（不包括首次server）
注意Hystrix断路器的超时时间需要大于ribbon的超时时间，不然不会触发重试
Feign和Ribbon在整合了Hystrix后，首次调用失败的问题？
目前楼主的强烈做法是： 禁用Hystrix的超时时间，设为false
还有一种是提倡的是 设置超时时间。
在实际的项目中亲测，这种方式也有不好的地方， 如请求时间超过5s会出现请求数据时有时无的情况 ，给用户的感觉是 系统不稳定，要求整改 。
另外，禁用hystrix，不 。
hystrix超时设置原则
问题：一个请求，如果feign和ribbon都配置了重试机制，异常情况下一共会请求多少次？
n(请求总次数) = feign(默认5次) (MaxAutoRetries+1) (MaxAutoRetriesNext+1)
其中+1是代表ribbon本身默认的请求。
nodejs Feign调用
首先feign接口处和被调用的controller接口无法相同。Feign是Spring Cloud提供的一个声明式的伪Http客户端， 它使得调用远程服务就像调用本地服务一样简单， 只需要创建一个接口并添加一个注解即可。Nacos很好的兼容了Feign， Feign默认集成了 Ribbon， 所以在Nac另外，要考虑tomcat的并发请求量大的情况下，对于系统参数优化，如虚拟机内存设置和linux的open file限制。os下使用Fegin默认就实现了负载均衡的效果。
————————————————
版权声明：本文为CSDN博主「carrier！」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：
feign的使用注意
比如系统中有很多服务，当某些服务不稳定的时候，使用这些服务的用户线程将会阻塞，如果没有隔离机制，系统随时就有可能会挂掉，从而带来很大的风险。SpringCloud使用 Hystrix组件提供断路器、资源隔离与自我修复功能 。下图表示服务B触发了断路器，阻止了级联失败1：如果controller的接口有@RequestParm制定了参数名称，那么feign那里也要加入这个注解的属性，并且名字也要取的相同。
2：feign处必须有@RequestParm注解（针对get请求），controller处不一定需要该注解
3：如果想使用get请求传输pojo对象，就使用@SpringQueryMap注解，这个注解会帮我们解析传入的对象的参数然后拼接到(这里不懂等会讲原理)
4：@SpringQueryMap只能使用一次，使用多次，后面参数接收的值都是填充个参数的值。
传入的值为4月服务降级 ：降级一般是从整体负荷考虑，当某个服务熔断之后，将不再被调用，客户端可自己准备一个本地的fallback回调，返回一个缺省值，虽然服务水平下降，当能用，比直接挂掉要强1号和4月22号，
然后尝试将传入的参数改为@SpringQueryMap DatesVo datesVo,并不能解析复杂对象，因为feign的本质是对Template对象的封装，所以我们的很难拼接一个复杂对象上去，或者无法解析复杂对象。
6：由于get的参数大小有限制，所以当传输的对象复杂时，使用@RequestBody和t请求解决。
Spring Cloud调用接口过程
请求连接的超时时间Feign ----->Hystrix —>Ribbon —>Http （apache components 或者 Ok） 具体交互流程上
Hystrix 是一个供分布式系统使用，提供 延迟 和 容错 功能，保证复杂的分布系统在面临不可避免的失败时，仍能有其弹性。
Hystrix是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统中，许多依赖不可避免的会调用失败，超时、异常等，Hystrix能够保证在一个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，提高分布式系统的弹性
“熔断器”本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障，，某个异常条件被触发，直接熔断整个服务。，向调用方法返回一个符合预期的、可处理的备选响应(FallBack),而不是长时间的等待或者抛出吊牌用方法无法处理的异常，就保证了服务调用方feign.codec.DecodeException: Could not extract response: no suitable HttpMessageConverter found for response type [ja.util.List
服务降级处理是在客户端实现完成的，与服务端没有关系
整体资源快不够了，忍痛将某些服务单元先关掉，关闭后还要返回一些可处理的备选方法，待渡过难关，再开启回来。
分布式项目中，有数十个依赖关系，每个依赖关系在某些时候不可避免地失败，
服务熔断 ：一般是某个服务异常引起的，相当于“保险丝”，当某个异常条件被触发，直接熔断整个服务，不是等到此服务超时
springcloud是spring，采用AOP的思想，异常处理信息，我们某个服务的功能是每个方法，我们还可以使用AOP直接在api层通过接口设置服务降级。
spring cloud feign 调用返回结果为null 的原因
为了方便判断我定义了一个MyRetryException并在errorDecoder里面判断状态码为token过期状态码（我们使用的是402），更为严谨的做法是还要判断响应内容的业务状态码。在读取 response body的时候需要注意，在FeignException.errorStatus方法内已经将body读取并关闭了stream，这时可以通过FeignException的contentUTF8方法读取1.启动类没有添加@EnableFeigns 注解
其实二者的重试机制相互，并无联系。但是因为用了feign肯定会用到ribbon，所以feign的重试机制相对来说比较鸡肋，一般会关闭该功能。ribbon的重试机制默认配置为0，也就是默认是去除重试机制的，建议不要修改。2.client 请求方式不一致，比如消费方定义为POST，服务方定位为GET
利用feign的重试机制刷新过期的请求Token
场景二feign的重试默认是不开启的，一般再业务中对于重试都非常谨慎，特别是写作，一定都要保证目标接口实现了幂等才能发起重试，不然就是灾难。但是在一些场景下重试可以简化实现逻辑，比如接口的jwt token过期了，那么在请求响应token过期错误的时候将token刷新后发起重试可以避免请求失败，并且也减少了token有效期的维护逻辑。
如果要看重试的情况，可以开启debug日志，在重试前，feign会打印日志如下因为不是全局开启重试，单独写一个Config类然后作为参数传递给feign client是的方式。
流程上大概是从请求结果得知token过期并重置token，然后交给重试器去判断是否需要重置，随后在重试的请求内刷新token并设置新的token。这里需要自定义feign的RequestInterceptor 、Retryer、ErrorDecoder 一起组合完成判断、重试和token的刷新
feign通过调用配置的Retryer.continueOrPropagate判断是否可以重试，如果抛exception那么重试就终止。需要重试的时候直接return，详细可以参考Retryer接口的Default实现，默认情况下开启的话feign会重试5次。我们只需要刷新token，因此重试一次即可，加计数器并在clone方法里传递到下一次重试中用于判断重试次数
声明：本站所有文章资源内容，如无特殊说明或标注，均为采集网络资源。如若本站内容侵犯了原著者的合法权益，可联系 836084111@qq.com 删除。