如何分析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来设置服务端列表去轮询访问以达到均衡负载的作用。
1.2 重试机制
1.3饥饿加载(eager-load)模式
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客户端实现。
3.服务容错保护(Hystrix服务降级、依赖隔离、断路器)
服务降级 ： 在为具体执行逻辑的函数上增加 @HystrixCommand 注解来指定服务降级方法，这个注解上有这个服务掉不通会掉哪个服务的标识。
依赖隔离 ： 如果新服务接入后运行不稳定或存在问题，完全不会影响到应用其他的请求。
断路器 ： 在分布式架构中，断路器模式的作用也是类似的，当某个服务单元发生故障（类似用电器发生短路）之后，通过断路器的故障监控（类似熔断保险丝），直接切断原来的主逻辑调用。
3.1 Hystrix降级逻辑中如何获取触发的异常
** Hystrix两种不同** 获取触发的异常的方式
上面的实现同上一节注解方式的实现一样，在使用继承方式的时候通过 getFailedExecutionException 方法就可以获取到触发降级的异常信息了。
3.2 不使用Hystrix
3.3 使用 Hystrix 解决内部调用抛出异常问题
该类中该方法为发生异常的回调方法，由此可以看出如果抛出异常如果是 HystrixBadRequestException 是直接处理异常之后进行抛出（这里不会触发熔断机制），而不是进入回调方法
3.4 请求合并
通常微服务架构中的依赖通过远程调用实现，而远程调用中最常见的问题就是通信消耗与连接数占用。在高并发的情况之下，因通信次数的增加，总的通信时间消耗将会变的不那么理想。同时，因为对依赖服务的线程池资源有限，将出现排队等待与响应延迟的情况。为了优化这两个问题，Hystrix提供了HystrixCollapser来实现请求的合并，以减少通信消耗和线程数的占用。
解决方案
** 方式一 继承重写方法、**
在上面的构造函数中，我们为请求合并器设置了时间延迟属性，合并器会在该时间窗内收集获取单个User的请求并在时间窗结束时进行合并组装成单个批量请求。下面 getRequestArgument 方法返回给定的单个请求参数userId，而 createCommand 和 mapResponseToRequests 是请求合并器的两个核心：
createCommand ：该方法的 collapsedRequests 参数中保存了延迟时间窗中收集到的所有获取单个User的请求。通过获取这些请求的参数来组织上面我们准备的批量请求命令
UserBatchCommand 实例。
mapResponseToRequests ：在批量命令 UserBatchCommand 实例被触发执行完成之后，该方法开始执行，其中 batchResponse 参数保存了 createCommand 中组织的批量请求命令的返回结果，而 collapsedRequests 参数则代表了每个被合并的请求。在这里我们通过遍历批量结果 batchResponse 对象，为 collapsedRequests 中每个合并前的单个请求设置返回结果，以此完成批量结果到单个请求结果的转换。
** 方式二【** 使用注解实现请求合并器】、
这里使用 @HystrixProperty(name="timerDelayInMilliseconds", value = "100") 将合并时间窗设置为100毫秒
注意:请求命令本身的延迟。如果依赖服务的请求命令本身是一个高延迟的命令，那么可以使用请求合并器.
看完上述内容，你们掌握如何分析Spring Cloud Ribbon、Spring Cloud Feign以及断路器的方法了吗？如果还想学到更多技能或想了解更多相关内容，欢迎关注创新互联行业资讯频道，感谢各位的阅读！
当前题目：如何分析SpringCloudRibbon、SpringCloudFeign以及断路器
网页网址：http://6mz.cn/article/gddcid.html