hystrix

背景 Hystrix 旨在通过控制那些访问远程系统、服务和第三方库的节点，从而对延迟和故障提供更强大的容错能力。Hystrix具备拥有回退机制和断路器功能的线程和信号隔离，请求缓存和请求打包，以及监控和配置等功能。 Dubbo是Alibaba开源的，目前国内最流行的java rpc框架。 本文介绍在spring应用里，怎么把Dubbo和Hystrix结合起来使用。 https://github.com/Netflix/Hystrix https://github.com/apache/incubator-dubbo Spring Boot应用 Demo地址： https://github.com/dubbo/dubbo-samples/tree/master/dubbo-samples-spring-boot-hystrix 生成dubbo集成spring boot的应用 对于不熟悉dubbo 集成spring boot应用的同学，可以在这里直接生成dubbo + spring boot的工程： http://start.dubbo.io/ 配置spring-cloud-starter-netflix-hystrix spring boot官方提供了对hystrix的集成，直接在pom.xml里加入依赖： <dependency> <groupId>org

在微服务架构中，根据业务来拆分成一个个的服务，服务与服务之间可以相互调用（RPC），在Spring Cloud可以用RestTemplate+Ribbon和Feign来调用。为了保证其高可用，单个服务通常会集群部署。由于网络原因或者自身的原因，服务并不能保证100%可用，如果单个服务出现问题，调用这个服务就会出现线程阻塞，此时若有大量的请求涌入，Servlet容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩”效应。 为了解决这个问题，业界提出了断路器模型。 一、断路器简介 Netflix has created a library called Hystrix that implements the circuit breaker pattern. In a microservice architecture it is common to have multiple layers of service calls. . —-摘自官网 Netflix开源了Hystrix组件，实现了断路器模式，SpringCloud对这一组件进行了整合。 在微服务架构中，一个请求需要调用多个服务是非常常见的，如下图： 较底层的服务如果出现故障，会导致连锁故障。当对特定的服务的调用的不可用达到一个阀值

本节详细讲解使用Hystrix的通用方式。 简介 Hystrix是由Netflix开源的一个延迟和容错库，用于隔离访问远程系统、服务或者第三方库，防止级联失败，从而提升系统的可用性与容错性。Hystrix主要通过以下几点实现延迟和容错。 包裹请求 使用HystrixCommand（或HystrixObservableCommand）包裹对依赖的调用逻辑，每个命令在独立线程中执行。这使用到了设计模式中的“命令模式”。 跳闸机制 当某服务的错误率超过一定阈值时，Hystrix可以自动或者手动跳闸，停止请求该服务一段时间。 资源隔离 Hystrix为每个依赖都维护了一个小型的线程池（或者信号量）。如果该线程池已满，发往该依赖的请求就被立即拒绝，而不是排队等候，从而加速失败判定。 监控 Hystrix可以近乎实时地监控运行指标和配置的变化，例如成功、失败、超时、以及被拒绝的请求等。 回退机制 当请求失败、超时、被拒绝，或当断路器打开时，执行回退逻辑。回退逻辑可由开发人员自行提供，例如返回一个缺省值。 自我修复 断路器打开一段时间后，会自动进入“半开”状态。断路器打开、关闭、半开的逻辑转换，前面我们已经详细探讨过了，不再赘述。 通用方式使用Hystrix 服务降级 加依赖： <dependency> <groupId>org.springframework.cloud</groupId>

