现在的web应用，基本上都会采用微服务架构，复杂的web应用系统中，会有几个甚至十几个微服务，应用系统在对外提供服务的背后，是很多个微服务相互依赖，相互协作完成的。每个微服务负责一个或多个功能的实现，通过对外暴露接口的形式，来实现自己的价值。正常情况下，多个微服务正常运行，在自己的工作岗位上，尽职尽责，对依赖自己的调用方，提供服务。但是，随着系统服务周期的增长，总会有某个，或者某几个服务出现不可用的情况，当一个服务出现了不可用，不仅自身无法对外提供服务，依赖自己的服务也会受到影响，变得不可用，一个服务的不可用，随着依赖关系的扩展，会导致更多的服务不可用，如果没有人工介入，可能会导致整个系统都会变得不可用。
在业务系统开发的过程中，要保证功能需求(这个是最基本的)，非功能需求也要一定满足。否则，出现上了上面的问题，整个系统都不可用了，那么开发的功能需求，也就没有意义了。系统的可用性，是一个系统非功能需求中比较重要的指标。
在微服务系统架构中，保障系统可用性的常用手段，有以下三个：熔断，降级和限流。整体来说，这三者都是采用通过牺牲系统吞吐量，来防止问题扩大化的一种手段，通过人为让系统部分不可用的手段，来避免系统整体不可用的灾难，是一种丢卒保车，断尾求生的做法，三者都是为了完成这一目的，只不过实现过程中，侧重点不同而已。对这三者有了一个整体认识之后，我们再来看一下，三者分别的侧重点都是什么。
1)什么是熔断
熔断主要针对具体某个接口出现问题时，对这个接口采用的临时方案，它站在接口或者服务的层面来考虑问题。防止因为某个接口出现问题，导致问题蔓延，直至整个系统不可用。例如：某个接口的提供方宕机，导致接口调用方频繁超时，调用方的上游受到影响，进而也会超时，最终整个链路都会变得超时，如果超时时间很长的话，会导致客户端系统资源浪费(一些池化的资源，长时间得不到释放)。此时可以在接口的调用方进行对该接口的熔断，具体做法：可以是直接返回一个默认值。防止频繁的调用超时。可以通过不断的对该接口进行可用性探测，当检测到该接口可用时，对熔断逻辑进行撤销，具体可以参考hystrix。
2)什么是降级
降级是系统应对突发流量的解决方案，它站在系统层面来考虑问题，目的是为了保证整个系统的可用性。因为受系统自身资源的限制，可以处理的流量时是有限的，不能对突发流量进行完全处理，那么此时就应该对流量进行有选择的处理，让系统只处理优先级高的流量，优先级低的流量不进行处理，直接返回默认值(或者其他处理策略)，也就是对部分低优先级流量进行舍弃，例如，双十一期间，很多电商网站的评论，收藏功能变得不可用，这里就是系统为了保证网站核心功能可用，对评论和收藏功能进行了降级，将系统资源用在核心业务上，正所谓"好钢用在刀刃上"。
但是，这种方案为什么叫做"降级"呢？好像没有体现出"降级"的语义。其实降级，是站在整个系统维度来说的，举例来说：系统正常情况下，可以对外提供10个接口服务，在降级的情况下，只能对外提供5个接口服务，那么此时的系统，就是有"瑕疵"的系统，能够完整提供服务的系统，我们给系统打5星，现在系统中一部分功能不可用了，那么此时系统只能打3星，系统的"级别"有所下降了。
3)什么是限流
限流和降级所做的事情相似，也是站在系统层面来考虑问题，都是在系统遇到突发大流量所做的应急方案。为了保证系统不被大流量冲垮，降级所做的事情是对流量进行有选择的处理，让系统处理总流量中的一部分。这里的有选择，主要是按照流量的优先级进行选择的。而限流则是通过对流量进行采样，例如1000个请求，通过80%采样后，系统只处理其中的800个，剩下的200个，通过限流策略进行过滤，这里的过滤更强调无差别的过滤。
总体来说，熔断，降级和限流，是系统面对突发流量，限于自身系统资源不足的一种"无奈"的做法，是一种兜底方案，系统设计的时候一定要考虑这些兜底方案，但是最好不要用上，因为它会降低系统的可用性，所以在遇到大流量前，一定要做好容量评估。