hystrix

目录 Hystrix是什么 Hystrix用来做什么 Hystrix解决什么问题 Hystrix设计原则 Hystrix如何实现目标 Hystrix是什么 在分布式环境下，难免出现许多服务之间调用失败的场景， Hystrix是一个通过添加延迟容忍和容错逻辑帮助您控制这些分布式服务之间交互的库。 Hystrix通过隔离服务之间的访问点来实现应用之间连锁故障（因下游服务失败，导致上游服务不可用），出现故障提供备选方案来提高应用整体的可用性。 举例：抢购活动中，由于库存服务超时或者崩掉，可以通过提示抢购失败，请稍后重试等预防抢购应用不可用 Hystrix用来做什么 Hystrix可以做一些事情： 通过第三方客户端库，为控制延迟和依赖之间调用失败提供保护。 在复杂的分布式系统中阻止连锁故障 快速故障恢复 在可能的情况下，做到服务隔离和优雅降级 尽可能的实时监控、报警、运维控制 Hystrix解决什么问题 复杂的分布式应用有许多依赖调用，在某一时刻它们之间必然会出现失败，这就是导致应用整体故障的风险。 例如，对于一个依赖于30个服务的应用程序，每个服务的正常运行时间为99.99%，下面是您可以预期的结果。 99.99 的30次方= 99.7% （意味着有0.3%的失败） 10亿*0.3% = 300万（10亿次请求会有300万次请求失败） 即使每个月在很好的正常运行的时间

转自： https://juejin.im/post/5bac48f9f265da0aa52914b4 1、水平权限校验 水平权限漏洞一般出现在一个用户对象关联多个其他对象（订单等）、并且要实现对关联对象的CRUD的时候。 请求包含用户ID及关联对象ID时、务必校验关联对象是否属于该用户； 2、幂等 幂等操作的特点是任意多次执行所产生的影响均与一次执行的影响相同。 幂等操作的基本处理思路是： 调用者给消息一个唯一请求ID标识。ID标识一个工作单元，这个工作单元只应执行一次； 接收者在执行一个工作单元必须先检验该工作单元是否已经执行过。检查是否执行的逻辑通常是根据唯一请求ID ，在服务端查询请求是否有记录，是否有对应的响应信息，如果有，直接把响应信息查询后返回或者返回重复操作错误信息；如果没有，那么就当做新请求去处理。 3、防并发 防并发基本思路是使用锁：1、分布式锁（redis锁）；2、乐观锁（版本号）；3、状态锁定（对数据进行修改前判断前置状态）。 4、异步任务 慎用EventBus、ThreadPool等处理异步任务，服务宕机或者重启时会丢失任务。建议采用mq自发自收。 5、最终一致性 最终一致性为弱一致性、在需要强一致性的场景务必不能采用tmc等方式实现。（例如下单扣减额度等） 6、防重放 常用的防止重放的机制是使用timestamp和nonce做重放机制

高可用架构：Hystrix作为大家熟知的容错组件，最近宣布停止开发，很多人对其背景可能了解不多。作为Spring Cloud官方默认的熔断组件，您觉得Hystrix是出于哪些原因停止开发呢？ 子衿/宿何： 这个事情，我也是之前看媒体报道才了解到的。Hystrix是Netflix的一款开源限流组件，官方宣布停止在开源版本上提供新功能，作为开发者，觉得有点可惜，但仍要感谢Netflix之前以及现在正在为开源做的贡献。 关于Netflix为什么会宣布停止在开源版本上提供新功能，目前官方并没有给出原因，只是提供了一些解决方案。但我看到Netflix官方博客的一篇文章，也许能找到技术层面的考量：Netflix 现在正在探索更自动化的熔断方式。所以我们猜测Netflix内部会逐步不再使用Hystrix ，没有继续更新的动力；再加上 Hystrix 作为一个熔断降级组件已经非常稳定了，因此停止开发是可以理解的。另一个是非技术层面，技术的开源是需要业务的增长和完整的技术团队来支撑的，无论是国内还是国外，开源项目能否持续，依赖于企业在技术上是否能长期投入。博客原文地址[1]。 高可用架构：Hystrix官方推荐使用Resilience4j，你们是怎么看这个项目？ 子衿/宿何： resilience4j 是一个比较轻量的熔断降级库。首先 resilience4j 的模块化做的比较好，将每个功能点

