分布式系统的熔断降级

分布式应用理论及应用

CAP理论

• CAP定理: 指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可同时获得。
  • 一致性（C）：所有节点都可以访问到最新的数据
  • 可用性（A）：每个请求都是可以得到响应的，不管请求是成功还是失败
  • 分区容错性（P）：除了全部整体网络故障，其他故障都不能导致整个系统不可用
• CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡。
  
• CA： 如果不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。但放弃P的同时也就意味着放弃了系统的扩展性，也就是分布式节点受限，没办法部署子节点，这是违背分布式系统设计的初衷的。
  ​
• CP: 如果不要求A（可用），每个请求都需要在服务器之间保持强一致，而P（分区）会导致同步时间无限延长(也就是等待数据同步完才能正常访问服务)，一旦发生网络故障或者消息丢失等情况，就要牺牲用户的体验，等待所有数据全部一致了之后再让用户访问系统。
  ​
• AP：要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。

注册中心的选择

	nacos	Eureka	Consul	Zookeeper
一致性协议	CP+AP	AP	CP	CP
健康检查	TCP/HTTP/MYSQL/Client Beat	心跳	TCP/HTTP/gRPC/Cmd	Keep Alive
雪崩保护	有	有	无	无
访问协议	HTTP/DNS	HTTP	HTTP/DNS	TCP
SpringCloud集成	支持	支持	支持	支持

• Zookeeper：CP设计，保证了一致性，集群搭建的时候，某个节点失效，则会进行选举行的leader，或者半数以上节点不可用，则无法提供服务，因此可用性没法满足
• Eureka：AP原则，无主从节点，一个节点挂了，自动切换其他节点可以使用，去中心化
• 结论
  • 分布式系统中P,肯定要满足，所以只能在CA中二选一
  • 没有最好的选择，最好的选择是根据业务场景来进行架构设计
  • 如果要求一致性，则选择zookeeper/Nacos，如金融行业 CP
  • 如果要求可用性，则Eureka/Nacos，如电商系统 AP
  • CP ： 适合支付、交易类，要求数据强一致性，宁可业务不可用，也不能出现脏数据
  • AP: 互联网业务，比如信息流架构，不要求数据强一致，更想要服务可用

分布式CAP的权衡结果 BASE理论

• 什么是Base理论

  • CAP 中的一致性和可用性进行一个权衡的结果，核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性, 来自 ebay 的架构师提出。

• Basically Available(基本可用)

  • 假设系统，出现了不可预知的故障，但还是能用, 可能会有性能或者功能上的影响

• Soft state（软状态）

  • 允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时

• Eventually consistent（最终一致性）

  • 系统能够保证在没有其他新的更新操作的情况下，数据最终一定能够达到一致的状态，因此所有客户端对系统的数据访问最终都能够获取到最新的值

高并发下的微服务架构存在的问题和解决方案

高并发下的微服务存在的问题

• 问题
  • 微服务拆分多个系统，服务之间互相依赖，可能会由于系统负载过高，突发流量或者网络等各种异常情况 导致服务不可用。
  • 核心思想-面向失败编程：不要外界影响，不被请求拖垮 （上、下游服务）

高并发下的微服务容错方案

• 限流
• 漏斗，不管流量多大，均匀的流入容器，令牌桶算法，漏桶算法
  
• 熔断
  • 保险丝，熔断服务，为了防止整个系统故障，包含当前和下游服务 下单服务 -》商品服务-》用户服务 -》（出现异常-》熔断风控服务
• 降级
  • 抛弃一些非核心的接口和数据，返回兜底数据 旅行箱的例子：只带核心的物品，抛弃非核心的，等有条件的时候再去携带这些物品
• 隔离
  • 服务和资源互相隔离，比如网络资源，机器资源，线程资源等，不会因为某个服务的资源不足而抢占其他服务的资源
• 熔断和降级互相交集
  • 相同点
    • 从可用性和可靠性触发，为了防止系统崩溃
    • 最终让用户体验到的是某些功能暂时不能用
  • 不同点
    • 服务熔断一般是下游服务故障导致的，而服务降级一般是从整体系统负荷考虑，由调用方控制
• 想进行微服务的容错，业界目前有Sentinel、Hystrix，相对于AlibabaCloud而言，Sentinel是最好的搭配

分布式系统的流量防卫兵-Sentinel

Sentinel概念

• 什么是Sentinel
  • 阿里巴巴开源的分布式系统流控工具
  • 以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性
  • 丰富的应用场景：消息削峰填谷、集群流量控制、实时熔断下游不可用应用等
  • 完备的实时监控：Sentinel 同时提供实时的监控功能
  • 提供开箱即用的与其它开源框架/库的整合模块，例如与 Spring Cloud、Dubbo、gRPC 的整合
  • 官网
