SpringCloud集成Resilience4j实现熔断器

　　前言
　　在文章《小谈Springcloud中的几个主流熔断器》，我们介绍了SpingCloud架构中的几个主流熔断器，其中SpringCloud官方推荐的Resilience4j作为2020。x以后的新秀，远远没有hystrix有名，相关的文档也还不够多；今天这个文章就来讲讲SpringCloud如何使用Resilience4j实现熔断器；
　　Resilience4j
　　resilience4j是一个轻量级、易于使用的容错库，其灵感来自Netflixesilience4j是一个轻量级、易于使用的容错库，其灵感来自NetflixHystrix，但专为Java8和函数式编程设计。
　　Resilience4j提供高阶函数（decorators）来增强任何功能接口、lambda表达式或方法引用，包括断路器、速率限制器、重试或舱壁。可以在任何函数接口、lambda表达式或方法引用上使用多个装饰器。
　　Resilience4j非常轻量级，不仅可以在SpringCloud进行使用，还可以直接在自己的Java程序里通过Resilience4j的API实现RateLimite的功能；这点也是笔者非常认同的一点；支持和扩展上更为方便；今天的这个文章，重点还是介绍如何在SpringCloud里使用Resilicen4j
　　导入依赖包
　　通过pom。xml引入对Resilience4j的依赖
　　dependencygroupIdio。github。resilience4jgroupIdresilience4jspringbootartifactIddependency
　　配置resilience4j
　　在项目的applicaiton。yml里添加SpringCloud里resilience4j的相关配置
　　resilience4j。circuitbreaker：configs：default：registerHealthIndicator：trueslidingWindowSize：10minimumNumberOfCalls：5permittedNumberOfCallsInHalfOpenState：3automaticTransitionFromOpenToHalfOpenEnabled：truewaitDurationInOpenState：5sfailureRateThreshold：50eventConsumerBufferSize：10recordExceptions：org。springframework。web。client。HttpServerErrorExceptionjava。util。concurrent。TimeoutExceptionjava。io。IOExceptionignoreExceptions：com。kxblive。common。error。CustomExceptionshared：slidingWindowSize：100permittedNumberOfCallsInHalfOpenState：30waitDurationInOpenState：1sfailureRateThreshold：50eventConsumerBufferSize：10ignoreExceptions：com。kxblive。common。error。CustomExceptioninstances：backendA：baseConfig：defaultbackendB：registerHealthIndicator：trueslidingWindowSize：10minimumNumberOfCalls：10permittedNumberOfCallsInHalfOpenState：3waitDurationInOpenState：5sfailureRateThreshold：50eventConsumerBufferSize：10recordFailurePredicate：com。kxblive。common。error。FailureExceptionPredicateresilience4j。retry：configs：default：maxAttempts：3waitDuration：100retryExceptions：org。springframework。web。client。HttpServerErrorExceptionjava。util。concurrent。TimeoutExceptionjava。io。IOExceptionignoreExceptions：com。kxblive。common。error。CustomExceptioninstances：backendA：baseConfig：defaultbackendB：baseConfig：defaultresilience4j。bulkhead：configs：default：maxConcurrentCalls：100instances：backendA：maxConcurrentCalls：10backendB：maxWaitDuration：10msmaxConcurrentCalls：20resilience4j。threadpoolbulkhead：configs：default：maxThreadPoolSize：4coreThreadPoolSize：2queueCapacity：2instances：backendA：baseConfig：defaultbackendB：maxThreadPoolSize：1coreThreadPoolSize：1queueCapacity：1resilience4j。ratelimiter：configs：default：registerHealthIndicator：falselimitForPeriod：10limitRefreshPeriod：1stimeoutDuration：0eventConsumerBufferSize：100instances：backendA：baseConfig：defaultbackendB：limitForPeriod：6limitRefreshPeriod：500mstimeoutDuration：3sresilience4j。timelimiter：configs：default：cancelRunningFuture：falsetimeoutDuration：2sinstances：backendA：baseConfig：defaultbackendB：baseConfig：default
　　在这个配置中分别配置了circuitbeaker、retry、bulkhead、ratelimiter，timelimiter，threadpoolbulkhead这些相关的熔断限流的相关项目。引入resilience4jspringboot集成了circuitbeaker、retry、bulkhead、ratelimiter几个模块的功能，提供相关的实现；我们可以根据业务的实际需要对这些相关项目进行具体配置修改；
　　开发上和使用Hystrix大致上一样；不过注意调整一下自己的地方
　　feign契约只能用feign的，不能用SpringMVC的契约
　　feign契约只能用feign的，不能用SpringMVC的契约；所以不能使用默认的方式，必须通过autoconfiguraiton进行修改
　　BeanpublicContractfeignContract（）｛returnnewContract。Default（）；｝BeanpublicContractfeignContract（）｛returnnewSpringMvcContract（）；｝
　　使用标准Feign注解
　　由于修改了feign的constract方式；所以默认的feign注解方式，不能使用SpringMVC的方式，必须使用Feign的标准方式
　　afterHystrixisremovedfromSpringCloud2021。0。1，thefallbackisineffectiveFeignClient（name｛codeman。service。name：codeman｝，url｛codeman。service。address：｝，fallbackCodeManFallbackImpl。class）publicinterfaceCodeManFeignextendsCodeManService｛RequestLine（GETcodemaninfoversion）publicStringgetVersion（）；RequestLine（GETcodemaninfoauthor）publicStringgetAuthor（）；RequestLine（GETcodemaninfoauthor｛userid｝）对应请求方式和路径publicStringrequestLine（Param（userid）Stringuserid）；｝
　　通过上面的代码可以看到在Feign的定义接口里，不再使用SpringMVC里的标准PostGetDeleteRequest等；而是使用Feign标准的注解RequestLine；这个估计大多数做过Feign的朋友，还不知道这个才是Feign的标准Annotation；由于上一步，我们修改了Consract不再使用SpringMVCConstract；所以PostGetDeleteRequest等这些在SpringMVC里的Annotation不能使用；必须替换；
　　业务调用
　　上一段代码，我们定义出了RPC的remote调用接口；在service层，我们使用已定义的Feign接口，完成业务上的调用；
　　ComponentpublicclassCodeManServiceImplimplementsCodeManService｛AutowiredCodeManFeigncodeManFeign；Value（｛codeman。service。address：http：｛codeman。service。name：codeman｝｝）privateStringurl；Value（｛codeman。service。name：codeman｝）privateStringname；CircuitBreakercircuitBreaker；CodeManFeigncodeManFeign；PostConstructpublicvoidinit（）｛circuitBreakerCircuitBreaker。ofDefaults（backendA）；FeignDecoratorsdecoratorsFeignDecorators。builder（）。withFallback（newCodeManFallbackImpl（），FeignException。class）。build（）；codeManFeignResilience4jFeign。builder（decorators）。target（newTarget。HardCodedTarget（CodeManFeign。class，name，url））；｝OverridepublicStringgetVersion（）｛returncodeManFeign。getVersion（）；｝OverridepublicStringgetAuthor（）｛returncodeManFeign。getAuthor（）；｝OverridepublicStringrequestLine（Stringuserid）｛returncodeManFeign。requestLine（userid）；｝｝
　　上面的业务调用的代码；和我们经常使用OpenFeign进行调用上有点差别；在与对CodeManFeign的IOC的获取上；可以看到代码里
　　注释掉了通过IOC的方式
　　Autowired
　　CodeManFeigncodeManFeign；
　　而是通过
　　PostConstruct
　　publicvoidinit（）｛
　　｝
　　的方式，在init里通过FeignDecorators。builder（）去实例化了Resilience4jFeign。builder（decorators）。target（）的方式去实例化了这个；这里也是不解的地方；为什么不去类似Hystrix的哦方式。在Feign接口定义的时候，也去做一些绑定，而是要手工在这里通过API进行绑定；对这个不解：个人的感觉；可能还是在产品设计的时候，让这个设置更加的细化吧。
　　在我们自己的项目里，在这里是自己做了处理的，其实这个处理的目的就省略掉Init里的代码
　　定义Fallback的实现
　　publicclassCodeManFallbackImplimplementsCodeManService｛OverridepublicStringgetVersion（）｛returnNA；｝OverridepublicStringgetAuthor（）｛returnSpringCloud；｝OverridepublicStringrequestLine（Stringuserid）｛returnKillteam‘spoison；｝｝
　　通过以上的步骤，就可以实现Resilience4j的熔断器的实现了。题外话，由于我们自己的项目都是使用的springcloud来实现微服务；并且都是在springcloud的基础上结合公司项目的特点，封装了自己的springcloud的开发框架，在springcloud的ioc是个好东西，但是在spring里的ioc到处都是，不仅增加了调试问题和追踪问题的复杂程度；而且更让人不放心的就是ioc都是使用反射或者动态代理的方式进行处理的，这样的实现方式真的存在着很大的隐患；不过由于我们使用SpringCloud实现的微服务大多数都是来处理业务应用，反射的性能低下相对于业务应用往往性能的瓶颈而言，基本上都可以忽略不计了，这样的隐患也就藏起来了。当然在学习了go语言以后，深深地体会到了，做服务和做业务对设计模式的取舍点的不同；
　　结束语
　　本文主要介绍的是在SpringCloud微服务开发中，如何使用Resilience4j实现熔断器功能的实现方式；也可以直接通过resilience4j的API，在自己的Java程序里实现熔断器功能，说实在的，SpringCloud的微服务体系真的和ServiceMesh的体系一比较，真的就是一个小孩和大人的比较，熔断是业务需求吗，既然不是，为什么springCloude的开发中，微服务的代码却要揉入熔断器的开发代码；别扭吧；这就是ServiceMesh为什么会是未来的原因。