「微服务系列 13」熔断限流隔离降级

我们知道微服务分布式依赖关系错综复杂，比方说前端的请求转化为后端调用的服务请求，一个前端请求会转为成很多个后端调用的服务请求，那么这个时候后台的服务出现不稳定或者延迟，如果没有好的限流熔断措施，可能会造成用户体验的下降，严重的时候会出现雪崩效应，把整个网站给搞垮，如果向阿里巴巴在双11等活动中，如果没有一套好的限流熔断措施，这是不可想象的，可能是根本无法支撑那么大的并发容量。

netflix在2012年前也没有设计好的限流容错，当时也是饱受着系统稳定性的困扰，好几次网站因为没有好的熔断措施把网站搞垮，在2012年netflix启动了弹性工程项目，其中有一个产品叫hystrix，这个产品主要用来解决微服务的可靠性，有了这个系统之后，netflix在系统稳定性上上了一个大的台阶，在此之后就没有出现过大规模的雪崩事故

下面使用hystrix也例子来讲解一下限流熔断

几个概念：

熔断，隔离，限流，降级，这几个概念是分布式容错最重要的概念和模式。

熔断

如果说房子里面安装了电路熔断器，当你使用超大功率的电路时，有熔断设配帮你保护不至于出问题的时候把问题扩大化。

隔离

我们知道计算资源都是有限的，cpu，内存，队列，线程池都是资源，他们都是限定的资源数，如果不进行隔离，一个服务的调用可能要消耗很多的线程资源，把其他服务的资源都给占用了，那么可能出现应为一个服务的问题连带效应造成其他服务不能进行访问。

限流

让大流量的访问冲进去我们的服务时，我们需要一定的限流措施，比方说我们规则一定时间内只允许一定的访问数从我们的资源过，如果再大的化系统会出现问题，那么就需要限流保护。

降级

如果说系统后题无法提供足够的支撑能力，那么需要一个降级能力，保护系统不会被进一步恶化，而且可以对用户提供比较友好的柔性方案，例如告知用户暂时无法访问，请在一段时候后重试等等。

hystrix

hystrix就把上面说的熔断，隔离，限流，降级封装在这么一个组件里面下图是hystrix内部设计和调用流程

大致的工作流如下：

构建一个HystrixCommand对象，用于封装请求，并在构造方法配置请求被执行需要的参数
执行命令，Hystrix提供了几种执行命令的方法，比较常用到的是synchrous和asynchrous
判断电路是否被打开，如果被打开，直接进入fallback方法
判断线程池/队列/信号量是否已经满，如果满了，直接进入fallback方法
执行run方法，一般是HystrixCommand.run()，进入实际的业务调用，执行超时或者执行失败抛出未提前预计的异常时，直接进入fallback方法
无论中间走到哪一步都会进行上报metrics，统计出熔断器的监控指标
fallback方法也分实现和备用的环节
最后是返回请求响应

博客地址：「微服务系列 13」熔断限流隔离降级

转载于:https://juejin.im/post/5cde87886fb9a07efe2d8a7b