微服务之容错保护

简介

        在微服务架构中，由于将单体应用进行服务拆分，各服务之间功能尽可能保持单一职责，然而在响应用户请求结果时，常常是通过众多服务互相调用形成的，由于每个单元都运行在不同的进程中（不同的微服务），服务依赖之间通过远程调用方式进行，这样很有可能因为网络原因或者微服务本身故障出现调用延迟，而这又会导致调用方出现延迟，此时，如果用户请求不断增加，极有可能出现过多的服务调用放等待，一个服务占用一个线程，线程过多可能导致服务器奔溃，造成严重的后果。

        我们常把因服务容错性不好，由于某一服务出现问题引起大量用户请求等待，导致服务器宕机的情况称为“雪崩效应”。比如：单点登录服务调用用户信息服务查询用户信息，由于用户信息服务无法提供服务导致单点登录服务一直等待，从而导致用户登录、用户退出功能无法使用，像这样由一个服务所引起的一连串的多个服务无法提供服务即是微服务的雪崩效应。

图片来自个人微信公众号 图片来自个人微信公众号 图片来自个人微信公众号

        我们可将服务雪崩的参与者简化为 服务提供者 和 服务调用者, 并将服务雪崩产生的过程分为以下三个阶段来分析形成的原因:

（1）服务提供者不可用：程序bug、用户大量请求

（2）重试加大流量：用户重试、代码逻辑重试

（3）服务调用者不可用：资源耗尽，当服务调用者使用 同步调用 时,会产生大量的等待线程占用系统资源

图片来自个人微信公众号

容错保护（Hystrix）

        为了防止“雪崩效应”，我们必须提供一个容错机制，当调用延迟超过一定时间时，可以采取一定措施处理，而不是让其一直处于等待状态，简单来说，该机制主要实现点如下：

1.为网络请求设置超时时间：

        主要是防止因服务故障或网络延迟导致请求堆积，占用服务器资源；

2.使用断路器模式：

        当调用出错或者超时，服务可以将此请求标记为失败，给调用方返回信息提示，即调用失败处理方法。熔断机制可以很好理解，想想家里的电路熔断器，一旦电路发生短路，立即切断电路，保护人身财产安全。

原理

        Spring CloudHystrix 是基于Netflix的开源框架Hystrix的整合，是一个开源的容错库，用户隔离访问远程服务，防止级联失败，它实现了断路器、线程隔离、信号隔离等容错功能，能够在一个、或多个依赖同时出现问题时保证系统依然可用。如下是Hystrix断路器示意图：

图片来自个人微信公众号 图片来自个人微信公众号

概念理解

        熔断：切断项目对指定服务的调用。

        降级：当某个服务熔断之后，服务器将不再被调用，此时客户端可以自己准备一个本地的fallback回调，返回一个缺省值。

        依赖隔离：使用舱壁模式实现线程池的隔离，它会为每 一个依赖服务创建 一个独立的线程池， 这样就算某个依赖服务出现延迟过高的情况， 也只是对该依赖服务的调用产生影响， 而不会拖慢其他的依赖服务。

        备注：不用担心为每一个依赖服务都分配一个线程池是否会过多地增加系统的负载和开销。

配置步骤

（1）添加Hystrix依赖，非常简单：

图片来自个人微信公众号

（2）在启动类添加@enableHystrix注解，开启容错保护功能：

图片来自个人微信公众号

（3）使用Hystrix实现容错，注解配置服务降级：

服务降级执行方式

（1）同步执行：即一旦开始执行该命令，当前线程就得阻塞着直到该命令返回结果，然后才能继续执行下面的逻辑。当调用命令的execute()方法即为同步执行。

图片来自个人微信公众号

（2）异步执行：命令开始执行会返回一个Future的对象，不阻塞后面的逻辑，开发者自己根据需要去获取结果。当调用HystrixCommand的queue()方法即为异步执行。

图片来自个人微信公众号

（3）响应式执行：命令开始执行会返回一个Observable 对象，开发者可以给给Obeservable对象注册上Observer或者Action1对象，响应式地处理命令执行过程中的不同阶段。当调用HystrixCommand的observe()方法，或使用Observable的工厂方法（just(),from()）即为响应式执行。

        后续再进行补充完善。