hystrix

1.Hystrix 是什么？ 在分布式系统中，每个服务都可能会调用很多其他服务，被调用的那些服务就是依赖服务，有的时候某些依赖服务出现故障也是很正常的。 Hystrix 可以让我们在分布式系统中对服务间的调用进行控制，加入一些调用延迟或者依赖故障的容错机制。 Hystrix 通过将依赖服务进行资源隔离，进而阻止某个依赖服务出现故障时在整个系统所有的依赖服务调用中进行蔓延；同时Hystrix 还提供故障时的 fallback 降级机制。 总而言之，Hystrix 通过这些方法帮助我们提升分布式系统的可用性和稳定性。 2.Hystrix 的历史 Hystrix 是高可用性保障的一个框架。Netflix（可以认为是国外的优酷或者爱奇艺之类的视频网站）的 API 团队从 2011 年开始做一些提升系统可用性和稳定性的工作，Hystrix 就是从那时候开始发展出来的。 在 2012 年的时候，Hystrix 就变得比较成熟和稳定了，Netflix 中，除了 API 团队以外，很多其他的团队都开始使用 Hystrix。 时至今日，Netflix 中每天都有数十亿次的服务间调用，通过 Hystrix 框架在进行，而 Hystrix 也帮助 Netflix 网站提升了整体的可用性和稳定性。 2018 年 11 月，Hystrix 在其 Github 主页宣布，不再开放新功能

