hystrix

本文源码： GitHub·点这里 || GitEE·点这里 一、流量控制 1、基本概念 流量控制的核心作用是限制流出某一网络的某一连接的流量与突发，使这类报文以比较均匀的速度流动发送，达到保护系统相对稳定的目的。通常是将请求放入缓冲区或队列内，然后基于特定策略处理请求，匀速或者批量处理，该过程也称流量整形。 流量控制的核心算法有以下两种：漏桶算法和令牌桶算法。 2、漏桶算法 基础描述 漏桶算法是流量整形或速率限制时经常使用的一种算法，它的主要目的是控制数据注入到网络的速率，平滑网络上的突发流量。漏桶算法提供了一种机制，通过它，突发流量可以被整形以便为网络提供一个稳定的流量。 漏桶算法基本思路：请求（水流）先进入到容器（漏桶）里，漏桶以一定的速度出水，这里就是指流量流出的策略，当流量流入速度过大容器无法承接就会直接溢出，通过该过程限制数据的传输速率。 核心要素 通过上述流程，不难发现漏桶算法涉及下面几个要素： 容器容量 容器的大小直接决定能承接流量的多少，容器一但接近饱和，要么溢出，要么加快流速； 流出速度 流量流出的速度取决于服务的请求处理能力，接口支撑的并发越高，流速就可以越大； 时间控制 基于时间记录，判断流量流出速度，控制匀速模式， 注意：需要一个基本的判定策略，漏桶算法在系统能承接当前并发流量时，不需要启用。 3、令牌桶算法 基础描述

1. 缓存的收益与成本 1. 收益： 加速读写 读缓存中的数据要比读数据存储位置的速度要快。（例如：寄存器-内存，内存-磁盘） 降低后端负载 如果不加缓存的话，并发的压力会直接加到后端数据库上，并发较大的时候，数据库可能会hold不住，而这里可以通过增加一层缓存，通过直接访问缓存不仅访问速度更快，而且减少了io次数，减少了数据库的压力。 2. 成本： 数据不一致： 缓存层是数据层的时间窗口不一致，和更新策略有关。 代码维护成本： 多了一层缓存逻辑 运维成本： 例如Redis Cluster… 2. 缓存更新策略 1. LRU/LFU/FIFO（一致性差，维护成本低） 2. 超时剔除: 例如expire（一致性差，维护成本低） 对于一些可以容忍数据不一致性的情况，可以使用这种策略。 3. 主动更新：开发控制生命周期（一致性较强，维护成本较高） 可以利用发布-订阅这种思想，在缓存来监听数据是否发生变化，若发生变化则失效. （例如volatile关键字的实现，缓存一致性协议中的嗅探机制，就是使用的这一策略， 也可利用消息队列来维护最终一致性） 低一致性： 最大内存和淘汰策略 高一致性：超时剔除和主动更新结合，最大内存和淘汰策略兜底（防OOM）。 3. 缓存的粒度控制 缓存的粒度，以缓存mysql中的数据为例，例如查询用户信息操作频繁，那么应该缓存用户信息的所有属性（select *）

一、介绍 1、熔断的目的：是为了保证服务高可用，不能因为系统中的一个小服务不可用，从而导致整个系统崩溃。 2、熔断的原理：对于使用相关注解的类或者方法，系统会监控其错误，如果多次出现同一个错误，且达到阈值，则打卡熔断开关，熔断开关打开后，不再访问远程服务，而是直接调用预先准备的失败方法。当熔断开关过期后，会尝试再次访问远程服务，这个时候的熔断开关是半开半闭状态的。有些服务会直接失败，有些会继续访问远程服务。 （至于熔断开关的过期时间多久，这个不确定。以及过期后重试远程服务比例，这些设置暂不清楚） 二、雪崩效应 在微服务架构中通常会有多个服务层调用，基础服务的故障可能会导致级联故障，进而造成整个系统不可用的情况，这种现象被称为服务雪崩效应。服务雪崩效应是一种因“服务提供者”的不可用导致“服务消费者”的不可用,并将不可用逐渐放大的过程。 如果下图所示：A作为服务提供者，B为A的服务消费者，C和D是B的服务消费者。A不可用引起了B的不可用，并将不可用像滚雪球一样放大到C和D时，雪崩效应就形成了。 三、熔断器（CircuitBreaker） 熔断器的原理很简单，如同电力过载保护器。它可以实现快速失败，如果它在一段时间内侦测到许多类似的错误，会强迫其以后的多个调用快速失败，不再访问远程服务器，从而防止应用程序不断地尝试执行可能会失败的操作，使得应用程序继续执行而不用等待修正错误

本系列示例与胶水代码地址： https://github.com/HashZhang/spring-cloud-scaffold 入口类注解修改 之前的项目，我们也许会用 @SpringCloudApplication 作为我们入口类的注解。这个注解包括： @SpringBootApplication @EnableDiscoveryClient @EnableCircuitBreaker public @interface SpringCloudApplication { } 其中的 @EnableDiscoveryClient 会启动服务发现的客户端，我们这里继续用Eureka，但是EurekaClient不需要这个注解，只要加上 spring-cloud-starter-eureka-client 的依赖，就会启动EurekaClient。对于 @EnableCircuitBreaker 这个注解，就比较麻烦了。我们引入了 spring-cloud-starter-netflix-eureka-client 依赖，这个依赖，包含了 hystrix 依赖，导致会自动启用 hystrix 实现 CircuitBreaker 接口，而我们并不想启用hystrix。并且，使用 SpringCloud 的 CircuitBreaker 的抽象接口，并不能完全使用

