hystrix

Spring Cloud整体核心架构只有一点：Rest服务，也就是说在整个Spring Cloud配置过程之中，所有的配置处理都是围绕着Rest完成的，在这个Rest处理之中，一定要有两个端：服务的提供者（Provider）、服务的消费者（Consumer），所以对于整个Spring Cloud基础的结构就如下所示。 SpringCloud基础架构 既然Spring Cloud的核心是Restful结构，那么如果要想更好的去使用Rest这些微服务还需要考虑如下几个问题。 1、所有的微服务地址一定会非常的多，所以为了统一管理这些地址信息，也为了可以及时的告诉用户哪些服务不可用，所以应该准备一个分布式的注册中心，并且该注册中心应该支持有HA机制，为了高速并且方便进行所有服务的注册操作，在Spring Cloud里面提供有一个Eureka的注册中心。 微服务结构图 2、对于整个的WEB端的构架（SpringBoot实现）可以轻松方便的进行WEB程序的编写，而后利用Nginx或Apache实现负载均衡处理，但是你WEB端出现了负载均衡，那么业务端呢？应该也提供有多个业务端进行负载均衡。那么这个时候就需要将所有需要参与到负载均衡的业务端在Eureka之中进行注册。 多业务端-负载均衡 在进行客户端使用Rest架构调用的时候，往往都需要一个调用地址，即使现在使用了Eureka作为注册中心

1：概述 Hystrix使用Archaius作为配置属性的默认实现。官方配置文档： https://github.com/Netflix/Hystrix/wiki/Configuration 每个属性有四个优先级，依次增大： 1：代码的全局默认值 2：动态全局默认属性 可以使用全局属性文件来更改全局默认值。 3：代码实例默认 定义特定于实例的默认值，比如在HystrixCommand构造函数中设置的值 4：动态实例属性 可以动态设置实例特定的值，从而覆盖前面三个默认级别，格式是： hystrix.command.命令key.属性名称=值 2：请求上下文 1：requestCache.enabled 设置是否开启请求的缓存功能，默认true 2：requestLog.enabled 设置是否开启请求的日志功能，默认true 3：命令执行 execution.isolation.strategy 指示HystrixCommand.run()执行哪个隔离策略，选项： 1：THREAD - 它在单独的线程上执行，并发请求受线程池中线程数的限制 2：SEMAPHORE - 它在调用线程上执行，并发请求受信号计数的限制 3：官方推荐使用线程隔离策略，默认也是按照线程隔离进行处理。 4：信号量隔离的方式是限制了总的并发数，每一次请求过来，请求线程和调用依赖服务的线程是同一个线程

提起 Spring Cloud 的限流降级组件，一般首先想到的是 Netflix 的 Hystrix。 不过就在2018年底，Netflix 宣布不再积极开发 Hystrix，该项目将处于维护模式。官方表示 1.5.18 版本的 Hystrix 已经足够稳定，可以满足 Netflix 现有应用的需求，所以接下来其会把焦点转向对于自适应的实现，更多关注对应用程序的实时性能做出响应。对于新应用的熔断需求，将采用其它项目实现，Netflix 推荐了 Resilience4j。 作为 Spring Cloud Netflix 重要套件，Hystrix已经成为保障微服务稳定性的首选应用。其实除了 Netflix 和 Resilience4j，限流降级还有一个新的选择，就是阿里巴巴的Sentinel组件。 一、阿里开源 Sentinel 简介 2018年8月，阿里巴巴宣布将 Sentinel 进行开源，同时推出了结合Dubbo的适配器，捐赠给了Apache Dubbo社区。 1.Sentinel 的历史 2012 年，Sentinel 诞生，主要功能为入口流量控制。 2013-2017 年，Sentinel 在阿里巴巴集团内部迅速发展，成为基础技术模块，覆盖了所有的核心场景。Sentinel 也因此积累了大量的流量归整场景以及生产实践。 2018 年，Sentinel 开源，并持续演进。 2

