监控大规模Hadoop集群

首先我们来看下限流熔断的出现背景。比如上图的一个微服务间调用关系，我们用这个图作为参考来进行一些常见的场景和问题。

某一个API接口服务调用导致整体资源被耗尽

这是一个比较典型的场景，即某一个API接口服务的大并发，大数据量调用导致服务器线程和内存资源的全部耗尽。

对于API接口服务调用，往往并不怕大并发调用，而是怕长耗时和大数据量的调用，这种接口调用导致连接一直被占用，而是大数据量情况下内存资源也一直被占用而服务是否。在这种场景下往往导致线程池满，或者场景的JVM内存溢出问题，将直接导致整个JVM内存溢出宕机。

即我们常说的单个API服务问题导致所有资源被抢占，而影响到所有API接口调用。

常说的服务调用引发雪崩

在微服务架构下，微服务API接口间相互依赖，形成服务链调用关系，如上图。在这种情况下依赖的API接口服务如果出现问题，那么就会导致上层的各个消费方都出现调用异常，而导致整体服务链调用雪崩。

比如上图里面如果C1出现性能问题，那么将直接导致B1和B2都出现性能问题，而由于B层出现的性能问题又会快速的传递到A层，导致A层相关的API接口服务全部出现问题。

通过上面初步分析也可以看到，服务限流熔断简单来说就是不要因为单个API接口服务出现的异常或性能问题而影响都整体API网关或微服务架构的运行，牺牲或拒绝一个服务的访问往往是确保了更多的服务能够正常被消费和调用。

在梳理清楚以上概念后，我们再回来看下服务限流熔断本身的概念。

限流熔断的基本概念

对于限流熔断，我原来给过一个概念，简单来说限流就是服务请求调用要排队，只给你一个线程池总数，超过就等待，即使你瞬间的请求并发再大也需要慢慢进入。而对于熔断则我们常说的整个服务都处于不可用状态。

今天我们对这个概念重新进行下说明。如下图：


 

简介：多年SOA规划建设，私有云PaaS平台架构设计经验，长期从事一线项目实践

今天准备谈下微服务架构和API网关中的限流熔断，当前可以看到对于Spring Cloud框架本身也提供了Hystrix，主流的开源API网关产品类似Kong网关本身也包括了限流熔断能力。

当然也有完全较为独立的限流熔断开源实现，比如阿里的Sentinel即是我们经常会用到的限流熔断开源产品，而且可以和Dubbo，SpringCloud等各种微服务框架无缝集成。

由于网上大家能够搜索到的关于各开源产品实现的限流熔断功能和使用的文章都很多，因此这篇文章不打算再去介绍这些开源产品，而是从业务场景出发来思考下一个限流熔断功能实现中的一些思路。当然，对于我们常说的资源定义，线程池隔离，滑动时间窗口计算等内容仍然是相通的。

问题和背景说明

（编辑：莆田站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!