云栖号资讯：【 点击查看更多行业资讯 】 在这里您可以找到不同行业的第一手的上云资讯，还在等什么，快来！ 阿里妹导读：软件工程领域存在一个共识：维护代码所花费的时间要远多于写代码。而整个代码维护过程中，最惊心动魄与扣人心弦的部分，莫过于问题排查（Trouble-shooting）了。特别是那些需要 7x24 小时不间断维护在线业务的一线服务端程序员们，大大小小的问题排查线上救火早已成为家常便饭，一不小心可能就吃成了自助餐 —— 竖着进躺着出，吃不了也兜不住。本文分享作者在服务端问题排查方面的一些经验，包括常见问题、排查流程、排查工具，结合实际项目中发生过的惨痛案例进行现身说法。 一 问题排查 1 常见问题 Know Your Enemy：知己知彼，百战不殆。 日常遇到的大部分问题，大致可以归到如下几类： 逻辑缺陷：e.g. NPE、死循环、边界情况未覆盖。 性能瓶颈：e.g. 接口 RT 陡增、吞吐率上不去。 内存异常：e.g. GC 卡顿、频繁 FGC、内存泄露、OOM 并发/分布式：e.g. 存在竞争条件、时钟不同步。 数据问题：e.g. 出现脏数据、序列化失败。 安全问题：e.g. DDoS 攻击、数据泄露。 环境故障：e.g. 宿主机宕机、网络不通、丢包。 操作失误：e.g. 配置推错、删库跑路（危险动作，请勿尝试..）。 上述分类可能不太完备和严谨，想传达的点是

注册中心--Eureka 相信通过 微服务应用开发入门①web端架构演进 童鞋已经大概知道注册中心的概念和它是做什么的； Eureka是Netflix开源的一款提供服务注册和发现的产品，它提供了完整的Service Registry和Service Discovery实现。 那我们还必须搞明白一些概念（当然其他概念还有很多很多） Register: 服务注册 服务的提供者，将自身注册到注册中心，服务提供者也是一个 Eureka Client。当 Eureka Client 向 Eureka Server 注册时，它提供自身的元数据，比如 IP 地址、端口，运行状况指示符 URL，主页等。 Renew: 服务续约 Eureka Client 会每隔 30 秒发送一次心跳来续约。 通过续约来告知 Eureka Server 该 Eureka Client 运行正常，没有出现问题。 默认情况下，如果 Eureka Server 在 90 秒内没有收到 Eureka Client 的续约，Server 端会将实例从其注册表中删除，此时间可配置，一般情况不建议更改 负载均衡 负载均衡是我们处理高并发、缓解网络压力和进服务端扩容的重要手段之一。 一般情况下我们所说的负载均衡通常都是指服务端负载均衡。 服务端负载均衡又分为两种，一种是硬件负载均衡，还有一种是软件负载均衡。 客户端负载均衡

序 本文主要研究一下dubbo-go的HystrixFilter HystrixFilter dubbo-go-v1.4.2/filter/filter_impl/hystrix_filter.go // HystrixFilter ... type HystrixFilter struct { COrP bool //true for consumer res map[string][]*regexp.Regexp ifNewMap sync.Map } HystrixFilter定义了COrP、res、ifNewMap属性 Invoke dubbo-go-v1.4.2/filter/filter_impl/hystrix_filter.go // Invoke ... func (hf *HystrixFilter) Invoke(ctx context.Context, invoker protocol.Invoker, invocation protocol.Invocation) protocol.Result { cmdName := fmt.Sprintf("%s&method=%s", invoker.GetUrl().Key(), invocation.MethodName()) // Do the configuration if the circuit

Hystrix的使用5-监控页面dashboard 1.简介 Hystrix仪表板可以实时监视Hystrix指标。可以查看Hystrix服务是否处于熔断状态等等。 2.代码实现 2.1 被监控工程代码增加代码 这里我们监控cloud-provider-payment-hystrix8001服务提供者类，需要在服务提供者启动类PaymentHystrixStart8001中加入以下方法，将监控地址修改 http://127.0.0.1:8001/hystrix.stream 。 /** * 给Hystrix Dashboard指定当前工程的监控路径为：http://127.0.0.1:8001/hystrix.stream * @return */ @Bean public ServletRegistrationBean getServlet(){ HystrixMetricsStreamServlet streamServlet = new HystrixMetricsStreamServlet(); ServletRegistrationBean registrationBean = new ServletRegistrationBean(streamServlet); registrationBean.setLoadOnStartup(1); registrationBean

背景 在我们的项目中，比较广泛地使用了ThreadLocal，比如，在filter层，根据token，取到用户信息后，就会放到一个ThreadLocal变量中；在后续的业务处理中，就会直接从当前线程，来获取该ThreadLocal变量，然后获取到其中的用户信息，非常的方便。 但是，hystrix 这个组件一旦引入的话，如果使用线程隔离的方式，我们的业务逻辑就被分成了两部分，如下： public class SimpleHystrixCommand extends HystrixCommand<String> { private TestService testService; public SimpleHystrixCommand(TestService testService) { super(setter()); this.testService = testService; } @Override protected String run() throws Exception { .... } ... } 首先，我们定义了一个Command，这个Command，最终就会丢给hystrix的线程池中去运行。那，我们的controller层，会怎么写呢？ @RequestMapping("/") public String hystrixOrder () {

pom配置 <dependencies> <!--gateway--> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-gateway</artifactId> </dependency> <!--Spring Cloud Alibaba--> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-hystrix</artifactId> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> <dependency>