1：架构图 2：ZuulServlet Zuul的核心是一系列的filters，Zuul大部分功能都是通过过滤器来实现的 1：ZuulServlet是Zuul的核心类，用来调度不同阶段的filters，处理请求，并处理异常等，路径是/zuul，可以使用zuul.servlet-path属性更改此路径 2：功能类似于SpringMvc的DispatcherServlet，所有的Request都要经过它的处理 3：里面有三个核心方法：preRoute(),route(), postRoute() 4：ZuulServlet会把具体的执行交给ZuulRunner去做，ZuulServlet是单例，因此ZuulRunner也仅有一个实例 5：Zuul的过滤器之间没有直接的相互通信，它们之间通过一个RequestContext的静态类来进行数据传递的。RequestContext类中有ThreadLocal变量来记录每个Request所需要传递的数据，ZuulRunner会初始化RequestContext 6：ZuulRunner直接将执行逻辑交由FilterProcessor处理，FilterProcessor也是单例，其功能就是依据filterType执行filter的处理逻辑，大致过程如下： （1）根据Type获取所有输入该Type的filter （2

作者：伈情的博客 http://nickid.cn/2017/04/分布式事务/ 分布式事务场景如何设计系统架构及解决数据一致性问题，个人理解最终方案把握以下原则就可以了，那就是：大事务=小事务（原子事务）+异步（消息通知），解决分布式事务的最好办法其实就是不考虑分布式事务，将一个大的业务进行拆分，整个大的业务流程，转化成若干个小的业务流程，然后通过设计补偿流程从而考虑最终一致性。 什么是事务 事务（Transaction）及其ACID属性 事务是由一组SQL语句组成的逻辑处理单元，事务具有以下4个属性，通常简称为事务的ACID属性： 原子性（Atomicity）： 事务是一个原子操作单元，其对数据的修改，要么全都执行，要么全都不执行。 一致性（Consistent）： 在事务开始和完成时，数据都必须保持一致状态。这意味着所有相关的数据规则都必须应用于事务的修改，以保持数据的完整性；事务结束时，所有的内部数据结构（如B树索引或双向链表）也都必须是正确的。 隔离性（Isoation）： 数据库系统提供一定的隔离机制，保证事务在不受外部并发操作影响的“独立”环境执行。这意味着事务处理过程中的中间状态对外部是不可见的，反之亦然。 持久性（Durabe）： 事务完成之后，它对于数据的修改是永久性的，即使出现系统故障也能够保持。 典型场景：银行转账业务 例如：李雷账户中有500块钱

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

参考文章： springcloud----服务熔断、降级、限流--之--Hystrix-服务降级 服务降级、服务熔断、服务限流、服务隔离 分布式面临的问题： 负责的分布式体系结构中应用程序有数十个依赖 ，可能会形成 调用链 (一个阻塞,全体等待) ， 引起服务雪崩 Hystrix 是一个用于处理分布式系统的 延迟 和 容错 的开源库， 在分布式系统中，许多不可避免的调用会失败， 比如超时，一场等。Hystrix 能够保证在一个依赖出现问题的情况下， 不会导致整体服务的失败、避免级联故障、以提高分布式系统的弹性 。 “ 断路器 ” 本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控（类似保险熔断）， 向调用方返回一个符合预期的、可处理的备选响应(FallBack) 而不是时间的等待或抛出调用方法处理异常 ，这样就保证了服务调用方的线程 不会长时间，不必要地占用 ，从而避免了故障在分布式系统无线的蔓延，从而导致 雪崩效应 。 重要概念 服务降级(fallback) ： 服务器忙，请稍后再试，等友好的提示 哪些情况会出现服务降级 程序异常、超时、服务熔断触发服务降级、线程池/信号量打满也会导致服务降级 服务熔断(break): 类比保险丝达到最大服务访问，直接拒绝。然后调用服务降级的方法返回友好提示 服务的降级 -> 进而熔断 -> 恢复调用链路 服务限流

