java基础巩固-宇宙第一AiYWM：为了维持生计，架构知识+分布式微服务+高并发高可用高性能知识序幕就此拉开（六：Hystrix之熔断、降级、限流）~整起

• Hystrix，用来解决服务雪崩现象的一个组件【服务雪崩效应是一种因服务提供者的不可用导致服务调用者的不可用，并将不可用逐渐放大的过程】
  
  • 中文文档：https://www.apiref.com/spring-cloud-zh/dalston/#_circuit_breaker_hystrix_clients
  • 服务雪崩：
    • 咱们搞分布式集群时，不可避免地会有许多服务依赖项中的某些失败，在系统中经常会出现 某个基础服务不可用造成整个系统不可用 的情况,，这种现象被称为服务雪崩效应.。
      • 服务雪崩效应是一种因 服务提供者 的不可用导致 服务调用者 的不可用,并将不可用 逐渐放大 的过程。比如服务 A 调用了服务 B，服务 B 再调用了服务 C，但是因为某些原因，服务 C 顶不住了，这个时候大量请求会在服务 C 阻塞。---->服务 C 阻塞了还好，毕竟只是一个系统崩溃了。但是这个时候因为服务 C 不能返回响应，那么服务 B 调用服务 C 的的请求就会阻塞，同理服务 B 阻塞了，那么服务 A 也会阻塞崩溃。【为什么阻塞会崩溃：因为请求会消耗占用系统的线程、IO 等资源，消耗完你这个系统服务器不就崩了么。】
        
      • 服务雪崩的成因：
        • 服务提供者拉垮了，不可用了，不能提供服务了
          • 服务器等硬件出故障、写的程序有bug、缓存击穿【这个数据的过期时间刚到，结果对这个数据的查询就来了，那你不扑空谁扑空；缓存击穿一般发生在缓存应用重启，所有缓存被清空时，以及短时间内大量缓存失效时，大量的缓存不命中，使请求直击后端,造成服务提供者超负荷运行，引起服务不可用】、用户请求量太大【用户发起大量请求也会造成服务提供者的不可用】
        • 分布式集群中设置的重试机制，重试的时候流量加大了，第一次一个人来吃你做的菜，贼好吃，然后第二次来的时候带了成千上万个人来吃，你就扛不住了
          • 用户重试【在服务提供者不可用后，用户由于忍受不了界面上长时间的等待，卡的要死，等不及了，多刷新几遍不是咱们经常干的嘛。而不断刷新页面甚至提交表单，服务调用端的会存在大量服务异常后的重试逻辑。这些重试都会进一步加大请求流量】
          • 代码逻辑重试
        • 我服务调用者拉垮了，偶感风寒，连外卖都点不了了，还咋调用服务
          • 当服务调用者使用 同步调用 时, 会产生大量的等待线程占用系统资源。一旦线程资源被耗尽,服务调用者提供的服务也将处于不可用状态, 于是服务雪崩效应产生了.
    • 整个微服务调用链路上某一个服务不可用了，大家都在等这个服务的响应，对这个不可用服务的调用会占用越来越多的系统资源，出现级联故障，进入有可能导致整个系统崩溃，所以咱们得弃车保帅。
      • 应对服务雪崩经常有两种思路：
        • 一种常见的做法是手动服务降级。
        • Hystrix的出现,给我们提供了另一种选择。Hystrix 就是一个能进行 熔断 和 降级 的库，通过使用它能提高整个系统的弹性。
      • 应对服务雪崩或者说弃车保帅常见实现方法：
        • 流量控制：流量控制的具体措施如下
          • 网关限流
            • 【因为Nginx的高性能，目前一线互联网公司大量采用Nginx+Lua的网关进行流量控制，由此而来的OpenResty也越来越热门。】
          • 用户交互限流
            • 用户交互限流的具体措施有:
              • 采用加载动画，提高用户的忍耐等待时间.
              • 提交按钮添加强制等待时间机制
          • 关闭重试
        • 改进缓存模式，具体措施如下
          • 缓存预加载
          • 同步刷新改为异步刷新
        • 服务自动扩容：AWS的auto scaling
        • 服务调用者降级服务：
          • 资源隔离
            • 资源隔离主要是对调用服务的线程池进行隔离。Hystrix通过将每个依赖服务分配独立的线程池进行资源隔离, 从而避免服务雪崩。比如电商系统中，当商品评论服务不可用时, 即使商品服务独立分配的20个线程全部处于同步等待状态,也不会影响其他依赖服务的调用.
          • 对依赖服务进行分类
            • 根据具体业务,将依赖服务分为: 强依赖和弱依赖. 强依赖服务不可用会导致当前业务中止,而弱依赖服务的不可用不会导致当前业务的中止
          • 不可用服务的调用快速失败
            • 不可用服务的调用快速失败一般通过 超时机制, 熔断器 和熔断后的 降级方法 来实现
  • Hystrix 是一个库，可通过添加等待时间容限和容错逻辑来帮助咱们控制这些分布式服务之间的交互。Hystrix 通过隔离服务之间的访问点，停止服务之间的级联故障并提供后备选项来实现此目的，所有这些都可以提高系统的整体弹性。
    • Hystrix [hɪst'rɪks]的中文含义是豪猪, 因其背上长满了刺,而拥有自我保护能力. Netflix的 Hystrix 是一个帮助解决分布式系统交互时超时处理和容错的类库, 它同样拥有保护系统的能力
    • Hystrix:提供了熔断和降级。主要就是发起向服务方的请求，如果请求过去后建立连接时超时了，把这次请求记录到服务里，然后尝试向其他服务器发起请求，如果连接还是建立失败，catch异常，return 服务器网络异常等友好提示。
      • Hystrix还可以进行监控，老规矩，先在pom.xml中导入依赖【被监控的服务中的pom.xml中也需要有actuator的依赖】、application.yml中配置server.port:xxxx；写主程序类，主程序类中加一个@EnableHystrixDashboard
        • 看Hystrix监控页面左边的圈大小，圈越大越红，说明请求流量越大，说明很不健康；还有错误比
    • 服务熔断： 熔断 就是服务雪崩的一种有效解决方案，当指定时间窗内的请求失败率达到设定阈值时，系统将通过 断路器 直接将此请求链路断开【也就是我们上面服务 B 调用服务 C 在指定时间窗内，调用的失败率到达了一定的值，那么 Hystrix 则会自动将 服务 B 与 C 之间的请求都断了，以免导致服务雪崩现象。】。
      
      • 这里所讲的 熔断 就是指的 Hystrix 中的 断路器模式，@HystrixCommand 注解来标注某个方法，这样 Hystrix 就会使用 断路器 来“包装”这个方法，每当调用时间超过指定时间时(默认为 1000ms)，断路器将会中断对这个方法的调用。当然也可以对这个注解的很多属性进行设置，比如设置超时时间
        

        • 使用Hystrix方式不仅仅是Hystrix这个组件，其他的Spring Cloud组件也一样：pom.xml中导入依赖+写配置信息+写注解【写主程序类、写配置类、写controller类等】，其中的注解使用如下：
          
          
          

          • 在需要熔断的类中的方法上用这个注解@HystrixCommand（fallbackMethod=出现异常了要调用的备选方法名），开启熔断逻辑
          • 调一个熔断方法用fallbackMethod，降多个用fallbackMethodFactory
          • 在主程序类上用的是@EnableCircuitBreaker

          @HystrixCommand(
           commandProperties = {@HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds",value = "1200")}
          )
          

      • 超时和重试机制设置之外，熔断机制也是很重要的。 熔断机制说的是系统自动收集所依赖服务的资源使用情况和性能指标，当所依赖的服务恶化或者调用失败次数达到某个阈值的时候就迅速失败，让当前系统立即切换依赖其他备用服务。 比较常用的流量控制和熔断降级框架是 Netflix 的 Hystrix 和 alibaba 的 Sentinel
    • 服务降级
      • 整体资源不够用了，我忍痛关闭一些资源，等高并发阶段过了再启动运行。当服务熔断或关闭之后服务不再被调用
      • 服务降级：降级是为了更好的用户体验，当一个方法调用异常时，通过执行另一种代码逻辑来给用户友好的回复。这也就对应着 Hystrix 的 后备处理 模式。你可以通过设置 fallbackMethod 来给一个方法设置备用的代码逻辑。比如这个时候有一个热点新闻出现了，我们会推荐给用户查看详情，然后用户会通过 id 去查询新闻的详情，大量用户同时访问可能会导致系统崩溃，那么我们就进行 服务降级 ，一些请求会做一些降级处理比如当前人数太多请稍后查看等等。
        • 实现方式就是：我们在客户端可以准备一个FallbackFactory返回一个默认的值【整体服务水平降低，但是至少还可用】。此时在没调通，就要降级了【可以把下面的try…catch跟AOP融合，可以跟RestTemplate】；
      • pom.xml中导入依赖+写配置信息+写注解【写主程序类、写配置类、写controller类等】，其中的注解使用如下：

        // 指定了后备方法调用
        @HystrixCommand(fallbackMethod = "getHystrixNews")
        @GetMapping("/get/news")
        public News getNews(@PathVariable("id") int id) {
        		  // 调用新闻系统的获取新闻api 代码逻辑省略
        }
        //
        public News getHystrixNews(@PathVariable("id") int id) {
        		  // 做服务降级
        		  // 返回当前人数太多，请稍后查看
        }
        

    • 服务限流
      
      • 流量控制（flow control）其原理是监控应用流量的 QPS 或并发线程数等指标，当达到指定的阈值时对流量进行控制，以避免被瞬时的流量高峰冲垮，从而保障应用的高可用性。
        • 用户每通过一个URL发HTTP请求时每次都得开一个业务线程以及HTTP线程，每个线程自己跑自己的。为避免请求太多导致线程堆积。
          • 相同的URI开一组发起HTTP请求的线程，可以用map<>(URI,线程数)或者线程池。如果线程满了抛出异常-----业务线程隔离
          • 用户请求来了后，客户端的Hystrix维护一个线程池，给每一个请求都会维护一个线程池，基于线程池隔离
      • 限流可能会导致用户的请求无法被正确处理，不过，这往往也是权衡了软件系统的稳定性之后得到的最优解。
        • 针对软件系统来说，限流就是对请求的速率进行限制，避免瞬时的大量请求击垮软件系统。毕竟，软件系统的处理能力是有限的。如果说超过了其处理能力的范围，软件系统可能直接就挂掉了。
      • 常见限流算法：
        • 固定窗口【时间窗口】计数器算法：固定窗口计数器算法 规定了我们单位时间处理的请求数量。这种限流算法无法保证限流速率，因而无法保证突然激增的流量【就比如说我们限制某个接口 1 分钟只能访问 1000 次，该接口的 QPS 为 500，前 55s 这个接口 1 个请求没有接收，后 1s 突然接收了 1000 个请求。然后，在当前场景下，这 1000 个请求在 1s 内是没办法被处理的，系统直接就被瞬时的大量请求给击垮了。】。
          • 假如我们规定系统中某个接口 1 分钟只能访问 33 次的话，使用固定窗口计数器算法的实现思路如下：
            
        • 滑动窗口计数器算法：固定窗口计数器算法的升级版。
          • 滑动窗口计数器算法相比于固定窗口计数器算法的优化在于：滑动窗口计数器算法把时间以一定比例分片【例如我们的接口限流每分钟处理 60 个请求，我们可以把 1 分钟分为 60 个窗口。每隔 1 秒移动一次，每个窗口一秒只能处理 不大于 60(请求数)/60（窗口数） 的请求， 如果当前窗口的请求计数总和超过了限制的数量的话就不再处理其他请求。】 。很显然， 当滑动窗口的格子划分的越多，滑动窗口的滚动就越平滑，限流的统计就会越精确。
        • 漏桶算法：感觉跟做浆水鱼鱼差不多，一大团面下去变成小鱼鱼出来，相当于限流了呗
          • 可以把发请求的动作比作成注水到桶中，我们处理请求的过程可以比喻为漏桶漏水。我们往桶中以任意速率流入水，以一定速率流出水。当水超过桶流量则丢弃，因为桶容量是不变的，保证了整体的速率。
          • 实现这个算法的话需要准备一个队列用来保存请求，然后我们定期从队列中拿请求来执行就好了（和消息队列削峰/限流的思想是一样的）
            
        • 令牌桶算法：
          
          • 令牌桶算法和漏桶算法算法一样，我们的主角还是桶（这限流算法和桶过不去啊）。不过现在桶里装的是令牌了，请求在被处理之前需要拿到一个令牌，请求处理完毕之后将这个令牌丢弃（删除）。我们根据限流大小，按照一定的速率往桶里添加令牌。如果桶装满了，就不能继续往里面继续添加令牌了。
      • 限流分单机限流和分布式集群限流
        • 单机限流：javaGuide老师关于单机限流的文章
          • 单机限流可以直接使用 Google Guava 自带的限流工具类 RateLimiter 。 RateLimiter 基于令牌桶算法，可以应对突发流量。除了最基本的令牌桶算法(平滑突发限流)实现之外，Guava 的RateLimiter还提供了 平滑预热限流 的算法实现。
            
        • 分布式集群限流：
          • 分布式限流常见的方案：网上也有很多现成的脚本供参考，就**比如 Apache 网关项目 ShenYu 的 RateLimiter 限流插件就基于 Redis + Lua 实现了令牌桶算法/并发令牌桶算法、漏桶算法、滑动窗口算法。**
            
          • 如果要基于 Redis 来手动实现限流逻辑的话，建议配合 Lua 脚本来做。

巨人的肩膀:
凤凰架构~大佬的书，跟深入理解JVM一样值得多次翻阅
Spring Cloud dalstoon版中文文档：https://www.apiref.com/spring-cloud-zh/dalston/#_router_and_filter_zuul
B站的各位大佬
JavaGuide
Zookeeper官方文档
Dubbo官方文档
https://mp.weixin.qq.com/s?__biz=MzAxODcyNjEzNQ==&mid=2247568029&idx=2&sn=9aae8d03e4e9c941db78a3673394e613&chksm=9bd26705aca5ee13a0b0a9ada7432741a7e5c11676e50661da34b7e7632f54882c66c4ce4d20&scene=178&cur_album_id=1776403731354337285#rd