• 核心概念
  • 资源：是 Sentinel 中的核心概念之一，可以是java程序中任何内容，可以是服务或者方法甚至代码，总结起来就是我们要保护的东西
  • 规则：定义怎样的方式保护资源，主要包括流控规则、熔断降级规则等
    

微服务引入Sentinel和控制台搭建

• Sentinel 分为两个部分

  • 核心库（Java 客户端）不依赖任何框架/库，能够运行于所有 Java 运行时环境，同时对 Dubbo、Spring Cloud 等框架也有较好的支持。
  • 控制台（Dashboard）基于 Spring Boot 开发，打包后可以直接运行，不需要额外的 Tomcat 等应用容器。

• 使用 docker搭建sentinel控制台

  docker run -d -p 8858:8858 \
  --name sentinel-dashboard \
  -e AUTH_USERNAME=sentinel \
  -e AUTH_PASSWORD=123456 \
  bladex/sentinel-dashboard:latest
  

  官网地址

• 微服务引入Sentinel依赖

  <dependency>
      <groupId>com.alibaba.cloud</groupId>
      <artifactId>spring-cloud-starter-alibaba-sentinel</artifactId>
  </dependency>
  

  • 微服务接入Sentinel配置

  spring:
    cloud:
      sentinel:
        transport:
          dashboard: 127.0.0.1:8080 
          port: 9999 
  #dashboard: 8080 控制台端口
  #port: 9999 本地启的端口，随机选个不能被占用的，与dashboard进行数据交互，会在应用对应的机器上启动一个 Http Server，该 Server 会与 Sentinel 控制台做交互, 若被占用,则开始+1一次扫描
  

  • 微服务注册上去后，由于Sentinel是懒加载模式，所以需要访问微服务后才会在控制台出现
    

Sentinel流空规则

• 流量控制（flow control）
  • 原理是监控应用流量的 QPS 或并发线程数等指标，当达到指定的阈值时对流量进行控制，以避免被瞬时的流量高峰冲垮，从而保障应用的高可用性。
• 两种规则
  • 基于统计并发线程数的流量控制
    • 并发数控制用于保护业务线程池不被慢调用耗尽
    • Sentinel 并发控制不负责创建和管理线程池，而是简单统计当前请求上下文的线程数目（正在执行的调用数目）
    • 如果超出阈值，新的请求会被立即拒绝，效果类似于信号量隔离
  • 当 QPS 超过某个阈值的时候，则采取措施进行流量控制

• 流控规则会下发到微服务，微服务如果重启，则流控规则会消失可以持久化配置

• 流量控制的效果包括以下几种
  • 直接拒绝：默认的流量控制方式，当QPS超过任意规则的阈值后，新的请求就会被立即拒绝
  • Warm Up：冷启动/预热，如果系统在此之前长期处于空闲的状态，我们希望处理请求的数量是缓步的增多，经过预期的时间以后，到达系统处理请求个数的最大值
    * 匀速排队：严格控制请求通过的间隔时间，也即是让请求以均匀的速度通过，对应的是漏桶算法，主要用于处理间隔性突发的流量，如消息队列，想象一下这样的场景，在某一秒有大量的请求到来，而接下来的几秒则处于空闲状态，我们希望系统能够在接下来的空闲期间逐渐处理这些请求，而不是在第一秒直接拒绝多余的请求
  • 流控文档

Sentinel 熔断策略

• 慢调用比例(响应时间): 选择以慢调用比例作为阈值，需要设置允许的慢调用 RT（即最大的响应时间），请求的响应时间大于该值则统计为慢调用
  
• 异常比例：当单位统计时长内请求数目大于设置的最小请求数目，并且异常的比例大于阈值，则接下来的熔断时长内请求会自动被熔断
  
• 异常数：当单位统计时长内的异常数目超过阈值之后会自动进行熔断
  

服务调用常见的熔断状态和恢复

• 服务熔断一般有三种状态
  • 熔断关闭（Closed）
    • 服务没有故障时，熔断器所处的状态，对调用方的调用不做任何限制
  • 熔断开启（Open）
    • 后续对该服务接口的调用不再经过网络，直接执行本地的fallback方法
  • 半熔断（Half-Open）
    • 所谓半熔断就是尝试恢复服务调用，允许有限的流量调用该服务，并监控调用成功率
      
• 熔断恢复
  • 经过熔断时长后熔断器会进入探测恢复状态（HALF-OPEN 状态）尝试恢复服务调用，允许有限的流量调用该服务，并监控调用成功率
  • 如果成功率达到预期，则说明服务已恢复，进入熔断关闭状态；如果成功率仍旧很低，则重新进入熔断状态

Sentinel自定义异常-整合Open-Feign

• 开启Feign对Sentinel的支持

  feign:
    sentinel:
      enabled: true
  

• 配置feign容错类

  @FeignClient(value = "xdclass-video-service", fallback = VideoServiceFallback.class)