基于SpringCloud分布式架构 为什么要使用分布式架构 Spring Cloud 专注于提供良好的开箱即用经验的典型用例和可扩展性机制覆盖 分布式/版本化配置 服务注册和发现 路由 Service-to-Service 调用 负载均衡 断路器 分布式消息传递 这是分布式的优点，这样看起来可能比较抽象，举个例子来说，对于单体服务来说，如果我想更新订单中的某个功能，我是不是需要重启整个服务。 这个时候就会导致整个项目都处于不可用状态，或者在处理订单的时候由于程序代码写的有问题，导致死锁了，这个时候也会导致整个服务处于宕机专改，容错率很差。 但是分布式不同，如上图所示，订单服务、售后服务、用户服务都是独立的服务，如果需要更新订单服务或者订单服务发生死锁，受影响的只会是订单服务，售后服务与用户服务还是可以正常工作的，这就是分布式相对单体来说最大的优势之一。 分布式基础组件 Spring Cloud Config：配置管理工具包，让你可以把配置放到远程服务器，集中化管理集群配置，目前支持本地存储、Git 以及 Subversion。 Spring Cloud Bus：事件、消息总线，用于在集群（例如，配置变化事件）中传播状态变化，可与 Spring Cloud Config 联合实现热部署。 Eureka：云端服务发现，一个基于 REST 的服务，用于定位服务

本篇讲述Spring Cloud 微服务及其组件的专业技术。微服务系统作为分布式系统的一种形式，.必然会带有分布式系统的各种弊病，因此本篇也会介绍分布式系统的一些常见知识，以更好满足企业构建系统的需求。 本篇从企业的真实需求出发，理论结合实际，深入讲解SpringCloud微服务和分布式系统的知识。文中既包括SpringCloud微服务的各类常用组件的讲解，又包括分布式系统的常用知识的介绍。 SpringCloud组件方面主要讲解服务注册和服务发现(Eureka) 、服务调用(Ribbon 和OpenFeign)、断路器(Hystrix 和Resilience4j)、网关(Zuul和Gateway)、配置(Config)、全链路追踪(Sleuth) 、微服务的监控(Admin)等;分布式系统方面主要讲解分布式数据库、分布式缓存、会话和权限以及发号机制等。本篇的实践部分通过Apache Thrift 讲解了远程过程调用(RPC)在分布式系统中的应用，并且分析了处理高并发的一些常用方法，最后还通过一个简单的实例讲解了微服务系统的搭建。 本篇篇幅有些长总共4大部分，20个章节： 第一部分概述和基础 第二部分Spring Cloud微服务 第三部分分布式技术 第四部分微服务系统实践 第一部分概述和基础 第1章分布式和微服务概述 第2章技术基础 第二部分Spring Cloud微服务

作者：伈情的博客 http://nickid.cn/2017/04/分布式事务/ 分布式事务场景如何设计系统架构及解决数据一致性问题，个人理解最终方案把握以下原则就可以了，那就是：大事务=小事务（原子事务）+异步（消息通知），解决分布式事务的最好办法其实就是不考虑分布式事务，将一个大的业务进行拆分，整个大的业务流程，转化成若干个小的业务流程，然后通过设计补偿流程从而考虑最终一致性。 什么是事务 事务（Transaction）及其ACID属性 事务是由一组SQL语句组成的逻辑处理单元，事务具有以下4个属性，通常简称为事务的ACID属性： 原子性（Atomicity）： 事务是一个原子操作单元，其对数据的修改，要么全都执行，要么全都不执行。 一致性（Consistent）： 在事务开始和完成时，数据都必须保持一致状态。这意味着所有相关的数据规则都必须应用于事务的修改，以保持数据的完整性；事务结束时，所有的内部数据结构（如B树索引或双向链表）也都必须是正确的。 隔离性（Isoation）： 数据库系统提供一定的隔离机制，保证事务在不受外部并发操作影响的“独立”环境执行。这意味着事务处理过程中的中间状态对外部是不可见的，反之亦然。 持久性（Durabe）： 事务完成之后，它对于数据的修改是永久性的，即使出现系统故障也能够保持。 典型场景：银行转账业务 例如：李雷账户中有500块钱