• 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 等资源，消耗完你这个系统服务器不就崩了么。】
    
    • 整个微服务调用链路上某一个服务不可用了，大家都在等这个服务的响应，对这个不可用服务的调用会占用越来越多的系统资源，出现级联故障，进入有可能导致整个系统崩溃，所以咱们得弃车保帅。
    • 弃车保帅常见实现方法：
      • Hystrix会在某个服务不可用时返回一个备用响应而不是造成长时间的大家排队等待
        • 搞一个计数器，如果连续失败次数到达指定数量了，就抛出异常
      • 做个备份嘛，不用组件的话，咱们也可以实现，比如异常可实现、异步加载也可实现
      • 后面来请求了，可以搞个时间窗口，过一段时间让这个请求过来再试试
      • 只要这个服务崩了你必须给我返回一个提示的友好信息或者另一个啥东西
  • Hystrix 就是一个能进行 熔断 和 降级 的库，通过使用它能提高整个系统的弹性。【在分布式环境中，不可避免地会有许多服务依赖项中的某些失败。Hystrix 是一个库，可通过添加等待时间容限和容错逻辑来帮助咱们控制这些分布式服务之间的交互。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