至此，我们已实现服务发现、负载均衡，同时，使用Feign也实现了良好的远程调用——我们的代码是可读、可维护的。理论上，我们现在已经能构建一个不错的分布式应用了，但微服务之间是通过网络通信的，网络可能出问题；微服务本身也不可能100%可用。 如何提升应用的可用性呢？这是我们必须考虑的问题—— 举个例子 ：某大型系统中，服务A调用服务B，某个时刻，微服务B突然崩溃了。微服务A中，依然有大量请求在请求B，如果没有任何措施，微服务A很可能很快就会被拖死——因为 在Java中，一次请求往往对应着一个线程 ，如果不做任何措施，那意味着微服务A请求B的线程要等Feign Client/RestTemplate超时才会释放（这个时间一般非常长，长达几十秒），于是就会有 大量的线程被阻塞 ，而 线程又对应着计算资源 （CPU/内存），于是乎，大量的资源被浪费，并且越积越多，最终服务器终于没有资源给微服务A浪费了，微服务A也挂了。 因此，在大型应用中，微服务之间的容错必不可少，下面来讨论如何实现微服务的容错。 应用容错三板斧 超时机制 超时机制你懂的，配置一下超时时间，例如1秒——每次请求在1秒内必须返回，否则到点就把线程掐死，释放资源！ 思路 ：一旦超时，就释放资源。由于释放资源速度较快，应用就不会那么容易被拖死。 舱壁模式 有兴趣的可以先了解一下船舱构造 ——一般来说，现代的轮船都会分很多舱室

本文节选自《疯狂Spring Cloud微服务架构实战》 京东购买地址： https://item.jd.com/12256011.html 当当网购买地址： http://product.dangdang.com/25201393.html Spring Cloud教学视频： https://my.oschina.net/JavaLaw/blog/1552993 Spring Cloud电子书： https://my.oschina.net/JavaLaw/blog/1570383 Hystrix运作流程 在前面的例子中，使用Hystrix时仅仅创建命令并予以执行，看似简单，实际上，Hystrix有一套较为复杂的执行逻辑，为了能让大家大致了解该执行过程，笔者将整个流程作了简化。Hystrix的运作流程请见图6-3。 图6-3 Hystrix的运作流程图 简单说明一下运作流程： 第一步：在命令开始执行时，会做一些准备工作，例如为命令创建相应的线程池（后面章节讲述）等。 第二步：判断是否打开了缓存，打开了缓存就直接查找缓存并返回结果。 第三步：判断断路器是否打开，如果打开了，就表示链路不可用，直接执行回退方法。结合本章开头的例子，可理解为“基础服务”模块不可用，“服务A”模块直接执行回退，响应用户请求。 第四步：判断线程池、信号量（计数器）等条件，例如像线程池超负荷，则执行回退方法

spring cloud的hystrix还有一个配搭的库hystrix-dashboard,它是hystrix的一款监控工具,能直观的显示hystrix响应信息,请求成功率等.但是hystrix-dashboard只能查看单机和集群的信息,如果需要将多台的信息汇总起来的话就需要使用turbine. 注:这一个系列的开发环境版本为 java1.8, spring boot2.x, spring cloud Greenwich.SR2, IDE为 Intelli IDEA hystrix-dashboard hystrix-dashboard只要在上一篇的hystrix的基础上稍微修改下就可以了. 添加依赖 依赖文件pom.xml需要添加一些信息. <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-hystrix</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-hystrix-dashboard</artifactId> <

上篇文章里我们实现了spring cloud中的服务提供者和使用者.接下来我们就来看看spring cloud中微服务的其他组件. 注:这一个系列的开发环境版本为 java1.8, spring boot2.x. IDE为 Intelli IDEA 熔断器 spring cloud架构成员中有一个叫"熔断器".微服务中一个服务通常存在多级调用情况,在这种情况下就出现了一些严重的问题.假如其中的一个服务故障了,那么调用这个服务的使用者就会处于等待状态中,由于多级联调用,所以后续的调用者也会处于这种情况.因此错误就会在一个系统中被放大,从而出现了服务的"雪崩效应".为了应对这种效应,就有了"熔断器". 所谓熔断器,就是当服务提供者出现问题时,调用者发现了这个问题,它会快速响应报错. 如果它在一段时间内侦测到许多类似的错误，会强迫其以后的多个调用快速失败，不再访问远程服务器，从而防止应用程序不断地尝试执行可能会失败的操作，使得应用程序继续执行而不用等待修正错误，或者浪费CPU时间去等到长时间的超时产生。熔断器也可以使应用程序能够诊断错误是否已经修正，如果已经修正，应用程序会再次尝试调用操作. Hystrix特性 1.断路器机制 断路器很好理解, 当Hystrix Command请求后端服务失败数量超过一定比例(默认50%), 断路器会切换到开路状态(Open).

