概览
微服务作为一种软件架构风格，强调将业务系统服务化和组件化。通过微服务间的组合完成业务系统的整体功能，相较于单体系统架构来说，微服务架构耦合性更低。在业务开发过程中无需关注改动功能以外的范畴，从而实现敏捷开发与部署。并且，同一个业务系统的各个微服务可以用不同的语言实现，服务间通过 rpc 或 kafka 等方式进行通信。
微服务雪崩
在微服务的链式调用中，当下游微服务失去响应时，上游微服务的请求就会被阻塞。当请求过多时，则会消耗大量的线程，内存等资源，从而引起上游微服务的宕机。
例如，在一个业务系统中，同时有 3 个 service 分别为 A, B, C。他们的调用链路如下图所示，当 service C 因为一系列原因宕机时，service B 因为大量的请求得不到响应而阻塞也跟着宕机，最终 A 也受到 Service B 的宕机影响而挂掉。
微服务降级
当下游链路宕机时，如何保证上游微服务不会不会因为过多请求阻塞而跟着宕机呢？微服务降级。降级方案是对业务具有侵入性的。在设计初期就要明确降级的指标是多少（比如 SLA 降低到多少就开启自动降级或者人工降级），同时明确核心功能与次要功能，在整个服务面临挂掉的风险时，可以考虑停用次要功能保证核心功能的正常使用。
降级的方案包括流量降级，效果降级以及功能性降级。流量降级是指当通过主动拒绝处理部分流量的方式让系统正常服务未降级的流量，这会造成部分用户服务不可用；效果降级表现为服务质量的降级，即在流量高峰时期用相对低质量、低延时的服务来替换高质量、高延时的服务，保障所有用户的服务可用性；功能性降级也表现为服务质量的降级，指的是通过减少功能的方式来提高用户的服务可用性。效果降级和功能性降级比较接近，效果降级强调的是主功能服务质量的下降，功能性降级更多强调的是辅助性功能的缺失。做一个类比如下：计划将100个工程师从北京送到夏威夷度假，但是预算不够。采用流量降级策略，只有50工程师做头等舱去了夏威夷度假，其余工程师继续编写程序（这可不好）；效果降级策略下，100个工程师都坐经济舱去夏威夷；采用功能性降级策略，100个工程师都坐头等舱去夏威夷，但是飞机上不提供食品和饮料。