微服务优势之一是可缩小故障影响范围，局限在某个服务中。那一个服务出现故障该如何处理？
1 集群故障
可能整个集群都会故障，无法再对外提供服务。
1.1 故障原因
代码bug
比如OOM
突发的流量冲击，超出了系统的最大承载能力
比如秒杀，会在某个时刻瞬间涌入大量流量，超出系统承载能力
1.2 解决方案
1.2.1 限流
系统所能承载流量根据集群规模是固定的，称为系统最大容量。当真实流量超过系统最大容量，系统响应就会变慢，服务调用出现大量超时，用户就会感觉卡顿、无响应。所以，应根据系统最大容量，给系统设置阈值，超过阈值的请求会被自动丢弃，便可保证系统服务正常。
通常一个微服务系统会同时提供多个服务，每个服务在同一时刻的请求量也不同，很可能系统中某服务的请求量激增，占用系统大部分资源，导致其他服务无资源可用。
因此，要针对系统中每个服务的请求量设置阈值，超过阈值的请求也要丢弃，不至于因为一个服务影响其他服务。
可用如下指标衡量服务的请求量：
QPS
工作线程数
QPS因不同服务的响应快慢不同，所以系统能承载QPS相差大，所以一般选择工作线程数作为限流指标，给系统设置
总的最大工作线程数
单个服务的最大工作线程数
如此，无论是系统总请求量过大导致整体工作线程数量达到最大工作线程数，还是某服务的请求量超过单个服务的最大工作线程数，都会被限流。
1.2.2 降级
通过停止系统中的某些功能，保证系统整体的可用性，属一种被动防御方案，因为一般是系统已故障后所采取的一种止损操作。
如何实现
通过开关，在系统运行的内存中开辟一块区域，专门用于存储开关状态：开启还是关闭。并且需监听某端口，通过该端口可向系统下发命令以改变内存中开关状态。当开关开启时，业务的某段逻辑就不再执行，而正常情况下，开关是关闭的状态。
适用场景
新增的业务逻辑
因为新增的业务逻辑相对来说不成熟，充满风险，需加开关控制新业务逻辑是否执行
依赖的服务或资源
因依赖的服务或资源不总是可靠，最好有开关控制是否对依赖服务或资源发起调用，以保证即使依赖出现问题，也能降级避免影响
分级
一级降级，对业务影响最小的
故障时，先执行一级降级，所以一级降级也可设置成自动降级而无需人工
二级降级，对业务有一定影响
故障时，若一级降级起不了啥作用，可采取人工
三级降级，对业务较大影响
这种降级要么对重大影响金钱交易，要么严重影响用户体验
