参考文章：https://blog.csdn.net/guwei9111986/article/details/51649240/
我的理解：
熔断：需要侵入业务代码，它的目标不是下掉服务，而是让服务能够继续稳定，且快速响应。只是返回值是mock的数据。可以通过Hystrix实现熔断
降级：可以不需要侵入代码，或者侵入较少。由负责人评估系统负载，如果过高的话，通过开关，配置中心等手段，下掉某些非核心服务。目标是下掉非核心或者不重要的服务。为核心服务让出资源。
限流：当熔断和降级后，系统的负债继续加大，就必须限流了，不能让流量源源不断的进入。
伴随着微服务架构被宣传得如火如荼，一些概念也被推到了我们面前（管你接受不接受），其实大多数概念以前就有，但很少被提的这么频繁（现在好像不提及都不好意思交流了）。想起有人总结的一句话，微服务架构的特点就是：“一解释就懂，一问就不知，一讨论就吵架”。
其实对老外的总结能力一直特别崇拜，Kevin Kelly、Martin Fowler、Werner Vogels……，都是著名的“演讲家”。正好这段时间看了些微服务、容器的相关资料，也在我们新一代产品中进行了部分实践，回过头来，再来谈谈对一些概念的理解。
今天先来说说“服务熔断”和“服务降级”。为什么要说这个呢，因为我很长时间里都把这两个概念同质化了，不知道这两个词大家怎么理解，一个意思or有所不同？现在的我是这么来看的：
- 在股票市场，熔断这个词大家都不陌生，是指当股指波幅达到某个点后，交易所为控制风险采取的暂停交易措施。相应的，服务熔断一般是指软件系统中，由于某些原因使得服务出现了过载现象，为防止造成整个系统故障，从而采用的一种保护措施，所以很多地方把熔断亦称为过载保护。
- 大家都见过女生旅行吧，大号的旅行箱是必备物，平常走走近处绰绰有余，但一旦出个远门，再大的箱子都白搭了，怎么办呢？常见的情景就是把物品拿出来分分堆，比了又比，最后一些非必需品的就忍痛放下了，等到下次箱子够用了，再带上用一用。而服务降级，就是这么回事，整体资源快不够了，忍痛将某些服务先关掉，待渡过难关，再开启回来。
所以从上述分析来看，两者其实从有些角度看是有一定的类似性的：
- 目的很一致，都是从可用性可靠性着想，为防止系统的整体缓慢甚至崩溃，采用的技术手段；
- 最终表现类似，对于两者来说，最终让用户体验到的是某些功能暂时不可达或不可用；
- 粒度一般都是服务级别，当然，业界也有不少更细粒度的做法，比如做到数据持久层（允许查询，不允许增删改）；
- 自治性要求很高，熔断模式一般都是服务基于策略的自动触发，降级虽说可人工干预，但在微服务架构下，完全靠人显然不可能，开关预置、配置中心都是必要手段；
而两者的区别也是明显的：
- 触发原因不太一样，服务熔断一般是某个服务（下游服务）故障引起，而服务降级一般是从整体负荷考虑；
- 管理目标的层次不太一样，熔断其实是一个框架级的处理，每个微服务都需要（无层级之分），而降级一般需要对业务有层级之分（比如降级一般是从最外围服务开始）
- 实现方式不太一样，这个区别后面会单独来说；
当然这只是我个人对两者的理解，外面把两者归为完全一致的也不在少数，或者把熔断机制理解为应对降级目标的一种实现也说的过去，可能“一讨论就吵架”也正是这个原因吧！
网友评论