hystrix

在微服务架构中，存在着多个服务单元，若一个单元出现故障，就很容易因依赖关系而出现故障的蔓延，最终导致整个系统的瘫痪，这样的架构相较传统的架构更加不稳定，为了解决这样的问题，产生了断路器等一系列的服务保护机制。 "断路器"本身是一种开关装置，用于在电路上保护线路过载，当线路中有电器发生短路，"断路器"能够及时切断故障电路，防止发生过载、发热甚至起火等严重后果。 分布式架构中，断路器模式的作用也是类似的，当某个服务单元发生故障（类似于用电器发生短路）之后，通过断路器的故障监控（l类似熔断器保险丝），向调用方返回一个错误响应，而不是长时间的等待。这样就不会使得线程因调用故障服务被长时间占用不释放，避免了故障在分布式系统的蔓延。 针对上述问题，SpringCloudHystrix实现了断路器、线程隔离等一系列服务保护功能。它也是基于Netflix的开源框架Hystrix实现的，该框架的目标在于通过控制那些访问远程系统、服务和第三方库的节点，从而对延迟和故障提供强大的容错能力。Hystrix具备服务降级、服务熔断、线程和信号隔离、请求缓存合并以及服务监控等强大的功能。 -----来自《SpringCloud微服务实战》 ​ 上图为正常的微服务调用 ​ 当某个服务出现故障Hystrix回退防止级联故障，较低级别的服务中的服务故障可能导致用户级联故障。当对特定服务的检测达到一定阈值时

1.引入组件的启动器 2.覆盖默认配置 3.在引导类上添加注解，开发相关组件 Map<serviceId， Map<服务实例名，实例对象(instance)>> 1.架构的演变 传统架构-->水平拆分-->垂直拆分（最早的分布式）-->soa(dubbo)-->微服务(springCloud) 2.远程调用技术：rpc http rpc协议：自定义数据格式，限定技术，传输速度快，效率高 tcp，dubbo http协议：统一的数据格式，不限定技术 rest接口 tcp协议 springCloud 3.什么是springCloud 微服务架构的解决方案，是很多组件的集合 eureka：注册中心，服务的注册与发现 zull：网关协议，路由请求，过滤器（ribbon hystrix） ribbon：负载均衡组件 hystrix：熔断组件 feign：远程调用组件(ribbon hystrix) *4.eureka 注册中心：eureka（1.引入启动器， 2.配置spring.application.name=eureka 3.在引导类上@EnableEurekaServer） 客户端：service-provider service-consumer （1.引入启动器 2.配置spring.application.name eureka.client.service-url

hystrix-dashboard- server 1. File-->new spring starter project 2.add dependency <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.1.5.RELEASE</version> <relativePath/> <!-- lookup parent from repository --> </parent> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-hystrix-dashboard</artifactId> </dependency> 3.Edit application.yml server: port: 9000 spring: application: name: hystrix-dashboard-server # #eureka: # client: # service-url: # defaultZone: http://localhost:8761/eureka

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

简单尝试Spring Cloud Gateway 简介 Spring Cloud Gateway是一个API网关，它是用于代替Zuul而出现的。Spring Cloud Gateway构建于Spring生态系统之上，包括Spring5，SpringBoot2等。它的目标是提供简单、有效的方式路由你的API。 Spring Cloud Gateway不能在传统的Servlet容器中工作，也不能构建成一个war包工作。这一点很重要。 重要概念 路由：Gateway的基础构建模块。它包括一个ID，一个目标URL，一个断言集合和一个过滤器集合。如果断言判断为真，则路由匹配。 断言：这是Java8的新增功能，输入的类型为Spring框架的ServerWebExchange。它可以匹配HTTP请求中的任何东西，比如：请求头或者参数。 过滤器：是Spring框架的GatewayFilter，请求和响应都可以被Filter修改。 　　Spring Cloud Gateway的流程图如下： 创建一个简单的路由 首先我们使用IDEA创建Spring-boot项目，并选择spring-cloud-starter-gateway依赖， 请注意，这里千万不能选择spring-boot-starter-web，它们两个不能同时存在 。然后我们在启动类中，增加如下代码： 　　@Bean public

1. 为什么是Spring Cloud Gateway 一句话， Spring Cloud已经放弃Netflix Zuul了 。现在Spring Cloud中引用的还是Zuul 1.x版本，而这个版本是基于过滤器的，是阻塞IO，不支持长连接。Zuul 2.x版本跟1.x的架构大一样，性能也有所提升。既然Spring Cloud已经不再集成Zuul 2.x了，那么是时候了解一下Spring Cloud Gateway了。 可以看到，最新的Spring Cloud中的Zuul还是1.3.1版本 而且，官网中也明确说了不再维护Zuul了 （PS：顺便补充几个名词： 服务发现（Eureka），断路器（Hystrix），智能路由（Zuul），客户端负载均衡（Ribbon）） 2. API网关 API网关是一个服务器，是系统的唯一入口。从面向对象设计的角度看，它与外观模式类似。API网关封装了系统内部架构，为每个客户端提供一个定制的API。它可能还具有其它职责，如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。API网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。通常，网关也是提供REST/HTTP的访问API。 网关应当具备以下功能： 性能：API高可用，负载均衡，容错机制。 安全：权限身份认证、脱敏，流量清洗，后端签名

前言 今天和大家聊一聊在Spring Cloud微服务框架实践中，比较核心但是又很容易把人搞得稀里糊涂的一个问题，那就是在 Spring Cloud 中 Hystrix 、 Ribbon 以及 Feign 它们三者之间在处理微服务调用超时从而触发熔断降级的关系是什么？ 我们知道在 Spring Cloud 微服务体系下， 微服务之间的互相调用可以通过 Feign 进行声明式调用，在这个服务调用过程中 Feign 会通过 Ribbon 从服务注册中心获取目标微服务的服务器地址列表，之后在网络请求的过程中 Ribbon 就会将请求以负载均衡的方式打到微服务的不同实例上 ，从而实现 Spring Cloud 微服务架构中最为关键的功能即服务发现及客户端负载均衡调用。 另一方面微服务在互相调用的过程中， 为了防止某个微服务的故障消耗掉整个系统所有微服务的连接资源，所以在实施微服务调用的过程中我们会要求在调用方实施针对被调用微服务的熔断逻辑 。而要实现这个逻辑场景在 Spring Cloud 微服务框架下我们是通过 Hystrix 这个框架来实现的。 调用方会针对被调用微服务设置调用超时时间，一旦超时就会进入熔断逻辑，而这个故障指标信息也会返回给 Hystrix 组件， Hystrix 组件会根据熔断情况判断被调微服务的故障情况从而打开熔断器，之后所有针对该微服务的请求就会直接进入熔断逻辑