如何分析SpringCloudRibbon、SpringCloudFeign以及断路器

如何分析Spring Cloud Ribbon、Spring Cloud Feign以及断路器,相信很多没有经验的人对此束手无策,为此本文总结了问题出现的原因和解决方法,通过这篇文章希望你能解决这个问题。

让客户满意是我们工作的目标,不断超越客户的期望值来自于我们对这个行业的热爱。我们立志把好的技术通过有效、简单的方式提供给客户,将通过不懈努力成为客户在信息化领域值得信任、有价值的长期合作伙伴,公司提供的服务项目有:主机域名雅安服务器托管、营销软件、网站建设、长兴网站维护、网站推广。

1.spring-cloud 基于 spring-boot ,spring-boot跟传统的spring项目的区别的就是精简配置 ‘搭建的框架’更轻便,上手更快

2.spring-cloud跟传统项目的区别是 前者是分布式 后者是单体架构 ,分布式 即每个子项目都独立开 服务与服务间 有些服务支持给多个其他的服务调用 【相当于简约了重复代码】,当然这个分布式中需要两个重要的服务

2.1、网关服务 (相当于‘分发’给不同的路由) 2.2认证服务 (有限私密的后端请求是需要权限 可能是登录权限 也可能是角色权限)

3.服务注册与发现:注册中心一般常用eruke,然后就是服务提供者 和服务消费者

eruke【高可用服务注册中心】:1.可以有多个注册中心 2.多个注册中心可以相互注册 3.其中一个注册中心挂了,其他的还可以提供服务

4.服务消费者:一般用Ribbon 和 Feign

1. Spring Cloud Ribbon

1.1 Spring Cloud Ribbon是基于Netflix Ribbon实现的一套客户端负载均衡的工具。它是一个基于HTTP和TCP的客户端负载均衡器。它可以通过在客户端中配置ribbonServerList来设置服务端列表去轮询访问以达到均衡负载的作用。

如何分析Spring Cloud Ribbon、Spring Cloud Feign以及断路器

1.2  重试机制

如何分析Spring Cloud Ribbon、Spring Cloud Feign以及断路器

如何分析Spring Cloud Ribbon、Spring Cloud Feign以及断路器

 1.3饥饿加载(eager-load)模式

如何分析Spring Cloud Ribbon、Spring Cloud Feign以及断路器

如何分析Spring Cloud Ribbon、Spring Cloud Feign以及断路器

如何分析Spring Cloud Ribbon、Spring Cloud Feign以及断路器

2. Spring Cloud Feign

2.1.Ribbon是一个基于HTTP和TCP客户端的负载均衡器。 Feign 中也使用Ribbon。

2.2.Spring Cloud Feign是一套基于 NetflixFeign实现的声明式服务调用客户端。它使得编写Web服务客户端变得更加简单。我们只需要通过创建接口并用注解来配置它既可完成对Web服务接口的绑定。它具备可插拔的注解支持,包括Feign注解、JAX-RS注解。它也支持可插拔的编码器和解码器。Spring Cloud Feign还扩展了对Spring MVC注解的支持,同时还整合了Ribbon和Eureka来提供均衡负载的HTTP客户端实现。

如何分析Spring Cloud Ribbon、Spring Cloud Feign以及断路器

3.服务容错保护(Hystrix服务降级、依赖隔离、断路器)

服务降级 : 在为具体执行逻辑的函数上增加 @HystrixCommand 注解来指定服务降级方法,这个注解上有这个服务掉不通会掉哪个服务的标识。

依赖隔离 : 如果新服务接入后运行不稳定或存在问题,完全不会影响到应用其他的请求。

断路器 :  在分布式架构中,断路器模式的作用也是类似的,当某个服务单元发生故障(类似用电器发生短路)之后,通过断路器的故障监控(类似熔断保险丝),直接切断原来的主逻辑调用。

3.1 Hystrix降级逻辑中如何获取触发的异常 

**        Hystrix两种不同** 获取触发的异常的方式

如何分析Spring Cloud Ribbon、Spring Cloud Feign以及断路器

如何分析Spring Cloud Ribbon、Spring Cloud Feign以及断路器

上面的实现同上一节注解方式的实现一样,在使用继承方式的时候通过 getFailedExecutionException 方法就可以获取到触发降级的异常信息了。

3.2  不使用Hystrix

如何分析Spring Cloud Ribbon、Spring Cloud Feign以及断路器

3.3  使用 Hystrix 解决内部调用抛出异常问题

如何分析Spring Cloud Ribbon、Spring Cloud Feign以及断路器

该类中该方法为发生异常的回调方法,由此可以看出如果抛出异常如果是  HystrixBadRequestException  是直接处理异常之后进行抛出(这里不会触发熔断机制),而不是进入回调方法

如何分析Spring Cloud Ribbon、Spring Cloud Feign以及断路器

如何分析Spring Cloud Ribbon、Spring Cloud Feign以及断路器

3.4 请求合并

通常微服务架构中的依赖通过远程调用实现,而远程调用中最常见的问题就是通信消耗与连接数占用。在高并发的情况之下,因通信次数的增加,总的通信时间消耗将会变的不那么理想。同时,因为对依赖服务的线程池资源有限,将出现排队等待与响应延迟的情况。为了优化这两个问题,Hystrix提供了HystrixCollapser来实现请求的合并,以减少通信消耗和线程数的占用。

如何分析Spring Cloud Ribbon、Spring Cloud Feign以及断路器

解决方案

**  方式一  继承重写方法、**

如何分析Spring Cloud Ribbon、Spring Cloud Feign以及断路器

如何分析Spring Cloud Ribbon、Spring Cloud Feign以及断路器

在上面的构造函数中,我们为请求合并器设置了时间延迟属性,合并器会在该时间窗内收集获取单个User的请求并在时间窗结束时进行合并组装成单个批量请求。下面 getRequestArgument 方法返回给定的单个请求参数userId,而 createCommand 和 mapResponseToRequests 是请求合并器的两个核心:

  • createCommand :该方法的 collapsedRequests 参数中保存了延迟时间窗中收集到的所有获取单个User的请求。通过获取这些请求的参数来组织上面我们准备的批量请求命令

    UserBatchCommand 实例。

  • mapResponseToRequests :在批量命令 UserBatchCommand 实例被触发执行完成之后,该方法开始执行,其中 batchResponse 参数保存了 createCommand 中组织的批量请求命令的返回结果,而 collapsedRequests 参数则代表了每个被合并的请求。在这里我们通过遍历批量结果 batchResponse 对象,为 collapsedRequests 中每个合并前的单个请求设置返回结果,以此完成批量结果到单个请求结果的转换。

如何分析Spring Cloud Ribbon、Spring Cloud Feign以及断路器

如何分析Spring Cloud Ribbon、Spring Cloud Feign以及断路器

**  方式二【** 使用注解实现请求合并器】、

如何分析Spring Cloud Ribbon、Spring Cloud Feign以及断路器

这里使用 @HystrixProperty(name="timerDelayInMilliseconds", value = "100") 将合并时间窗设置为100毫秒

注意:请求命令本身的延迟。如果依赖服务的请求命令本身是一个高延迟的命令,那么可以使用请求合并器.

看完上述内容,你们掌握如何分析Spring Cloud Ribbon、Spring Cloud Feign以及断路器的方法了吗?如果还想学到更多技能或想了解更多相关内容,欢迎关注创新互联行业资讯频道,感谢各位的阅读!


网页标题:如何分析SpringCloudRibbon、SpringCloudFeign以及断路器
网站地址:http://myzitong.com/article/gddcid.html