本文对Hystrix、Resilience4j、Sentinel进行对比，并探讨如何使用一行代码将Hystrix迁移到Sentinel。 作者：洛夜，校对：周立 在本博客首发，欢迎转载。 前段时间，Netflix宣布Hystrix进入维护模式，详见 Hystrix停止开发，我们该何去何从？ ，而Spring Cloud亦宣布Spring Cloud Netflix进入维护状态，后续不再进行更新已成为事实。作为开发者的我们，如何使用极简的方式替换Hystrix成为首要解决的问题。 Hystrix 宣布停止维护 后，社区推荐了 Resilience4j ，而业界还有Alibaba Sentinel可供选择——3款产品各有优势，具体的功能差异参考下表(该表来自 Sentinel Wiki ： Sentinel Hystrix resilience4j 隔离策略 信号量隔离（并发线程数限流） 线程池隔离/信号量隔离 信号量隔离 熔断降级策略 基于响应时间、异常比率、异常数 基于异常比率 基于异常比率、响应时间 实时统计实现 滑动窗口（LeapArray） 滑动窗口（基于 RxJava） Ring Bit Buffer 动态规则配置 支持多种数据源 支持多种数据源 有限支持 扩展性 多个扩展点 插件的形式 接口的形式 基于注解的支持 支持 支持 支持 限流 基于 QPS

public static ThreadLocal<String> threadLocal = new ThreadLocal<>(); public static void main(String[] args) { threadLocal.set("main"); Thread t1 = new Thread(new Runnable() { @Override public void run() { System.out.printf("threadlocal1 value:%s\n", threadLocal.get()); threadLocal.set("thread1"); System.out.printf("threadlocal1 value:%s\n", threadLocal.get()); } }); t1.setName("thread1"); t1.start(); Thread t2 = new Thread(new Runnable() { @Override public void run() { System.out.printf("threadlocal2 value:%s\n", threadLocal.get()); threadLocal.set("thread2"); System.out.printf("threadlocal2

Hystrix, a Netflix API for latency and fault tolerance in complex distributed systems uses Bulkhead Pattern technique for thread isolation. Can someone please elaborate on it. General In general, the goal of the bulkhead pattern is to avoid faults in one part of a system to take the entire system down. The term comes from ships where a ship is divided in separate watertight compartments to avoid a single hull breach to flood the entire ship; it will only flood one bulkhead. Implementations of the bulkhead pattern can take many forms depending on what kind of faults you want to protect the

使用说明 如果只是为了让使 用 Sentinel 的限流功能，只需要引入相关的jar包依赖。 添加依赖 添加相关模块的 Adapter Sentinel 为每个构建项目的各个组件都打包成了相应的 Adapter 。项目需要按需引入。 现阶段的Dubbo-Adapter模块最高只支持到dubbo 2.6.6 <dependency> <groupId>com.alibaba.csp</groupId> <artifactId>sentinel-dubbo-adapter</artifactId> <version>1.6.3</version> </dependency> 各个模块的adapter 限流信息上传dashboard 添加参数 添加此依赖，客户端的实时限流信息能汇总到后台管理界面。 <dependency> <groupId>com.alibaba.csp</groupId> <artifactId>sentinel-transport-simple-http</artifactId> <version>1.6.3</version> </dependency> 修改启动参数 # 指定 dashboard的访问地址和自己在dashbaord中要显示的名字。 -Dcsp.sentinel.dashboard.server=localhost:8888 -Dproject

Spring Cloud中，Feign和Ribbon在整合了Hystrix后，可能会出现首次调用失败的问题，要如何解决该问题呢 造成该问题的原因 Hystrix默认的超时时间是1秒，如果超过这个时间尚未响应，将会进入fallback代码。而首次请求往往会比较慢（ 由于Ribbon是懒加载的，在首次请求时，才会开始初始化相关类 ），这个响应时间可能就大于1秒了。知道原因后，我们来总结一下解决方案。以feign为例，解决方案有如下四种。 方法一、将Hystrix超时设长 hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds: 5000 该配置是让Hystrix的超时时间改为5秒，这是最容易想到的办法，不过有点治标不治本。 方法二、禁用Hystrix超时 hystrix.command.default.execution.timeout.enabled: false 该配置，用于禁用Hystrix的超时时间，一般不建议使用。 方法三、为Feign禁用Hystrix 全局禁用 feign.hystrix.enabled: false 索性禁用feign的hystrix，该做法比较极端，除非一些特殊场景，不推荐使用。 局部禁用 为名为 microservice-provider-user 的Feign

在微服务架构中，我们将系统拆分成了一个个的服务单元，各单元应用间通过服务注册与订阅的方式互相依赖。由于每个单元都在不同的进程中运行，依赖通过远程调用的方式执行，这样就有可能因为网络原因或是依赖服务自身问题出现调用故障或延迟，而这些问题会直接导致调用方的对外服务也出现延迟，若此时调用方的请求不断增加，最后就会出现因等待出现故障的依赖方响应而形成任务积压，线程资源无法释放，最终导致自身服务的瘫痪，进一步甚至出现故障的蔓延最终导致整个系统的瘫痪。如果这样的架构存在如此严重的隐患，那么相较传统架构就更加的不稳定。为了解决这样的问题，因此产生了断路器等一系列的服务保护机制。 针对上述问题，在Spring Cloud Hystrix中实现了线程隔离、断路器等一系列的服务保护功能。它也是基于Netflix的开源框架 Hystrix实现的，该框架目标在于通过控制那些访问远程系统、服务和第三方库的节点，从而对延迟和故障提供更强大的容错能力。Hystrix具备了服务降级、服务熔断、线程隔离、请求缓存、请求合并以及服务监控等强大功能。 接下来，我们就从一个简单示例开始对Spring Cloud Hystrix的学习与使用。 动手试一试 在开始使用Spring Cloud Hystrix实现断路器之前，我们先拿之前实现的一些内容作为基础，其中包括： eureka-server 工程：服务注册中心，端口

前言 在上一篇 《Spring Cloud构建微服务架构：服务容错保护（Hystrix服务降级）》 中，我们已经体验了如何使用 @HystrixCommand 来为一个依赖资源定义服务降级逻辑。实现方式非常简单，同时对于降级逻辑还能实现一些更加复杂的级联降级等策略。之前对于使用Hystrix来实现服务容错保护时，除了服务降级之外，我们还提到过线程隔离、断路器等功能。那么在本篇中我们就来具体说说线程隔离。 依赖隔离 “舱壁模式”对于熟悉Docker的读者一定不陌生，Docker通过“舱壁模式”实现进程的隔离，使得容器与容器之间不会互相影响。而Hystrix则使用该模式实现线程池的隔离，它会为每一个Hystrix命令创建一个独立的线程池，这样就算某个在Hystrix命令包装下的依赖服务出现延迟过高的情况，也只是对该依赖服务的调用产生影响，而不会拖慢其他的服务。 通过对依赖服务的线程池隔离实现，可以带来如下优势： 应用自身得到完全的保护，不会受不可控的依赖服务影响。即便给依赖服务分配的线程池被填满，也不会影响应用自身的额其余部分。 可以有效的降低接入新服务的风险。如果新服务接入后运行不稳定或存在问题，完全不会影响到应用其他的请求。 当依赖的服务从失效恢复正常后，它的线程池会被清理并且能够马上恢复健康的服务，相比之下容器级别的清理恢复速度要慢得多。 当依赖的服务出现配置错误的时候