前言 本篇主要介绍的是SpringCloud中的断路器(Hystrix)和断路器指标看板(Dashboard)的相关使用知识。 SpringCloud Hystrix Hystrix 介绍 Netflix创建了一个名为Hystrix的库，它实现了断路器模式。主要的目的是为了解决服务雪崩效应的一个组件，是保护服务高可用的最后一道防线。 开发准备 开发环境 JDK :1.8 SpringBoot :2.1.1.RELEASE SpringCloud ：Finchley 注:不一定非要用上述的版本，可以根据情况进行相应的调整。需要注意的是SpringBoot2.x以后，jdk的版本必须是1.8以上！ 确认了开发环境之后，我们再来添加相关的pom依赖。 <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-openfeign</artifactId> <

本节探讨Zuul的高级特性。 TIPS： 笔者已经写过很多Zuul相关的文章，对于已经写过的内容，就不再啰嗦一遍了，直接贴地址吧。 过滤器详解 过滤器是Zuul的核心，Zuul大多功能都是基于过滤器实现的。详见： Spring Cloud Zuul过滤器详解 ，文章着重探讨了Zuul过滤器的生命周期、如何自定义过滤器、如何禁用指定过滤器等。 内置过滤器详解 Zuul内置了很多过滤器，这些过滤器帮助我们实现各种能力，来分析一下内置过滤器有哪些，分别是干嘛的。 详见： Spring Cloud内置的Zuul过滤器详解 为Zuul提供回退 跟我学Spring Cloud（Finchley版）-16-Zuul 讲过，Zuul整合了Hystrix，而Hystrix提供fallback的能力。 前文已详细讲过通用方式提供fallback、Feign提供fallback。如果不记得如何提供Fallback，可前往如下文章复习。 跟我学Spring Cloud（Finchley版）-13-通用方式使用Hystrix 跟我学Spring Cloud（Finchley版）-14-Feign使用Hystrix /** * @author itmuch.com */ @Component public class MyFallbackProvider implements FallbackProvider

阅读源码的作用 提取设计思路，增强设计能力 理解运行机制，便于快速解决问题以及功能扩展 常见有关 dubbo 的问题 dubbo的负载均衡是在哪个组件中处理的？ dubbo默认的负载均衡算法是什么？ 如果注册中心挂掉了客户端是否能够继续调用dubbo？ 一个请求从调用端到服务端的处理流程是什么？ 如果你有仔细的研读dubbo的开发文档，大部分问题都是有答案的，为了进一步了解细节就有必要对源码进行了解。 源码分析计划 RPC框架的简易结构 dubbo客户端的初始化 dubbo服务端的初始化 dubbo客户端处理请求流程 dubbo服务端处理请求流程 第一阶段汇总,持续更新中... 01. 环境的搭建 02. 项目结构分析 03. 配置 Configuration 04. 核心流程分析 05. 拓展机制 SPI 06. 关于线程池 07. 服务暴露 Export 08. 服务引用 Refer 09. 注册中心 Registry 10. 动态编译 Compile 11. 动态代理 Proxy 12. 服务调用 Invoke 13. 调用特性 14. 过滤器 Filter 15. NIO 服务器 16. P2P 服务器 17. HTTP 服务器 18. 序列化 Serialization 19. 集群容错 Cluster 20. 优雅停机 21. 日志适配 22. 状态检查 23.