1.服务熔断
1.1 什么是服务熔断？
如果某个目标服务调用慢或者有大量超时，此时，熔断该服务的调用，对于后续调用请求，不在继续调用目标服务，直接返回，快速释放资源。如果目标服务情况好转则恢复调用。
1.2 熔断器 Circuit Breaker
在Hystrix中，对应配置如下
//滑动窗口的大小，默认为20 circuitBreaker.requestVolumeThreshold //过多长时间，熔断器再次检测是否开启，默认为5000，即5s钟 circuitBreaker.sleepWindowInMilliseconds //错误率，默认50% circuitBreaker.errorThresholdPercentage
每当20个请求中，有50%失败时，熔断器就会打开，此时再调用此服务，将会直接返回失败，不再调远程服务。
直到5s钟之后，重新检测该触发条件，判断是否把熔断器关闭，或者继续打开。
熔断器的状态机：
closed->open:正常情况下熔断器为closed状态，当访问同一个接口次数超过设定阈值并且错误比例超过设置错误阈值（circuitBreaker.errorThresholdPercentage）时候，就会打开熔断机制，这时候熔断器状态从closed->open。
open->half-open:当服务接口对应的熔断器状态为open状态时候，所有服务调用方调用该服务方法时候都是执行本地降级方法，那么什么时候才会恢复到远程调用那？Hystrix提供了一种测试策略，也就是设置了一个时间窗口（circuitBreaker.sleepWindowInMilliseconds），从熔断器状态变为open状态开始的一个时间窗口内，调用该服务接口时候都委托服务降级方法进行执行。如果时间超过了时间窗口，则把熔断状态从open->half-open,这时候服务调用方调用服务接口时候，就可以发起远程调用而不再使用本地降级接口，如果发起远程调用还是失败，则重新设置熔断器状态为open状态，从新记录时间窗口开始时间。
half-open->closed: 当熔断器状态为half-open,这时候服务调用方调用服务接口时候，就可以发起远程调用而不再使用本地降级接口，如果发起远程调用成功，则重新设置熔断器状态为closed状态。
2. 服务降级
2.1 什么是服务降级？
这里有两种场景:
- 当下游的服务因为某种原因响应过慢，下游服务主动停掉一些不太重要的业务，释放出服务器资源，增加响应速度！
- 当下游的服务因为某种原因不可用，上游主动调用本地的一些降级逻辑FallbackFactory，避免卡顿，迅速返回给用户“一个默认的值”！
其实乍看之下，很多人还是不懂熔断和降级的区别!
其实应该要这么理解:
- 服务降级有很多种降级方式！如开关降级、限流降级、熔断降级!
- 服务熔断属于降级方式的一种！
2.2 什么是开关降级？（了解）
开关降级!这也是我们生产上常用的另一种降级方式！
做法很简单，做个开关，然后将开关放配置中心！在配置中心更改开关，决定哪些服务进行降级。至于配置变动后，应用怎么监控到配置发生了变动，这就不是本文该讨论的范围。
2.3 什么是埋点？（了解）
那么，在应用程序中部下开关的这个过程，业内也有一个名词，称为埋点！
那接下来最关键的一个问题，哪些业务需要埋点？
一般有以下方法
(1)简化执行流程
自己梳理出核心业务流程和非核心业务流程。然后在非核心业务流程上加上开关，一旦发现系统扛不住，关掉开关，结束这些次要流程。
(2)关闭次要功能
一个微服务下肯定有很多功能，那自己区分出主要功能和次要功能。然后次要功能加上开关，需要降级的时候，把次要功能关了吧！
(3)降低一致性
假设，你在业务上发现执行流程没法简化了，愁啊！也没啥次要功能可以关了，桑心啊！那只能降低一致性了，即将核心业务流程的同步改异步，将强一致性改最终一致性！
可是这些都是手动降级，有办法自动降级么？
这里我摸着良心说，我们在生产上没弄自动降级！因为一般需要降级的场景，都是可以预见的，例如某某活动。假设，平时真的有突发事件，流量异常，也有监控系统发邮件通知，提醒我们去降级！
当然，这并不代表自动降级不能做，因此以下内容可以认为我在胡说八道，因为我在生产上没实践过，只是头脑大概想了下，如果让我来做自动降级我会怎么实现：
- (1)自己设一个阈值，例如几秒内失败多少次，就启动降级
- (2)自己做接口监控(有兴趣的可以了解一下Rxjava)，达到阈值就走推送逻辑。怎么推呢？比如你配置是放在git上，就用jgit去改配置中心的配置。如果配置放数据库，就用jdbc去改。
- (3)改完配置中心的配置后，应用就可以自动检测到配置的变化，进行降级！(这句不了解的，了解一下配置中心的热刷新功能)