Hystrix提供了熔断、隔离、Fallback、cache、监控等功能，能够在一个、或多个依赖同时出现问题时保证系统依然可用。 将服务的接口使用hystrix线程池做隔离，可以实现限流和熔断的效果。配合天舟平台提供的SpringCloudConfig配置中心，可以在不重启服务的情况下，动态调整hystrix限流的参数。
springboot工程使用hystrix的配置步骤: 1.pom.xml:
<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-hystrix</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-hystrix-dashboard</artifactId> </dependency>2.开启hystrix及hystrixDashboard:
入口类加注解，@EnableHystrix,@EnableHystrixDashboard @SpringBootApplication @EnableHystrix @EnableHystrixDashboard public class ContestDemoApplication{ public static void main(String[] args) { SpringApplication.run(ContestDemoApplication.class, args); } }3.@HystrixCommand注解:
@HystrixCommand 加到服务的接口方法上，可以对接口限流。 下面的代码，给服务的 /hello接口 加了hystrix线程隔离，并且限制并发为5。 当接口熔断或者降级时，会走降级方法，降级方法将异常信息返回，并且返回状态码 503 @RestController @RequestMapping(value = "/contest/demo") public class HelloController { //对controller层的接口做hystrix线程池隔离，可以起到限流的作用 @HystrixCommand( commandKey = "helloCommand",//缺省为方法名 threadPoolKey = "helloPool",//缺省为类名 fallbackMethod = "fallbackMethod",//指定降级方法，在熔断和异常时会走降级方法 commandProperties = { //超时时间 @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "1000") }, threadPoolProperties = { //并发，缺省为10 @HystrixProperty(name = "coreSize", value = "5") } ) @RequestMapping( value = "/hello", method = RequestMethod.GET ) public String sayHello(HttpServletResponse httpServletResponse){ return "Hello World!：00000"; } /** * 降级方法，状态码返回503 * 注意，降级方法的返回类型与形参要与原方法相同，可以多一个Throwable参数放到最后，用来获取异常信息 */ public String fallbackMethod(HttpServletResponse httpServletResponse,Throwable e){ httpServletResponse.setStatus(HttpStatus.SERVICE_UNAVAILABLE.value()); return e.getMessage(); }}
hystrix的属性配置:
如果将@HystrixCommand注解加到方法上，不对属性（如CoreSize）做任何配置，那么相当于使用了如下缺省配置。 每个属性的意义可以参考 hystrix学习资料 @HystrixCommand( commandProperties = { //execution @HystrixProperty(name = "execution.isolation.strategy", value = "THREAD"), @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "1000"), @HystrixProperty(name = "execution.timeout.enabled", value = "true"), @HystrixProperty(name = "execution.isolation.thread.interruptOnTimeout", value = "true"), @HystrixProperty(name = "execution.isolation.thread.interruptOnCancel", value = "false"), @HystrixProperty(name = "execution.isolation.semaphore.maxConcurrentRequests", value = "10"), //fallback @HystrixProperty(name = "fallback.isolation.semaphore.maxConcurrentRequests", value = "10"), @HystrixProperty(name = "fallback.enabled", value = "true"), //circuit breaker @HystrixProperty(name = "circuitBreaker.enabled", value = "true"), @HystrixProperty(name = "circuitBreaker.forceClosed", value = "false"), @HystrixProperty(name = "circuitBreaker.forceOpen", value = "false"), @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold", value = "20"), @HystrixProperty(name = "circuitBreaker.sleepWindowInMilliseconds", value = "5000"), @HystrixProperty(name = "circuitBreaker.errorThresholdPercentage", value = "50"), //Metrics @HystrixProperty(name = "metrics.rollingStats.timeInMilliseconds", value = "10000"), @HystrixProperty(name = "metrics.rollingStats.numBuckets", value = "10"), @HystrixProperty(name = "metrics.rollingPercentile.enabled", value = "true"), @HystrixProperty(name = "metrics.rollingPercentile.timeInMilliseconds", value = "60000"), @HystrixProperty(name = "metrics.rollingPercentile.numBuckets", value = "6"), @HystrixProperty(name = "metrics.rollingPercentile.bucketSize", value = "100"), @HystrixProperty(name = "metrics.healthSnapshot.intervalInMilliseconds", value = "500"), //request context @HystrixProperty(name = "requestCache.enabled", value = "true"), @HystrixProperty(name = "requestLog.enabled", value = "true")}, threadPoolProperties = { @HystrixProperty(name = "coreSize", value = "10"), @HystrixProperty(name = "maximumSize", value = "10"), @HystrixProperty(name = "maxQueueSize", value = "-1"), @HystrixProperty(name = "queueSizeRejectionThreshold", value = "5"), @HystrixProperty(name = "keepAliveTimeMinutes", value = "1"), @HystrixProperty(name = "allowMaximumSizeToDivergeFromCoreSize", value = "false"), @HystrixProperty(name = "metrics.rollingStats.timeInMilliseconds", value = "10000"), @HystrixProperty(name = "metrics.rollingStats.numBuckets", value = "10") } ) 如果要自定义这些属性，那么需要先了解下hystrix属性配置的优先级。4 个不同优先级别的配置（优先级由低到高）。 全局配置属性：通过在配置文件中定义全局属性值， 在应用启动时或可用Spring Cloud Config和服务本身的动态刷新接口实现的动态刷新配置功能下， 可以实现对“全局默认值”的覆盖以及在运行期对“全局默认值”的动态调整。
如下是 threadpool 和 command下的属性全局配置，注意具体的配置都在 default 下 #hystrix全局属性配置 hystrix: threadpool: default: #对应@HystrixCommand注解中threadPoolKey的属性值，默认为default coreSize: 50 #线程池的核心线程数及并发执行的最大线程数 command: default: #对应@HystrixCommand注解中commandKey的属性值，默认为default execution: isolation: thread: timeoutInMilliseconds: 1000 #执行超时时间 fallback: isolation: semaphore: maxConcurrentRequests: 1000 #任意时间点允许的降级方法并发数。当请求达到或超过该设置值其余请求不会调用fallback而是直接被拒绝 实例默认值：通过代码为实例定义的默认值。 通过代码的方式为实例设置属性值来覆盖默认的全局配置。 示例如下： @HystrixCommand( commandKey = "helloCommand",//缺省为方法名 threadPoolKey = "helloPool",//缺省为类名 fallbackMethod = "fallbackMethod",//指定降级方法，在熔断和异常时会走降级方法 commandProperties = { //超时时间 @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "1000") }, threadPoolProperties = { //并发，缺省为10 @HystrixProperty(name = "coreSize", value = "5") } ) @RequestMapping( value = "/hello", method = RequestMethod.GET ) public String sayHello(HttpServletResponse httpServletResponse){ return "Hello World!：00000"; }实例配置属性：通过配置文件来为指定的实例进行属性配置， 以覆盖前面的三个默认值。 它也可用Spring Cloud Config和服务本身的动态刷新接口实现的动态刷新配置功能，实现对具体实例配置的动态调整。
以示例代码中的 /hello 接口为例， commandKey=helloCommand threadPoolKey=helloPool,那么对其的配置如下 #hystrix参数配置 hystrix: threadpool: helloPool: #注解中的threadPoolKey属性值, 如有特殊配置不想使用defualt默认配置可自行添加 coreSize: 20 command: helloCommand: #注解中的commandKey属性值,如有特殊配置不想使用默认配置可自行添加 execution: isolation: thread: timeoutInMilliseconds: 4000 #执行超时时间
服务熔断 在微服务架构中，微服之间互相调用。如微服务A调用微服务B和微服务C，微服务B和微服务C又调用其它的微服务，这就是所谓的“扇出”。如果扇出的链路上某个微服务的调用响应时间过长或者不可用，微服务A的就会堆积大量的未响应的的请求，进而引起系统崩溃，所谓的“雪崩效应”。熔断机制是应对雪崩效应的一种微服务链路保护机制。当扇出链路的某个微服务不可用或者响应时间太长时，就熔断该节点微服务的调用，快速返回错误的响应信息。
服务降级 降级是指自己的待遇下降了，就是此时客户端可以自己准备一个本地的fallback（回退）回调，返回一个缺省值。 当双11活动时，把无关交易的服务统统降级，如查看蚂蚁深林，查看历史订单，商品历史评论，只显示最后100条等等。
服务限流
限流的目的是通过对并发访问/请求进行限速或者一个时间窗口内的的请求进行限速来保护系统，一旦达到限制速率则可以拒绝服务（定向到错误页或告知资源没有了）、排队或等待（比如秒杀、评论、下单）、降级（返回兜底数据或默认数据，如商品详情页库存默认有货）。一般开发高并发系统常见的限流有：限制总并发数（比如数据库连接池、线程池）、限制瞬时并发数（如nginx的limit_conn模块，用来限制瞬时并发连接数）、限制时间窗口内的平均速率（如Guava的RateLimiter、nginx的limit_req模块，限制每秒的平均速率）；其他还有如限制远程接口调用速率、限制MQ的消费速率。另外还可以根据网络连接数、网络流量、CPU或内存负载等来限流。
常见的限流算法有：令牌桶、漏桶。计数器也可以进行粗暴限流实现。
计数器方法 系统维护一个计数器，来一个请求就加1，请求处理完成就减1，当计数器大于指定的阈值，就拒绝新的请求。 基于这个简单的方法，可以再延伸出一些高级功能，比如阈值可以不是固定值，是动态调整的。另外，还可以有多组计数器分别管理不同的服务，以保证互不影响等。
漏桶(Leaky Bucket)算法思路很简单,水(请求)先进入到漏桶里,漏桶以一定的速度出水(接口有响应速率),当水流入速度过大会直接溢出(访问频率超过接口响应速率),然后就拒绝请求,可以看出漏桶算法能强行限制数据的传输速率.示意图如下: 这里写图片描述
令牌桶算法(Token Bucket)和 Leaky Bucket 效果一样但方向相反的算法,更加容易理解.随着时间流逝,系统会按恒定1/QPS时间间隔(如果QPS=100,则间隔是10ms)往桶里加入Token(想象和漏洞漏水相反,有个水龙头在不断的加水),如果桶已经满了就不再加了.新请求来临时,会各自拿走一个Token,如果没有Token可拿了就阻塞或者拒绝服务. 这里写图片描述
令牌桶的另外一个好处是可以方便的改变速度. 一旦需要提高速率,则按需提高放入桶中的令牌的速率. 一般会定时(比如100毫秒)往桶中增加一定数量的令牌, 有些变种算法则实时的计算应该增加的令牌的数量.
