微服务专栏地址

1. 简介

微服务的限流容错机制是保证微服务架构体系稳定运行的不可或缺的一个模块，从一下几个方面理解微服务的限流容错：

-
为什么需要限流容错机制
微服务的限流容错相关概念有哪些
3.1 雪崩效应
3.2 容错机制
3.3 限流机制
3.4 降级机制
通过Hystrix来理解限流容错框架
4.1 Hystrix是什么
4.2 Hystrix具体能做什么
4.3 Hystrix设计原则
4.4 整体工作流程图
4.5 实现原理
微服务体系架构中如何选择

2. 为什么需要限流容错机制

简单理解：提高系统稳定性。限流容错机制可以为我们解决的问题：

网络流量限制：如秒杀、抢购、双十一等场景，在某一时间点会有爆发式的网络流量涌入，如果没有好的网络流量限制，任由流量压到后台服务实例，很有可能造成资源耗尽，服务无法响应，甚至严重的导致应用崩溃
限制长时间无响应的请求或者出错的请求在每次请求时都调用后台服务再返回结果，换句话说就是采用一种机制来判断一个请求之前是否已经处理过，并且属于长时间无响应或者是出错的请求，如果是，则直接返回统一处理结果，不再调用后台对应服务

3. 微服务的限流容错相关概念有哪些

搞清楚微服务的限流容错之前，了解一些相关概念是很有必要的

3.1 雪崩效应

在IO型服务中，假设服务A依赖服务B和服务C，而B服务和C服务有可能继续依赖其他的服务，继续下去会使得调用链路过长。如果在A的链路上某个或几个被调用的子服务不可用或延迟较高，则会导致调用A服务的请求被堵住。

堵住的请求会消耗占用掉系统的线程、io等资源，当该类请求越来越多，占用的计算机资源越来越多的时候，会导致系统瓶颈出现，造成其他的请求同样不可用，最终导致业务系统崩溃，雪崩效应。

3.2 容错机制

当服务者无法正常为消费者提供服务时，如请求超时、后台服务无响应、后台服务异常等，通过容错机制直接返回统一处理结果，并对下次请求进行同样处理，直到后台服务功能正常。

微服务的提供者可能是一个基础服务也能是一个聚合服务，当消费者的请求到来，如果服务中的一个或者几个无法正常工作（挂了），此时在不做任何处理的情况下，消费者只能等待，直到超时，在高负载场景下，此类问题可能会导致服务提供者的资源耗尽甚至整个系统崩溃。

3.3 限流机制

防止爆发式流量直接压到后台服务实例，造成资源耗尽、甚至应用崩溃

控制访问流量，通过指定的策略消减流量（如网络层面限制访问流量、后服务实例使用技术手段限制并发数量等），使得落到后台服务实例的请求在能承受的范围内。高并发是常常讨论的话题，如何限流，以及服务的实例能承受的范围是多大，什么情况下需要增加服务实例，调整资源，都需要结合实际进行严格的测试。

3.4 降级机制

当访问量剧增、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务。

弃卒保帅，最终目的是保证核心服务可用，即使是有损的。但是核心服务肯定是无法舍弃的，舍弃也就意味着应用系统无法正常工作。只能是一种保障或者拯救措施。

4. 通过Hystrix来理解限流容错框架

4.1 Hystrix是什么

Hystrix是Netflix解决自己业务不稳定性的一个限流容错框架，可以帮助我们解决微服务架构体系中的限流、降级、熔断等功能。提高系统稳定性，提供了完善的监控实现，并且Hystrix可以根据监控数据动态调整内部处理机制。

4.2 Hystrix具体能做什么

熔断：在第三方客户端访问依赖服务出现高延迟或者失败时，熔断访问请求，为系统提供保护和控制
雪崩：在分布式系统中防止级联失败，避免因为某一个服务功能不正常导致异常扩散
快速失败：Fail fast，同时能快速回复
失败回滚和降级：提供Fallback和优雅的降级机制
监控报警：提供近实时的监控、报警和运维手段

4.3 Hystrix设计原则

防止单个依赖好景容器内所有用户线程
降低系统负载，对无法及时处理的请求使用快速失败（Fail fast）机制而不是排队
提供失败回退功能，意在必要时让失效对用户透明化
使用隔离机制，降低依赖服务对整个系统的影响
针对系统提供服务的监控、报警、度量，满足近实时性的要求
服务快速恢复、配置动态调整、快速部署
保护应用不受依赖服务的整个执行过程中失败的影响，不仅仅是网络请求

4.4 整体工作流程图

整体工作流程图

流程说明:

每次调用创建一个新的HystrixCommand,把依赖调用封装在run()方法中.
执行execute()/queue做同步或异步调用.
当前调用是否已被缓存，是则直接返回结果，否则进入步骤 4
判断熔断器(circuit-breaker)是否打开,如果打开跳到步骤 8,进行降级策略,如果关闭进入步骤 5.
判断线程池/队列/信号量是否跑满，如果跑满进入降级步骤8,否则继续后续步骤 6
调用HystrixCommand的run方法.运行依赖逻辑
6.1. 调用是否出现异常，否：继续，是进入步骤8，
6.2. 调用是否超时，否：返回调用结果，是进入步骤8
搜集5、6步骤所有的运行状态(成功, 失败, 拒绝,超时)上报给熔断器，用于统计从而判断熔断器状态.
getFallback()降级逻辑.四种触发getFallback调用情况（图中步骤8的箭头来源）：
返回执行成功结果

步骤8详细说明：
产生原因：

run()方法抛出非HystrixBadRequestException异常。
run()方法调用超时
熔断器开启拦截调用
线程池/队列/信号量是否跑满

处理结果：

没有实现getFallback的Command将直接抛出异常
fallback降级逻辑调用成功直接返回
降级逻辑调用失败抛出异常

4.5 实现原理

后续demo以及实际使用中深入了解、分析，传送门：How it Works

5. 微服务体系架构中如何选择

Hystrix

业界广泛使用
能力已得到证明
完善的限流容错机制
完善的监控机制，包括分布式监控实现
与其他框架良好集成

九：对微服务限流容错的理解