hystrix

一.服务器雪崩效应 在SpringCloud中存在多个微服务的调用情况，当服务的提供者不可用时，多次调用失败可能会导致服务调用者的不可用，逐渐扩展到整个系统不可用，这种情况称为服务器雪崩效应，下面图中展示服务的故障扩散，那么在SpringCloud中，解决这一效应就变得尤为重要，SpringCloud中通过Hystrix熔断器的熔断机制提高服务的容错能力。 二.熔断器的原理 Hystrix如同电力系统中断路器，在一定时期内检测到多次类似的错误，它将会强迫后续的多次调用快速失败，使应用不再访问远程服务，不再执行可能失败的错误访问，从而使得应用程序能够继续执行而不再等待错误的修正，或者等待长时间的超时产生，同时熔断器还具有诊断错误是否修正的能力，当错误修正时，服务会再次尝试调用。原理图如下图所示: 三.配置Hystrix 由于Hystrix只是用于服务调用端，所以引用上面spring-cloud-consumer项目进行改造，因为Feign中已经有了Hystrix的依赖，所以不需要添加新的配置 1.配置文件中添加 feign.hystrix.enabled = true 2.实现HelloRemote接口，重写方法 @Component public class HelloRemoteHystrix implements HelloRemote{ @Override public

一、雪崩效应 　　在微服务架构中，由于服务和服务之间可以互相调用，一项工作的完成可能会依赖调用多个微服务模块，但由于网络原因或者自身的原因，服务并不能保证100%可用，如果单个服务出现问题，调用这个服务就会出现线程阻塞，此时若有大量的请求涌入，Servlet容器的线程资源会被消耗完毕，导致服务瘫痪；再加上服务和服务之间的依赖性，瘫痪会迅速传播，给整个微服务系统造成严重的后果，这就是服务故障的“血崩”效应。 服务雪崩效应形成的阶段 1、服务提供者不可用 硬件故障。硬件损坏导致服务器主机宕机，或网络硬件故障造成服务提供者的不可访问。 程序Bug 缓存击穿。一般发生在缓存应用重启，所有缓存被清空时，以及短时间内大量缓存失效时。大量的缓存不命中，使请求直击后端，造成服务提供者超负荷运行，引起服务不可用。 用户大量请求 2、重试加大流量 用户重试 代码逻辑重试 3、服务调用者不可用 同步等待造成资源耗尽。同步调用时，产生大量的等待线程占用系统资源。 二、服务雪崩的应对措施 针对造成服务雪崩的不同原因，可以采用不同的应对措施。 1、流量控制 网关限流 用户交互限流，例如：1.采用加载动画，提高用户的忍耐等待时间。2.提交按钮添加强制等待机制等。 关闭重试 2、改进缓存模式 缓存预加载 同步改为异步刷新 3、服务自动扩容 AWS的auto scaling 4、服务调用者降级服务 资源隔离

demo 演示 @HystrixCommand( groupKey = "thread-control1", fallbackMethod = "failback", commandProperties = { @HystrixProperty(name = "execution.isolation.strategy", value = "SEMAPHORE"), @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "100"), //超时时间 @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold", value = "50"),//触发熔断最小请求数量 @HystrixProperty(name = "circuitBreaker.errorThresholdPercentage", value = "30"),//触发熔断的错误占比阈值 @HystrixProperty(name = "circuitBreaker.sleepWindowInMilliseconds", value = "3000"),//熔断器回复时间 @HystrixProperty(name = "execution

修改请求路径的过滤器 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

来源： 常见的缓存穿透，缓存击穿，缓存雪崩解决方案分析 前言 设计一个缓存系统，不得不要考虑的问题就是：缓存穿透、缓存击穿与失效时的雪崩效应。 缓存穿透 缓存穿透是指查询一个一定不存在的数据，由于缓存是不命中时被动写的，并且出于容错考虑，如果从存储层查不到数据则不写入缓存，这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。在流量大时，可能DB就挂掉了，要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞。 解决方案 有很多种方法可以有效地解决缓存穿透问题，最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被 这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。另外也有一个更为简单粗暴的方法（我们采用的就是这种），如果一个查询返回的数据为空（不管是数 据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。 缓存雪崩 缓存雪崩是指在我们设置缓存时采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到DB，DB瞬时压力过重雪崩。 解决方案 缓存失效时的雪崩效应对底层系统的冲击非常可怕。大多数系统设计者考虑用加锁或者队列的方式保证缓存的单线 程（进程）写，从而避免失效时大量的并发请求落到底层存储系统上。这里分享一个简单方案就时讲缓存失效时间分散开

序 本文主要研究一下spring cloud netflix的HystrixCommands。 maven <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-hystrix</artifactId> <version>2.0.0.RELEASE</version> </dependency> 这个组件对hystrix进行了封装了，2.0.0.RELEASE全面支持了Reactor的Reactive Streams。 spring-cloud-starter-netflix-hystrix/pom.xml spring-cloud-starter-netflix-hystrix-2.0.0.RELEASE.jar!/META-INF/maven/org.springframework.cloud/spring-cloud-starter-netflix-hystrix/pom.xml <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http

【 前面的话 】书接上文，本文的某些知识依赖我的第一篇SpringCLoud的文章： SpringCloud之Eureka ，如果没有看过可以先移步去看一下。另外在微服务架构中，业务都会被拆分成一个个独立的服务，服务与服务的通讯是基于http restful的。Spring cloud有两种服务调用方式，一种是ribbon+restTemplate，另一种是feign。上一篇文章已经讲过 ribbon+rest 这种方式了，这一片博文主要讲feign的应用。 壹、Feign的简介 Feign是一个声明式的伪Http客户端，它使得写Http客户端变得更简单。使用Feign，只需要创建一个接口并注解。它具有可插拔的注解特性，可使用Feign 注解和JAX-RS注解。Feign支持可插拔的编码器和解码器。Feign默认集成了Ribbon，并和Eureka结合，默认实现了负载均衡的效果。 简而言之： Feign 采用的是基于接口的注解 Feign 整合了ribbon 贰、准备工作 新建一个feign子工程 lovin-feign-client ，用于后面的操作。下面是主要的pom依赖: ~~~pom lovincloud com.eelve.lovincloud 1.0-SNAPSHOT 4.0.0 <artifactId>lovin-feign-client</artifactId>

【 前面的话 】书接上文，本文的某些知识依赖我的第一篇SpringCLoud的文章： SpringCloud之Eureka ，如果没有看过可以先移步去看一下。另外在微服务架构中，业务都会被拆分成一个个独立的服务，服务与服务的通讯是基于http restful的。Spring cloud有两种服务调用方式，一种是ribbon+restTemplate，另一种是feign。上一篇文章已经讲过 ribbon+rest 这种方式了，这一片博文主要讲feign的应用。 壹、Feign的简介 Feign是一个声明式的伪Http客户端，它使得写Http客户端变得更简单。使用Feign，只需要创建一个接口并注解。它具有可插拔的注解特性，可使用Feign 注解和JAX-RS注解。Feign支持可插拔的编码器和解码器。Feign默认集成了Ribbon，并和Eureka结合，默认实现了负载均衡的效果。 简而言之： Feign 采用的是基于接口的注解 Feign 整合了ribbon 贰、准备工作 新建一个feign子工程 lovin-feign-client ，用于后面的操作。下面是主要的pom依赖: <parent> <artifactId>lovincloud</artifactId> <groupId>com.eelve.lovincloud</groupId> <version>1.0

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

Hystrix 隔离策略细粒度控制 Hystrix 实现资源隔离，有两种策略： 线程池隔离 信号量隔离 对资源隔离这一块东西，其实可以做一定细粒度的一些控制。 execution.isolation.strategy 指定了 HystrixCommand.run() 的资源隔离策略： THREAD or SEMAPHORE ，一种基于线程池，一种基于信号量。 // to use thread isolation HystrixCommandProperties.Setter().withExecutionIsolationStrategy(ExecutionIsolationStrategy.THREAD) // to use semaphore isolation HystrixCommandProperties.Setter().withExecutionIsolationStrategy(ExecutionIsolationStrategy.SEMAPHORE) 线程池机制，每个 command 运行在一个线程中，限流是通过线程池的大小来控制的；信号量机制，command 是运行在调用线程中，通过信号量的容量来进行限流。 如何在线程池和信号量之间做选择？ 默认的策略 就是线程池。 线程池 其实最大的好处就是对于网络访问请求，如果有超时的话，可以避免调用线程阻塞住。