hystrix

1.开启支持Hytrix 在application.yml中配置开启（这是需要增加的配置） feign: hystrix: enabled: true #开启熔断支持 client: config: remote-service: #服务名，填写default为所有服务 connectTimeout: 3000 readTimeout: 3000 hystrix: command: default: execution: isolation: thread: timeoutInMilliseconds: 3000 2.写入类，实现回调类 在我们定义的接口中在添加 @FeignClient(name = "USER-SERVER", fallback = HystrixClientFallback.class ) 实现HystrixClientFallback 需要使用 @Component，不然会注入失败 package cn.jiedada.Feign.impl; import cn.jiedada.Feign.UserFeginClient; import cn.jiedada.domain.User; import org.springframework.stereotype.Component; @Component public class

Hystrix作用 资源隔离 （限流） ：包括 线程池隔离 和 信号量隔离 ，限制调用分布式服务的资源使用， 某一个调用的服务出现问题不会影响其他服务调用。 熔 断 ： 当失败率达到阀值自动触发降级 ( 如因网络故障 / 超时造成的失败率高 ) ，熔断器触发的快速失败会进行快速恢复 。 降级机制 ： 超时降级、资源不足时 ( 线程或信号量 ) 降级，降级后可以配合降级接口返回托底数据。 缓存：提供了请求缓存、请求合并实现。 A. 1.导包 <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-hystrix</artifactId> </dependency> 2.在主配置类上加注解 @EnableCircuitBreaker package cn.jiedada; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.boot.builder.SpringApplicationBuilder; import org.springframework.cloud.client.circuitbreaker

本文采用Spring cloud本文为2.1.8RELEASE，version=Greenwich.SR3 本文基于前两篇文章 eureka-server、eureka-client、eureka-ribbon 和 spring-gateway 的实现。 参考 eureka-server eureka-client eureka-ribbon spring-cloud-stream 概述 Spring Cloud Stream 是一个构建消息驱动微服务的框架。它通过使用 Spring Integration 来连接消息代理中间件以及实现消息事件驱动的微服务应用。Spring Cloud Stream 为一些供应商的消息中间件产品提供了个性化的自动化配置实现，并且引入了发布-订阅、消费组以及消息分区这三个核心概念。简单的说，Spring Cloud Stream 本质上就是整合了 Spring Boot 和 Spring Integration，实现了一套轻量级的消息驱动的微服务框架。 1. 创建 Spring Cloud Stream 应用： spring-cloud-stream 1.1 增加 pom 依赖 <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud

Hystrix集群及监控turbine 前面Dashboard演示的仅仅是单机服务监控，实际项目基本都是集群，所以这里集群监控用的是turbine。 turbine是基于Dashboard的。 先搞个集群； 再microservice-student-provider-hystrix-1004项目的基础上再搞一个microservice-student-provider-hystrix 代码和配置都复制一份，然后修改几个地方； 1、yml配置 --- server: port: 1004 context-path: / spring: datasource: type: com.alibaba.druid.pool.DruidDataSource driver-class-name: com.mysql.jdbc.Driver url: jdbc:mysql://localhost:3306/t224?useUnicode=true&characterEncoding=utf8 username: root password: 123 jpa: hibernate: ddl-auto: update show-sql: true application: name: microservice-student profiles: provider-hystrix-1004

概述 在 Ribbon 和 Feign 项目增加 Hystrix 仪表盘功能，两个项目的改造方式相同 # 在 pom.xml 中增加依赖 <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-hystrix-dashboard</artifactId> </dependency> # 在 Application 中增加 @EnableHystrixDashboard 注解 package com.snake.hello.spring.cloud.web.admin.ribbon; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.cloud.client.discovery.EnableDiscoveryClient; import org.springframework.cloud.netflix.hystrix.EnableHystrix; import org.springframework

概述 在微服务架构中，根据业务来拆分成一个个的服务，服务与服务之间可以通过 RPC 相互调用，在 Spring Cloud 中可以用 RestTemplate + Ribbon 和 Feign 来调用。为了保证其高可用，单个服务通常会集群部署。由于网络原因或者自身的原因，服务并不能保证 100% 可用，如果单个服务出现问题，调用这个服务就会出现线程阻塞，此时若有大量的请求涌入， Servlet 容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的 “雪崩” 效应。 为了解决这个问题，业界提出了熔断器模型。 Netflix 开源了 Hystrix 组件，实现了熔断器模式，Spring Cloud 对这一组件进行了整合。在微服务架构中，一个请求需要调用多个服务是非常常见的，如下图： 较底层的服务如果出现故障，会导致连锁故障。当对特定的服务的调用的不可用达到一个阀值（Hystrix 是 5 秒 20 次） 熔断器将会被打开。 熔断器打开后，为了避免连锁故障，通过 fallback 方法可以直接返回一个固定值。 # Ribbon 中使用熔断器 # 在 pom.xml 中增加依赖 <dependency> <groupId>org.springframework.cloud</groupId>

