hystrix

在微服务架构中，我们将系统拆分成了一个个的服务单元，各单元应用间通过服务注册与订阅的方式互相依赖。由于每个单元都在不同的进程中运行，依赖通过远程调用的方式执行，这样就有可能因为网络原因或是依赖服务自身问题出现调用故障或延迟，而这些问题会直接导致调用方的对外服务也出现延迟，若此时调用方的请求不断增加，最后就会出现因等待出现故障的依赖方响应而形成任务积压，线程资源无法释放，最终导致自身服务的瘫痪，进一步甚至出现故障的蔓延最终导致整个系统的瘫痪。如果这样的架构存在如此严重的隐患，那么相较传统架构就更加的不稳定。为了解决这样的问题，因此产生了断路器等一系列的服务保护机制。 针对上述问题，在Spring Cloud Hystrix中实现了线程隔离、断路器等一系列的服务保护功能。它也是基于Netflix的开源框架 Hystrix实现的，该框架目标在于通过控制那些访问远程系统、服务和第三方库的节点，从而对延迟和故障提供更强大的容错能力。Hystrix具备了服务降级、服务熔断、线程隔离、请求缓存、请求合并以及服务监控等强大功能。 接下来，我们就从一个简单示例开始对Spring Cloud Hystrix的学习与使用。 在开始使用Spring Cloud Hystrix实现断路器之前，我们先拿之前实现的一些内容作为基础，其中包括： eureka-server工程：服务注册中心，端口：1001

这个Finchley版本，也就是6月低刚刚出RELEASE版。我这里录制了个教程。 也懒得写博客了。网上还没有这个版本的教程。大家有需要可以看下： 目录： 1、微服务介绍 2、服务的注册与发现（Eureka） 3、服务消费者（rest+ribbon） 4、服务消费者（Feign） 5、断路器（Hystrix） 6、路由网关(zuul) 7、分布式配置中心(Spring Cloud Config) 8、高可用的分布式配置中心(Spring Cloud Config) 9、消息总线(Spring Cloud Bus) 10、服务链路追踪(Spring Cloud Sleuth) 11、高可用的服务注册中心 12、docker部署spring cloud项目 13、断路器监控(Hystrix Dashboard) 14、断路器聚合监控(Hystrix Turbine) 15、服务注册(consul) 16、SrpingCloud集成mybatis、mysql 17、SrpingCloud集成redis 18、深入理解Feign之源码解析 19、深入理解Eureka之源码解析 20、深入理解Ribbon之源码解析 21、深入理解Zuul之源码解析 22、深入理解Hystrix之源码解析 23、深入理解Config之源码解析 24、深入理解Bus之源码解析 25

在学习Spring Cloud断路器的时候配置Hystrix仪表盘出现Unable to connect to Command Metric Stream 错误。这个错误意思是连接不上。 我使用的Spring boot版本是 1.5.2.RELEASE 我的解决方案是在pom文件中加入这个依赖， < dependency > < groupId > org.springframework.cloud </ groupId > < artifactId > spring-cloud-starter-zuul </ artifactId > < version > 1.4.4.RELEASE </ version > </ dependency > 然后在启动类上加上 @EnableCircuitBreaker 注解，这样重新访问就可以连接上了。 欢迎关注我的博客： https://li-weijian.github.io/ 欢迎关注我的CSDN： https://blog.csdn.net/qq352642663 需要联系请加QQ：352642663 欢迎联系我共同交流 文章来源: Hystrix Dashboard仪表盘Unable to connect to Command Metric Stream问题解决方案

配置信息 server: port: 8010 spring: application: name: microservice-consumer-order eureka: client: serviceUrl: defaultZone: http: //localhost:8761/eureka/ instance: prefer-ip-address: true feign: hystrix: enabled: true # 说明：请务必注意，从Spring Cloud Dalston开始，Feign默认是不开启Hystrix的。 # 因此，如使用Dalston请务必额外设置属性：feign.hystrix.enabled=true，否则 断路器不会生效。 # 而，Spring Cloud Angel/Brixton/Camden中，Feign默认都是开启Hystrix的。 无需设置该属性。 UserFeignClient /** * Feign的fallback测试 * 使用@FeignClient的fallback属性指定回退类 */ @FeignClient (name = "microservice-provider-user" , fallback = FeignClientFallback.class /*, configuration =

1. feign和hystrix feign整合出错回退的功能，FeignClient的注解中，加入fallbackFactory = UserServiceFallback.class的设置，其中UserServiceFallBack需要实现FallbackFactory<UserServFeign>的接口。 在UserServiceFallBack中会接受一个Throwable的对象，在服务出错时可以利用他，分辨出错误类型，并且给予调用者错误信息。所以fiegn整合回退功能，是可以处理程序异常的 2. zuul整合服务回退功能 在给zuul整合回退功能时，只要类实现ZuulFallbackProvider接口，并且注册bean即可。 不错需要注意的时，如果服务程序出现异常，此回退程序是不能处理的，异常会直接返回给调用者，比如页面。 zuul中异常的处理，主要是利用error过滤器，这个之后再详细学习。 3. 异常的处理流程 从最低的程序报出异常，到最后处理掉，有很多地方可以处理，在此列举下目前知道的。 try-catch异常---> 文章来源: 关于zuul，feign和hystrix的整合

