hystrix

目录 SpringCloud 基础 一、概述 二、服务发现组件 Eureka 1. 介绍 2. 搭建 Maven 父工程 3. 创建 Eureka 集群 4. 创建服务提供方集群 5. 创建服务消费方 三、服务调用组件 1. 调用服务基于 LoadBalancerClient 2. 调度服务基于 Ribbon 3. 调度基于 Feign 四、熔断器组件 Hystrix 1. 介绍 2. Ribbon使用Hystrix 3. Feign使用Hystrix 4. Hystrix监控服务器 五、分布式配置中心组件Spring Cloud Config 1. 介绍 2. 构建Config Server 3. 构建Config Client 六、服务网关组件Netflix Zuul 1. 介绍 2.Zuul服务网关搭建 SpringCloud 基础 一、概述 微服务：将传统的一站式应用，拆分成一个个的服务，彻底去耦合，一个微服务就是单功能业务，只做一件事。 微服务是一种架构模式或者一种架构风格，提倡将单一应用程序划分成一组小的服务独立部署服务之间相互配合、相互协调，每个服务运行于自己的进程中。服务与服务间采用轻量级通讯，如HTTP的RESTful API等避免统一的、集中式的服务管理机制 。 微服务优点 每个服务足够内聚，足够小，比较容易聚焦。 开发简单且效率高，一个服务只做一件事情。

前言 本文主要介绍Hystrix的基本功能，原理。Hystrix协调分布式系统中各个服务高可用的框架，SpringCloud体系重要的一员。Hystrix主要解决了服务雪崩问题、服务监控问题等。 Hystrix功能介绍 资源隔离与限流 作用 主要在于预防依赖服务崩溃影响到自己服务资源被耗光，使用隔离的方式限制调用依赖服务所能使用的最大线程资源。如果一个服务崩溃，不控制好资源隔离的话，会引发服务雪崩，众多上游服务集体崩溃。 另外在并发量很大的情况下，也可以降低对依赖服务请求的流量，避免依赖服务过度负载。 原理 Hystrix将对外部服务的调用和一系列处理封装为一个Commond对象，具体分为HystrixCommand（直接调用命令），HystrixObservableCommand（观察者订阅命令），后者可以注册回调事件。两者都可以以异步或同步的方式调用（异步返回Future，后续可以调用get阻塞获取结果）。 Commond对象对资源隔离进行隔离有两种方式，一种是使用线程池（常用），第二种是使用信号量。两者都是对Commond被调用的线程并发数量进行限制，区别在于信号量只是对command被调用并发许可的一个线程，不能记录超时信息等等。 配置项 选择Commond资源隔离的策略，线程池（常用）或信号量 指定command名称、组。名称默认为类名

分布式链路跟踪 Sleuth 与 Zipkin 随着业务发展，系统拆分导致系统调用链路愈发复杂一个前端请求可能最终需要调用很多次后端服务才能完成，当整个请求变慢或不可用时，我们是无法得知该请求是由某个或某些后端服务引起的，这时就需要解决如何快读定位服务故障点，以对症下药。于是就有了分布式系统调用跟踪的诞生。 Spring Cloud Sleuth 也为我们提供了一套完整的解决方案。在本章中，我们将详细介绍如何使用 Spring Cloud Sleuth + Zipkin 来为我们的微服务架构增加分布式服务跟踪的能力。 Spring Cloud Sleuth 一般的，一个分布式服务跟踪系统主要由三部分构成： 数据收集 数据存储 数据展示 根据系统大小不同，每一部分的结构又有一定变化。譬如，对于大规模分布式系统，数据存储可分为实时数据和全量数据两部分，实时数据用于故障排查（Trouble Shooting），全量数据用于系统优化；数据收集除了支持平台无关和开发语言无关系统的数据收集，还包括异步数据收集（需要跟踪队列中的消息，保证调用的连贯性），以及确保更小的侵入性；数据展示又涉及到数据挖掘和分析。虽然每一部分都可能变得很复杂，但基本原理都类似。 服务追踪的追踪单元是从客户发起请求（request）抵达被追踪系统的边界开始，到被追踪系统向客户返回响应（response）为止的过程

本文涵盖 spring cloud 学习示例程序，eureka，feign，rebbion，hystrix，zuul，config，bus使用示例（使用svn管理配置） 。 Eureka注册中心 Eureka服务端配置 @EnableEurekaServer eureka: instance: hostname: localhost client: register-with-eureka: false #是否将eureka自身作为应用注册到eureka注册中心 fetch-registry: false #为true时，可以启动，但报异常：Cannot execute request on any known server serviceUrl: defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/ Eureka客户端配置 @EnableDiscoveryClient spring: application: name: service-a eureka: client: serviceUrl: defaultZone: http://localhost:8010/eureka/ #eureka服务注册地址 Ribbon 客户端的负载均衡 在注入 RestTemplate 调用服务时，加注解