1 前言 在我们的平常的项目中多多少少都会使用到缓存，因为一些数据我们没有必要每次查询的时候都查询到数据库。 特别是高QPS的系统，每次都去查询数据库，对于你的数据库来说将是灾难。 今天我们不牵涉多级缓存的知识，就把系统使用到的缓存方案，不管是一级还是多级的都统统成为缓存，主要是为了讲述使用缓存的时候可能会遇到的一些问题以及一些解决办法。 我们缓存时，我们的业务系统大概的调用流程如下图片： 当我们查询一条数据时，先去查询缓存，如果缓存有就直接返回，如果没有就去查询数据库，然后返回。这种情况下就可能会出现一些现象。 2 缓存穿透 2.1 什么是缓存 正常情况下，我们去查询数据都是存在的。 那么请求去查询一条压根儿数据库中根本就不存在的数据，也就是缓存和数据库都查询不到这条数据，但是请求每次都会打到数据库上面去。 这种查询不存在数据的现象我们称为缓存穿透。 2.2 穿透带来的问题 试想一下，如果有黑客会对你的系统进行攻击，拿一个不存在的id 去查询数据，会产生大量的请求到数据库去查询。可能会导致你的数据库由于压力过大而宕掉。 2.3 解决办法 2.3.1 缓存空值 之所以会发生穿透，就是因为缓存中没有存储这些空数据的key。从而导致每次查询都到数据库去了。 那么我们就可以为这些key对应的值设置为null 丢到缓存里面去。后面再出现查询这个key 的请求的时候，直接返回null。 这样

目的:　　 　 服务雪崩效应 　　 服务熔断服务降级 　　 Hystrix 默认超时时间设置 　　 Hystrix 服务监控 Dashboard 服务雪崩效应 　　 雪崩效应就是一种不稳定的平衡状态也是加密算法的一种特征，它指明文或密钥的少量变化会引起密文的很大变化，就像雪崩前，山上看上去很平静，但是只要有一点问题，就会造成一片 大崩溃 。 正常情况下的访问 但是，当 请求的服务中出现无法访问、异常、超时等问题时（图中的 I），那么用户的请求将会被阻塞。 如果多个用户的请求中，都存在无法访问的服务，那么他们都将陷入阻塞的状态中。 Hystrix的引入，可以通过服务熔断和服务降级来解决这个问题 服务熔断服务降级 Hystrix断路器简介 Hystrix 是 Netflix 针对微服务分布式系统采用的熔断保护中间件，相当于电路中的保险丝。 在分布式环境中，许多服务依赖项中的一些必然会失败。Hystrix 是一个库，通过添加延迟容忍和容错逻辑，帮助你控制这些分布式服务之间的交互。Hystrix 通过隔离服务之间的访问点、停止级联失败和提供回退选项来实现这一点，所有这些都可以提高系统的整体弹性。 在微服务架构下，很多服务都相互依赖，如果不能对依赖的服务进行隔离，那么服务本身也有可能发生故障，Hystrix 通过 HystrixCommand 对调用进行隔离，这样可以阻止故障的连锁效应

1、服务雪崩效应 2、服务熔断服务降级 3、Hystrix 默认超时时间设置 4、Hystrix 服务监控 Dashboard 服务雪崩效应 定义： 服务雪崩效应是一种因服务提供者的不可用导致服务调用者的不可用,并将不可用逐渐放大的过程. 如果所示: A为服务提供者, B为A的服务调用者, C和D是B的服务调用者. 当A的不可用,引起B的不可用,并将不可用逐渐放大C和D时, 服务雪崩就形成了. 形成原因 服务雪崩的过程可以分为三个阶段： 服务提供者不可用； 重试加大请求流量； 服务调用者不可用； 服务雪崩的每个阶段都可能由不同的原因造成，总结如下： Hystrix的引入，可以通过服务熔断和服务降级来解决这个问题 服务熔断服务降级 Hystrix断路器简介： 在一个分布式系统里，许多依赖不可避免的会调用失败，比如超时、异常等，如何能够保证在一个依赖出问题的情况下，不会导致整体服务失败，这个就是Hystrix需要做的事情。Hystrix提供了熔断、隔离、Fallback、cache、监控等功能，能够在一个、或多个依赖同时出现问题时保证系统依然可用。 Hystrix服务熔断服务降级@HystrixCommand fallbackMethod 熔断机制是应对雪崩效应的一种微服务链路保护机制。 当某个服务不可用或者响应时间超时，会进行服务降级，进而熔断该节点的服务调用

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