转自： https://juejin.im/post/5bac48f9f265da0aa52914b4 1、水平权限校验 水平权限漏洞一般出现在一个用户对象关联多个其他对象（订单等）、并且要实现对关联对象的CRUD的时候。 请求包含用户ID及关联对象ID时、务必校验关联对象是否属于该用户； 2、幂等 幂等操作的特点是任意多次执行所产生的影响均与一次执行的影响相同。 幂等操作的基本处理思路是： 调用者给消息一个唯一请求ID标识。ID标识一个工作单元，这个工作单元只应执行一次； 接收者在执行一个工作单元必须先检验该工作单元是否已经执行过。检查是否执行的逻辑通常是根据唯一请求ID ，在服务端查询请求是否有记录，是否有对应的响应信息，如果有，直接把响应信息查询后返回或者返回重复操作错误信息；如果没有，那么就当做新请求去处理。 3、防并发 防并发基本思路是使用锁：1、分布式锁（redis锁）；2、乐观锁（版本号）；3、状态锁定（对数据进行修改前判断前置状态）。 4、异步任务 慎用EventBus、ThreadPool等处理异步任务，服务宕机或者重启时会丢失任务。建议采用mq自发自收。 5、最终一致性 最终一致性为弱一致性、在需要强一致性的场景务必不能采用tmc等方式实现。（例如下单扣减额度等） 6、防重放 常用的防止重放的机制是使用timestamp和nonce做重放机制

上篇文章中讲了使用Hystrix实现容错，除此之外，Hystrix还提供了近乎实时的监控。本文将介绍如何进行服务监控以及使用Hystrix Dashboard来让监控数据图形化。 sc-parent，父模块(请参照 SpringCloud学习笔记(1)：Eureka注册中心 ) sc-eureka，注册中心(请参照 SpringCloud学习笔记(1)：Eureka注册中心 ) sc-consumer-hystrix-ribbon，使用Hystrix+Ribbon的消费者(请参照 SpringCloud学习笔记(4)：Hystrix容错机制 ) sc-consumer-hystrix-feign，使用Hystrix+Feign的消费者(请参照 SpringCloud学习笔记(4)：Hystrix容错机制 ) sc-hystrix-dashboard，用于可视化监控数据 sc-turbine，用于聚合监控数据 <dependency> <groupId> org.springframework.boot </groupId> <artifactId> spring-boot-starter-actuator </artifactId> </dependency> management : endpoints : web : exposure : include : 'hystrix

修改请求路径的过滤器 StripPrefix Filter StripPrefix Filter 是一个请求路径截取的功能，我们可以利用这个功能来做特殊业务的转发。 application.yml 配置如下： spring: cloud: gateway: routes: - id: nameRoot uri: http://nameservice predicates: - Path=/name/** filters: - StripPrefix=2 上面这个配置的例子表示，当请求路径匹配到/name/**会将包含name和后边的字符串接去掉转发， StripPrefix=2就代表截取路径的个数，这样配置后当请求/name/bar/foo后端匹配到的请求路径就会变成http://nameservice/foo。 我们还是在 cloud-gateway-eureka 项目中进行测试，修改 application.yml 如下： spring: cloud: routes: - id: nameRoot uri: lb://spring-cloud-producer predicates: - Path=/name/** filters: - StripPrefix=2 配置完后重启 cloud-gateway-eureka 项目，访问地址：http://localhost:8888

熔断断路器的重要功能之一，是实现快速失败的基础； Hystrix的熔断器设计成一个接口 com.netflix.hystrix.HystrixCircuitBreaker，解释如下： /** * Circuit-breaker logic that is hooked into {@link HystrixCommand} execution and will stop allowing executions if failures have gone past the defined threshold. * <p> * It will then allow single retries after a defined sleepWindow until the execution succeeds at which point it will again close the circuit and allow executions again. */ 大意就是，在失败请求达到一定量时终止执行HystrixCommand，并且允许一定时间（sleepWindow）后重试一次，成功后就关掉断路器； 熔断主要涉及到三个方面的问题： 　　1、如何实现熔断，如何恢复 　　2、怎么判断是否该熔断 　　3、判断熔断的基础指标数据如何收集和统计 上面就已经大致解释了第一个问题；

接上文，我在接口的并发量压到了500。 发现了A服务调用B服务的时候请求失败，直接进入熔断。经过hystrix和dashaboard监控发现B服务没有接受到请求。 推断是A服务的hystrix配置有问题。 现将实践配置粘到下方。 #hystrix的超时时间 hystrix : command : default : execution : timeout : enabled : true isolation : strategy : THREAD thread : timeoutInMilliseconds : 92000 # interruptOnTimeout: false circuitBreaker : requestVolumeThreshold : 1000 fallback : enabled : true threadpool : # 这是默认的配置 default : coreSize : 200 maxQueueSize : 500 queueSizeRejectionThreshold : 500 请在使用的时候注意缩进。 目前500个并发A服务调用B调用是可以正常响应的。不过仍然有问题，响应速度有些慢。 下面会在接着优化的。 来源：51CTO 作者： 田培融 链接：https://blog.csdn.net/u011296165/article