背景 分布式系统环境下,服务之间的依赖调动非常常见,一个业务调用通常依赖多个基础服务,如果调用某服务层,而这个服务层不可用或者因为网络等原因响应时间超出预期,请求线程被堵塞,当有大量的请求调用这个服务就会导致这个服务的资源被耗尽,无法继续对外提供服务,这也叫雪崩效应; 雪崩效应经常出现在,服务器宕机,光纤被挖断(如腾讯:https://baijiahao.baidu.com/s?id=1628812006479290058&wfr=spider&for=pc),异常流量,缓存穿透,JVM长时间FullGC,同步等待; 出现了雪崩效应,服务一个一个出问题,为了构建一个稳定可靠的分布式系统,我们的系统应该具备自我保护能力,避免雪崩效应; 服务短路（CircuitBreaker） QPS (Query per second 每秒查询率) QPS: 经过全链路压测，计算单机极限QPS，集群 QPS = 单机 QPS * 集群机器数量 * 可靠性比率; 全链路压测 除了压 极限QPS，还有错误数量; 全链路：一个完整的业务流程操作; Hystrix 本文猪角Hystrix就是解决同步等待导致的雪崩问题; 对来自依赖的延迟和故障进行防护控制,一般都是通过网络调用导致的; 快速失败并迅速恢复; 停止分布式系统中的级联故障; 回退并优雅的降级; https://github.com/Netflix

一、概述 1.1、基础【示例一】 　　如果Hystrix在类路径上并且 feign.hystrix.enabled = true ，Feign将用断路器包装所有方法。还可以返回com.netflix.hystrix.HystrixCommand。这可让您使用响应模式（调用.toObservable（）或.observe（）或异步使用（调用.queue（））。 　　要以每个客户端为基础禁用Hystrix支持，请创建一个具有“prototype”范围。 　　在Spring Cloud Dalston发布之前，如果Hystrix在类路径上，Feign默认情况下会将所有方法封装在断路器中。 Spring Cloud Dalston改变了这种默认行为，以支持选择加入方式。 @Configuration public class FooConfiguration { @Bean @Scope("prototype") public Feign.Builder feignBuilder() { return Feign.builder(); } } 1.2、Fallbacks【示例一、示例二】 　　Hystrix支持回退的概念：当电路断开或出现错误时执行的默认代码路径。要为给定的@FeignClient启用回退，请将fallback属性设置为实现回退的类名称。您还需要将您的实现声明为Spring

前言 分布式系统中经常会出现某个基础服务不可用造成整个系统不可用的情况, 这种现象被称为服务雪崩效应. 为了应对服务雪崩, 一种常见的做法是手动服务降级. 而Hystrix的出现,给我们提供了另一种选择. 服务雪崩效应的定义 服务雪崩效应是一种因 服务提供者 的不可用导致 服务调用者 的不可用,并将不可用 逐渐放大 的过程.如果所示: 上图中, A为服务提供者, B为A的服务调用者, C和D是B的服务调用者. 当A的不可用,引起B的不可用,并将不可用逐渐放大C和D时, 服务雪崩就形成了. 服务雪崩效应形成的原因 我把服务雪崩的参与者简化为 服务提供者 和 服务调用者 , 并将服务雪崩产生的过程分为以下三个阶段来分析形成的原因: 服务提供者不可用 重试加大流量 服务调用者不可用 服务雪崩的每个阶段都可能由不同的原因造成, 比如造成 服务不可用 的原因有: 硬件故障 程序Bug 缓存击穿 用户大量请求 硬件故障可能为硬件损坏造成的服务器主机宕机, 网络硬件故障造成的服务提供者的不可访问. 缓存击穿一般发生在缓存应用重启, 所有缓存被清空时,以及短时间内大量缓存失效时. 大量的缓存不命中, 使请求直击后端,造成服务提供者超负荷运行,引起服务不可用. 在秒杀和大促开始前,如果准备不充分,用户发起大量请求也会造成服务提供者的不可用. 而形成 重试加大流量 的原因有: 用户重试 代码逻辑重试

1.Hystrix断路器简介 Hystrix断路器简介 　　hystrix对应的中文名字是“豪猪”，豪猪周身长满了刺，能保护自己不受天敌的伤害，代表了一种防御机制，这与hystrix本身的功能不谋而合，因此Netflix团队将该框架命名为Hystrix，并使用了对应的卡通形象做作为logo。 　　在一个分布式系统里，许多依赖不可避免的会调用失败，比如超时、异常等， 如何能够保证在一个依赖出问题的情况下，不会导致整体服务失败 ，这个就是Hystrix需要做的事情。Hystrix提供了熔断、隔离、Fallback、cache、监控等功能，能够在一个、或多个依赖同时出现问题时保证系统依然可用。 2.服务雪崩效应 服务雪崩效应 当一个请求依赖多个服务的时候： 正常情况下的访问 但是，当请求的服务中出现无法访问、异常、超时等问题时（图中的I），那么用户的请求将会被阻塞。 如果多个用户的请求中，都存在无法访问的服务，那么他们都将陷入阻塞的状态中。 Hystrix的引入，可以通过服务熔断和服务降级来解决这个问题。 3.Hystrix服务熔断服务降级@HystrixCommand fallbackMethod Hystrix服务熔断服务降级@HystrixCommand fallbackMethod 熔断机制是应对雪崩效应的一种微服务链路保护机制。 当某个服务不可用或者响应时间超时，会进行服务降级

转载来源：https://maimai.cn/article/detail?fid=1149221357&efid=lL_Z3WzTyUDLAjQwrNrIsw 概述 毫无疑问，Spring Cloud是目前微服务架构领域的翘楚，无数的书籍博客都在讲解这个技术。不过大多数讲解还停留在对Spring Cloud功能使用的层面，其底层的很多原理，很多人可能并不知晓。因此本文将通过大量的手绘图，给大家谈谈Spring Cloud微服务架构的底层原理。 实际上，Spring Cloud是一个全家桶式的技术栈，包含了很多组件。本文先从其最核心的几个组件入手，来剖析一下其底层的工作原理。也就是Eureka、Ribbon、Feign、Hystrix、Zuul这几个组件。 一、业务场景介绍 先来给大家说一个业务场景，假设咱们现在开发一个电商网站，要实现支付订单的功能，流程如下： 创建一个订单之后，如果用户立刻支付了这个订单，我们需要将订单状态更新为“已支付” 扣减相应的商品库存 通知仓储中心，进行发货 给用户的这次购物增加相应的积分 针对上述流程，我们需要有订单服务、库存服务、仓储服务、积分服务。整个流程的大体思路如下： 用户针对一个订单完成支付之后，就会去找订单服务，更新订单状态 订单服务调用库存服务，完成相应功能 订单服务调用仓储服务，完成相应功能 订单服务调用积分服务，完成相应功能 至此

3 月，跳不动了？>>> 一、什么是springcloud，有什么作用 　　Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。 Spring Cloud是一个全家桶式的技术栈，包含了很多组件。实例 www.b123.com 。先从其最核心的几个组件入手，来剖析一下其底层的工作原理。也就是Eureka、Ribbon、Feign、Hystrix、Zuul这几个组件。 Eureka Eureka是微服务架构中的注册中心，专门负责服务的注册与发现。库存服务、仓储服务、积分服务中都有一个Eureka Client组件，Eureka Client这个组件专门负责将这个服务的信息注册到Eureka Server中（就是告诉Eureka Server，自己在哪台机器上，监听着哪个端口）。而Eureka Server是一个注册中心，里面有一个注册表，保存了各服务所在的机器和端口号。 订单服务里也有一个Eureka Client组件，这个Eureka Client组件会找Eureka Server问一下：库存服务在哪台机器啊？监听着哪个端口啊？仓储服务呢？积分服务呢

3 月，跳不动了？>>> Circuit Breaker解决方案Spring Cloud Hystrix组件。 以 2.2.0.release 为例，教你如何入门该组件。 核心概念 hystrix：就是一般所说的断路器组件 hystrix-dashboard：断路器监控统计展示面板组件 turbine：多节点的断路器统计数据合并展示组件，一般用于集群场景 引入的jar包 <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> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-turbine</artifactId> </dependency>

软件是有生命的，你做出来的架构决定了这个软件它这一生是坎坷还是幸福。 本文不是讲解如何使用Spring Cloud的教程，而是探讨Spring Cloud是什么，以及它诞生的背景和意义。 一、背景 2008年以后，国内互联网行业飞速发展，我们对软件系统的需求已经不再是过去”能用就行”这种很low的档次了，像 抢红包、双十一这样的活动 不断逼迫我们去突破软件系统的性能上限，传统的IT企业”能用就行”的开发思想已经不能满足互联网 高并发、大流量的性能要求 。系统架构 走向分布式 已经是服务器开发领域解决该问题唯一的出路，然而分布式系统由于天生的复杂度，并不像开发单体应用一样把框架一堆就能搞定，因此各大互联网公司都在投入技术力量研发自己的基础设施。这里面比较有名的如 阿里的开源项目dubbo, Netflix开发的一系列服务框架 。在这种“百花齐放”、重复造轮子的状况下，必然要出现一种统一的标准来简化分布式系统的开发， Spring Cloud 应运而生。 二、Spring Cloud是什么 Spring Cloud是一系列框架的有序集合 。它利用 Spring Boot 的开发便利性巧妙地简化了分布式系统基础设施的开发，如 服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控 等，都可以用Spring Boot的开发风格做到一键启动和部署。Spring并没有重复制造轮子

3 月，跳不动了？>>> 上一章介绍了grpc断路器sentinel， grpc断路器之sentinel 但是由于公司线上系统用的告警与监控组件是prometheus，而sentinel暂时还没有集成prometheus，所以这里就在部分线上系统还是用hystrix 步骤 1、pom依赖 <dependency> <groupid>org.springframework.cloud</groupid> <artifactid>spring-cloud-starter-netflix-hystrix</artifactid> </dependency> 2、启动类或者配置类中增加@EnableHystrix 3、增加hystrixCommend注解 @PostMapping("/grpc") @HystrixCommand(fallbackMethod = "fallbackMethod") public BaseResponse doGrpc(@RequestBody ReRequest rr）{ ...... ....... } public BaseResponse fallbackMethod(@RequestBody ReRequest rr）{ ...... ....... } 4、yml中增加相关配置 feign: hystrix: enabled: true