转载

微服务-高并发情况下接口降级和熔断策略

介绍一下降级和熔断的概念

什么是降级呢?降级意味着多种方案,当系统出现问题的时候,你有一个备选方案可以马上切换,比如有一个接口的功能是实时预测未来一个月某个商品的采购数量,突然间依赖的上游系统出现问题了,那么我们的接口就完全不可用了吗?显然这是不应该的,这时我接口就可以降级,返回昨天实时计算出来的结果,虽然准确性可能差一点,但系统能够正常运转,降级也分为自动降级和手动降级,前者是系统自动检测到问题时自动切换,后者是系统检测到问题报警,人为的切换,降级代表着系统相比降级之前其功能表现不如之前的完美(这个具体体现在功能准确性,可用性上等,如上面接口的例子)

什么是熔断呢?通俗来讲,熔断指的是遇到危险了,必须马上停掉,比如生活中的电流过大,必须马上切断,否则就发生了火灾了,熔断之后就会导致断电,完全不可用,在一个系统中,假设一个接口部署了10台机器(分布式),突然某一台机器的接口调用情况正确率降到90%,那么这台机器肯定出现问题了,这个时候就需要熔断这台机器,把这台机器从整个集群中摘掉,从而保证用户的请求100%的正确,再比如,一个系统中有很多功能,这些功能有些是核心功能,有些是非核心功能,那么在一些大促中,我们可能熔断掉一些非核心功能,从而保证核心功能的流转(登录和注册,登录属于核心,注册是属于非核心)

为什么需要降级和熔断

不管是降级还是熔断,都是为了保证了系统的稳定性,可用性。降级往往代表系统功能部分不可用,熔断代表的是完全不可用,再举一个简单例子,注册功能,降级可能出现的情况是手机号可以正常,邮箱不能注册,而熔断出现的情况是注册功能完全不可用,所以说有时候熔断是一种特殊的降级。这在整个系统设计编码中都需要考虑到。

常用的降级和熔断策略

在业务系统时,降级在编码时需要考虑好备选方案,和业务确认方案的合理性,熔断在编码时需要分离核心功能和非核心功能,梳理上下游依赖关系,防止强依赖引起的系统的雪崩,这些是业务系统功能设计时需要经常考虑的。

所有业务系统都需要考虑的东西,就意味着可以优化,可以剥离,抽象出来,做成公共组件,中间件,形成通用性。

上面有提到,降级和熔断的最终目的都是保证系统的稳定性,可靠性,保证核心服务可用,那么在形成中间件时具体措施是什么呢?

降级

  1. 超时降级(调用服务时超时返回默认值或者其它处理办法)
  2. 失败次数降级(服务可用率下降时降级)
  3. 限流也是降级的一种办法
  4. 故障降级(依赖的外系统发生故障时降级)
  5. 拒绝服务降级

熔断

  1. 系统攻击熔断(当某个服务遭遇流量攻击时,可以熔断这个服务)
  2. 涉及核心功能运行时的熔断(下单和评论功能,关键时刻可以熔断评论功能)

不管降级还是熔断,在设计时都要考虑:降级熔断算法,恢复机制,报警。这些是必备的,不能系统降级了或者熔断了就无法回复之前的情况,也不能不报警,要不然开发人员都不知道,这还得了。

熔断和降级的异样性

  1. 两者的目的相当
  2. 两者的最终的表现的相同
  3. 粒度一样,大多数都是服务级别的粒度,也有可能是方法级别的
  4. 自治性要求比较高(尽可能的智能化)
  5. 降级一般是客户端处理,熔断是在服务端处理的

设计方案

介绍一种的常见的方案,服务码+配置中心,调用任何服务时都传入必要参数服务码和开关,默认关闭,当触发某种条件时可打开开关,或者通过配置中心手动推送开关新的值,从而保护系统不被单个服务压垮,别看这个简单,很多系统都是这么做的。

func  DowngradeAndFuse (ctx context.Context){
    //业务码
    bizValue := ctx.Value("bizCode")
    //熔断降级标识
    flag := ctx.Value("flag")
   
    if bizValue == "指定业务" && flag {
       //降级或者熔断
       return
    }
}

Hystrix的原理

Hystrix有Java和Go版本的,Java版本的是Netflix公司开发并开源的,Go版本的是由afex(个人)创建的,代码库地址如下:

https://github.com/Netflix/Hystrix
https://github.com/afex/hystrix-go

Hystrix引入以下手段来保护系统:

  1. 资源隔离(线程池和信号量两种手段的隔离)
  2. 限流
  3. 降级
  4. 熔断(断路器)

Hystrix如何设计实现这些手段呢?

  1. 使用命令模式将所有对外部服务(或依赖关系)的调用包装在HystrixCommand或HystrixObservableCommand对象中,并将该对象放在单独的线程中执行
  2. 每一个依赖都有自己对应的线程池或者信号量,线程池耗尽时,拒绝请求
  3. 维护请求的各种状态(成功,失败,超时的次数)
  4. 当错误率到达一定阈值时,进行熔断,过一定的时间后又恢复
  5. 提供降级,失败,成功,熔断后的回调逻辑
  6. 实时的监控指标和配置信息的修改

用代码实现一个hystrix-go的Demo,第一步写在init初始化中,配置hystrix的一些参数,如果不配置的话,也会有默认参数。

func init() {
   hystrix.ConfigureCommand("my_command", hystrix.CommandConfig{
      //多长时间 超时
      Timeout: 5000,
      //最大并发数
      MaxConcurrentRequests: 1,
      //错误百分比,错误率达到这个数值开启熔断
      ErrorPercentThreshold: 25,
      //当熔断器被打开后,SleepWindow的时间就是控制过多久后去尝试服务是否可用了(毫秒)
      SleepWindow: 10,
      //最小请求数,只有到达这个数量后才判断是否开启熔断
      RequestVolumeThreshold: 10,
   })
}

如何使用hystrix熔断呢,总的来说分为4个步骤:

第一步:定义你调用的外部系统的服务

第二步:设置回调函数(当超时或者熔断了会调用回调函数)

第三步:使用hystrix的api调用第一步定义好的服务

第四步:获取最终结果(结果可能时正确的,也可能是一个err)

//异步调用
func HystrixAsyStudy() {
   //第一步:
   result := make(chan string, 1)
   //定义依赖外部系统的函数
   f1 := func() error {
      // 处理业务系统(调用外部服务)
      fmt.Println("处理业务逻辑")
      result <- "处理结果"
      return nil
   }
   //第二步:
   //回调函数,只有 err不为空,才会执行回调函数(如果发生了超时,熔断,
   //限流,超时之后也会回调)
   fallBack1 := func(err error) error {
      fmt.Println("回调函数")
      return err
   }
   //第三步:
   errors := hystrix.Go("my_command", f1, fallBack1)
   //第四步:
   select {
   case r := <-result:
      fmt.Println(r)
   case e := <-errors:
      fmt.Println(e)
   }
}

Hystrix更加详细的文档参考如下地址:

//Java版本的
https://github.com/Netflix/Hystrix/wiki/How-To-Use#Common-Patterns-FailFast
//Go版本的
https://github.com/afex/hystrix-go
原文  http://www.cnblogs.com/sy270321/p/12675480.html
正文到此结束
Loading...