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

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

什么是降级呢? 降级意味着多种方案，当系统出现问题的时候，你有一个备选方案能够立刻切换，好比有一个接口的功能是实时预测将来一个月某个商品的采购数量，忽然间依赖的上游系统出现问题了，那么咱们的接口就彻底不可用了吗？显然这是不该该的，这时我接口就能够降级，返回昨天实时计算出来的结果，虽然准确性可能差一点，但系统可以正常运转，降级也分为自动降级和手动降级，前者是系统自动检测到问题时自动切换，后者是系统检测到问题报警，人为的切换，降级表明着系统相比降级以前其功能表现不如以前的完美（这个具体体如今功能准确性，可用性上等,如上面接口的例子）
什么是熔断呢? 通俗来说，熔断指的是遇到危险了，必须立刻停掉，好比生活中的电流过大，必须立刻切断，不然就发生了火灾了，熔断以后就会致使断电，彻底不可用，在一个系统中，假设一个接口部署了10台机器（分布式），忽然某一台机器的接口调用状况正确率降到90%，那么这台机器确定出现问题了，这个时候就须要熔断这台机器，把这台机器从整个集群中摘掉，从而保证用户的请求100%的正确，再好比，一个系统中有不少功能，这些功能有些是核心功能，有些是非核心功能，那么在一些大促中，咱们可能熔断掉一些非核心功能，从而保证核心功能的流转（登陆和注册，登陆属于核心，注册是属于非核心）
git

为何须要降级和熔断

不论是降级仍是熔断，都是为了保证了系统的稳定性，可用性。降级每每表明系统功能部分不可用，熔断表明的是彻底不可用，再举一个简单例子，注册功能，降级可能出现的状况是手机号能够正常，邮箱不能注册，而熔断出现的状况是注册功能彻底不可用，因此说有时候熔断是一种特殊的降级。这在整个系统设计编码中都须要考虑到。github

经常使用的降级和熔断策略

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

全部业务系统都须要考虑的东西，就意味着能够优化，能够剥离，抽象出来，作成公共组件，中间件，造成通用性。api

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

降级

超时降级（调用服务时超时返回默认值或者其它处理办法）
失败次数降级（服务可用率降低时降级）
限流也是降级的一种办法
故障降级（依赖的外系统发生故障时降级）
拒绝服务降级

熔断

系统攻击熔断（当某个服务遭遇流量攻击时，能够熔断这个服务）
涉及核心功能运行时的熔断（下单和评论功能，关键时刻能够熔断评论功能）

无论降级仍是熔断，在设计时都要考虑：降级熔断算法，恢复机制，报警。这些是必备的，不能系统降级了或者熔断了就没法回复以前的状况，也不能不报警，要否则开发人员都不知道，这还得了。异步

熔断和降级的异样性

二者的目的至关
二者的最终的表现的相同
粒度同样，大多数都是服务级别的粒度，也有多是方法级别的
自治性要求比较高（尽量的智能化）
降级通常是客户端处理，熔断是在服务端处理的

设计方案

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

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引入如下手段来保护系统：优化

资源隔离（线程池和信号量两种手段的隔离）
限流
降级
熔断（断路器）

Hystrix如何设计实现这些手段呢？编码

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

用代码实现一个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