一、前言 1、什么是Turbine？ Turbine是Netflix开源的将Server-Sent Event（SSE）的JSON数据流聚合成单个流的工具。我们可以通过Turbine将Hystrix生产的监控数据（JSON）合并到一个流中，方便我们对存在多个实例的应用进行监控。 Turbine can be used with any data source that fits the supported JSON format of key/value pairs delivered via Server Sent Events. However, it is specifically intended for aggregating streams output by Hystrix so that will be used in all examples. 2、本篇环境信息 框架 版本 Spring Boot 2.0.0.RELEASE Spring Cloud Finchley.RELEASE JDK 1.8.x 3、准备工作 启动Eureka Server： http://localhost:8800 启动Test Service： http://localhost:8602 服务消费者+Hystrix Dashboard准备 修改 feignclient项目

一、前言 1、为什么需要断路器 在分布式架构中，一个应用依赖多个服务是非常常见的，如果其中一个依赖由于延迟过高发生阻塞，调用该依赖服务的线程就会阻塞，如果相关业务的QPS较高，就可能产生大量阻塞，从而导致该应用/服务由于服务器资源被耗尽而拖垮。 另外，故障也会在应用之间传递，如果故障服务的上游依赖较多，可能会引起服务的雪崩效应。就跟数据瘫痪，会引起依赖该数据库的应用瘫痪是一样的道理。 所以，断路器就是用来 支持服务隔离、熔断等操作的工具 。断路器会以隔离的方式来处理服务请求， 当断路数量达到阈值，就会触发熔断（直接返回失败） 。 2、什么是Hystrix？ Hystrix是SOA/微服务架构中提供 服务隔离、熔断、降级机制的工具/框架 。通过以上手段来降低服务故障带来的关联影响，以提高系统的整体可用性。 Hystrix is a latency and fault tolerance library designed to isolate points of access to remote systems, services and 3rd party libraries, stop cascading failure and enable resilience in complex distributed systems where failure is inevitable.

1.在 Servlet 容器线程与 Hystrix 线程中共享变量的问题 今天遇到一个问题，在使用 zuul 的过程中我想要在 Hystrix 执行的线程中获取到 com.netflix.zuul.context.RequestContext 中的数据。不过 RequestContext 是基于 ThreadLocal 的，所以在 Hystrix 执行的线程中调用 com.netflix.zuul.context.RequestContext#getCurrentContext 函数获取到的只能是一个空的没有任何数据的 RequestContext 对象。因为 Hystrix 默认是在另一个线程中执行的 ， 而 zuul filter 则是在 servlet 容器的线程中执行的，基于 ThreadLocal 的 RequestContext 自然无法起作用了。 2.在 Servlet 容器线程与 Hystrix 线程中共享变量的实现方式 2.1 关键类介绍 Hystrix 的设计者们早就考虑到了这个问题，并且提供了解决方案。关键类是 ： com.netflix.hystrix.strategy.concurrency.HystrixRequestContext ，com.netflix.hystrix.strategy.concurrency

为什么需要Hystrix 在大中型分布式系统中，通常系统很多依赖，如下图: 在高并发访问下，这些依赖的稳定性与否对系统的影响非常大，但是依赖有很多不可控问题：如网络连接缓慢，资源繁忙，暂时不可用，服务脱机等，如下图： 当依赖阻塞时，大多数服务器的线程池就出现阻塞，影响整个线上服务的稳定性，如下图： 在复杂的分布式架构的应用程序有很多的依赖，都会不可避免地在某些时候失败。高并发的依赖失败时如果没有隔离措施，当前应用服务就有被拖垮的风险。 Hystrix如何解决依赖隔离 Hystrix使用命令模式HystrixCommand(Command)包装依赖调用逻辑，每个命令在单独线程中/信号授权下执行。 可配置依赖调用超时时间,超时时间一般设为比99.5%平均时间略高即可。当调用超时时，直接返回或执行fallback逻辑。 为每个依赖提供一个小的线程池或信号，如果线程池已满调用将被立即拒绝，默认不采用排队。加速失败判定时间。 依赖调用结果分：成功、失败/抛出异常、超时、线程拒绝、短路。 请求失败(异常，拒绝，超时，短路)时执行fallback(降级)逻辑。 提供熔断器组件，可以自动运行或手动调用，停止当前依赖一段时间(10秒)，熔断器默认错误率阈值为50%，超过将自动运行。 提供近实时依赖的统计和监控。 Hystrix依赖的隔离架构，如下图： 如何使用Hystrix

SpringCloud使用Sentinel（限流） 代替 Hystrix 来源： https://my.oschina.net/u/2351011/blog/3099078