微服务故障应对策略与实战验.pdfVIP

20|服务端出现故障时该如何应对？

2018-10-06想

20|服务端出现故障时该如何应对？

朗读人：想09′49′′|4.51M

在专栏前面我讲过，单体应用改造成微服务的一个好处是可以减少故障影响范围，故障被局限在一

个微服务系统本身，而不是整个单体应用都。那么具体到一个微服务系统，如果出现了故障，

应该如何处理呢？

首先，我先来带你回顾一下微服务系统可能出现故障的种类，主要有三种故障。

集群故障。根据我的经验，微服务系统一般都是集群部署的，根据业务量大小而定，集群规模从

几台到甚至上都有可能。一旦某些代码出现bug，可能整个集群都会发生故障，不能对

外服务。

单IDC故障。现在大多数互联网公司为了保证业务的高可用性，往往业务部署在不止一个IDC。

然而现实中时常会发生某个IDC的光缆因为道路施工被挖断，导致整个IDC脱网。

单机故障。顾名思义就是集群中的个别机器出现故障，这种情况往往对全局没有太大影响，但会

导致调用到故障机器上的请求都失败，影响整个系统的成功率。

在我的实践过程中，这三种故障都经常遇到，因此相应的处理也可谓驾轻就熟，下面就把我应

对故障的实战经验给你，希望对你有所帮助。

集群故障

一般而言，集群故障的产生不外乎有两种：一种是代码bug所导致，比如说某一段Java代码

不断地分配大对象，但没有及时回收导致JVMOOM；另一种是的流量冲击，超出了系统

的最大承载能力，比如“双11”这种购物活动，系统会在零点一瞬间涌入大量流量，超出系统的

最大承载能力，一下子就把整个系统给压垮了。

应付集群故障的思路，主要有两种：限流和降级。

1.限流

顾名思义，限流就是限制流量，通常情况下，系统能够承载的流量根据集群规模的大小是固定的，

可以称之为系统的最大容量。当流量超过了系统的最大容量后，就会导致系统响应变慢，服务

调用出现大量超时，反映给用户的感觉就是卡顿、无响应。所以，应该根据系统的最大容量，给系

统设置一个阈值，超过这个阈值的请求会被自动抛弃，这样的话可以最度地保证系统的服

务正常。

除此之外，通常一个微服务系统会同时多个服务，每个服务在同一时刻的请求量也是不同的，

很可能出现的一种情况就是，系统中某个服务的请求量突增，占用了系统中大部分资源，导致其他

服务没有资源可用。因此，还要针对系统中每个服务的请求量也设置一个阈值，超过这个阈值的请

求也要被自动抛弃，这样的话不至于因为一个服务影响了其他所有服务。

在实际项目中，可以用两个指标来衡量服务的请求量，一个是QPS即每秒请求量，一个是工作线

程数。不过QPS因为不同服务的响应快慢不同，所以系统能够承载的QPS相差很大，因此一般选

择工作线程数来作为限流的指标，给系统设置一个总的最大工作线程数以及单个服务的最大工作线

程数，这样的话无论是系统的总请求量过大导致整体工作线程数量达到最大工作线程数，还是某个

服务的请求量超过单个服务的最大工作线程数，都会被限流，以起到保护整个系统的作用。

2.降级

什么是降级呢？在我看来，降级就是通过停止系统中的某些功能，来保证系统整体的可用性。降级

可以说是一种防御的措施，为什么这么说呢？因为它一般是系统已经出现故障后所采取的一种

止损措施。

那么降级一般是如何实现的呢？根据我的实践来看，一种可行的方案是通过开关来实现。

具体来讲，就是在系统运行的内存中开辟一块区域，专门用于开关的状态，也就是开启还是关

闭。并且需要某个端口，通过这个端口可以向系统下发命令，来改变内存中开关的状态。当开

关开启时，业务的某一段逻辑就不再执行，而正常情况下，开关是关闭的状态。

开关一般用在两种地方，一种是新增的业务逻辑，因为新增的业务逻辑相对来说不成熟，往往具备

一定的风险，所以需要加开关来控制新业务逻辑是否执行；另一种是依赖的服务或资源，因为依赖

的服务或者资源不总是可靠的，所以是有开关能够控制是否对依赖服务或资源发起调用，来保

证即使依赖出现问题，也能通过降级来避免影响。

在实际业务应用的时候，降级要按照对业务的影响程度进行分级，一般分为