微服务架构服务容错设计分析

作者 |慕枫Java
来源 | 慕枫技术笔记(ID：lulideguang)

引言

在微服务体系架构中，由于拆解的服务数变多了，服务发生故障的地方也会相应的增加，因此如何保证服务架构健壮是一个值得深思的问题。微服务容错机制正是这样一种稳定性解决方案，可以理解微服务架构的保险丝，通过它可以对业务平台形成一种有效的保护机制。在发生平台异常时候，容错机制是平台稳定运行的最后一道屏障。

微服务架构为什么需要容错机制

说起来可能有一些年头了，以前小时候家里面经常出现电压不稳电灯忽明忽暗，有时候甚至出现短路停电的情况。每次一片漆黑的时候，大人们最常说的一句话就是：哎，估计又是保险丝断了哦。这里的保险丝就是保护家中电路电器的一种手段，当发生短路情况时，通过熔断保险丝来保护家中电器不受电流过载的影响。

在微服务架构体系中的熔断降级正是起到保险丝作用的基础组件。我们在进行架构设计时，不仅需要满足业务要求，同时也需要面向失败进行设计，意思就是说当外部条件发生变化或者内部出现异常时，平台的架构能够将这种异常的影响降到最低，强大的容错能力是优秀架构的关键指标。

回到今天的主题容错机制，我们可以反过来想，如果没有如果没有熔断降级系统容错机制，整个系统平台在异常情况下，会发生怎样的系统反应，我们先看下以下几种场景。

场景一：服务节点异常影响上游服务调用方

假设我们有客户端服务，需要分别调用Service1集群的接口、Service2集群的接口以及Service3集群的接口来完成一项业务流程，如果Service3集群发生异常情况，服务都还在，但是可能由于出现fullGC、慢查询、业务异常等情况，客户端在调用Service3集群时出现timeout，不能在规定时间内进行服务响应。当调用请求不断发出时，此时Client中的工作线程将会被这些调用的time out阻塞住，当业务不断进行请求时，Client对应的工作线程会越来越多的被阻塞住，进而导致客户端不可用。

当此客户端不可用时，可能上层调用方也会由Client的不可用向上影响，导致上层调用方也出现异常，就像病毒一样一层一层的传导，异常影响被不断向上放大，最终导致整个平台不可用。

场景二：流量激增导致服务不可用，影响其他依赖该服务的服务异常

我们假设Service1集群可以承载6000QPS的流量，正常情况下上游三个服务的流量总和都小于这个阈值。但是当流量发生激增时，其中一个服务的QPS就超过了10000QPS，超出了Service1集群的服务能力，因此造成了集群的异常出现响应异常的情况，此时Service2集群以及Service3集群由于依赖Service1集群的服务，同样会出现线程阻塞的情况，最终导致整个平台的异常。

因此基于以上分析，微服务架构中引入熔断降级组件是为了提升微服务架构整体的容错能力。主要避免以下三种场景对平台稳定性的影响。

1、单个服务集群节点出现异常故障，其影响范围可能被无限向上游服务放大;

2、由于使用了共同基础服务，基础服务出现异常时，多租户相互影响;

3、某个服务的瞬时流量突增，某个服务集群扛不住，影响整个平台稳定性;

如何破局

资源隔离

我们以现实生活中的船舱为例，实际的船舱格局大致如下所示，船舱底部并不是完全的一整个空心结构，而是通过格子进行区域隔离。为什么这么设计呢?主要还是为了一旦发生船舱漏水，只影响其中一个隔离区域，而不是整个船舱都灌满水，从而达到一定程度保护船体不会因为一处漏洞而沉没的目的。

那么借助于船舱隔离的思想，在我们的程序世界中，我们是不是也可以采用资源隔离的方式来保护我们的微服务架构呢?答案是肯定的，也的确是这么做的。

1、线程池隔离

我们可以通过线程池隔离的方式来实现资源的隔离，不同的请求使用相应的线程池来处理，即便出现请求资源time out的情况，最多影响当前线程池的资源，而不会影响整个服务的线程资源。类似船舱中的隔离区域。

2、信号量隔离

信号量主要是用来控制线程数的，规定好一些调用最大的并发量，超过指定的信号量后，可以将请求丢弃或者延时处理，防止线程的不断增长导致的服务异常。

熔断

所谓熔断，正如上文所说，它的作用就是像保险丝一样，在流量过大或者请求错误率过大的情况下，此时保险丝就熔断了，对应的业务链路断开，不再提供服务。当流量恢复正常或者错误降低后，熔断开关再进行闭合，之前的业务链路重新恢复。这是一种很好的保护后端微服务的一种方式。

在大促期间，平台需要用足够的机器去保证核心商业链路正常运转，对于退款、退货这种服务，则可以通过暂时熔断的方式不对外提供服务，当大促过了之后再进行恢复。

在熔断机制中，核心的内容就是断路器的设计，断路器设计主要有两方面一个是状态转换的设计，一个是如何根据阈值以统计数据来执行核心的断路功能。

降级

和熔断的场景有点类似，当系统流量过多时，系统资源有限，平台处理不过来那么多的请求。此时就可以可将不是那么重要的功能模块进行降级处理，停止对外服务，这样可以释放出更多的资源供给核心功能的服务使用。如下所示，商品详情页中，商品服务中方商品列表才是最重要的服务，至于用户的积分以及用户的头像此时并不是核心业务，所以在系统能力有限的情况下，优先让商品服务对外提供服务，其他服务进行降级处理。

总结

本文主要对微服务架构中的容错机制进行了分析，从为什么要有容错机制到如何通过资源隔离、熔断以及降级等方式实现微服务容错保护进行了阐述。下一篇文章将带大家看看熔断降级组件Hystrix的工作原理，敬请期待哦。