sentinel接入第1个应用A以及控制台,已经上线一段时间了,本周接入了第2个应用B;
因为测试同学只有几个,没有压测团队、测试平台。。 各接口能承载的最大qps不确定 ,接入的应用暂时都没有配置规则。
sentinel控制台主要用到机器列表、实时监控,进行一些节点ip、状态,各接口qps、rt的查看。
应用A部署了4个节点,其中有2个最近了进行虚拟机迁移。有一天上游监控告警,看日志是调用A服务这2个节点的方法出现了大量dubbo线程满的异常;
查看A的日志,有很多Thread pool is EXHAUSTED!
dump出堆栈日志,发现是一起某一个方法block住了,A的线程池配置的500个,都是这个方法block。
该方法使用了异步mq消息,请运维同学帮忙看, 新节点连mq是网络正常的。由于是偶现,原因暂时没定位到。
由于A服务接入了sentinel,想到了增加流控规则的方法。于是将2个有问题节点的服务A重启,通过sentinel控制台的簇点链路,搜索到该方法
点击新增流控规则,增加了1个类型为线程数,阈值为50的规则。
通过实时监控的页面发现,该方法已被sentinel限流快速失败。A服务也没有出现线程满的情况。
在正常情况下,即没有超过50个线程,该方法也不会被限流。
用word画了一个示意图:
---------------------------------------------------------------------------------------------------------------------------------------
总结:
这是目前线上应用接入sentinel后添加的第一个流控规则。
场景很典型:通过线程数的流控规则,保护上游应用不会因调下游服务的某一个方法导致本身被拖垮。
---------------------------------------------------------------------------------------------------------------------------------------
以下是sentinel官方blog中的一个限流场景:
并发线程数限流
Service Consumer 作为客户端去调用远程服务。每一个服务都可能会依赖几个下游服务,若某个服务 A 依赖的下游服务 B 出现了不稳定的情况,服务 A 请求 服务 B 的响应时间变长,从而服务 A 调用服务 B 的线程就会产生堆积,最终可能耗尽服务 A 的线程数。我们通过用并发线程数来控制对下游服务 B 的访问,来保证下游服务不可靠的时候,不会拖垮服务自身。基于这种场景,推荐给 Consumer 配置线程数模式的限流,来保证自身不被不稳定服务所影响。采用基于线程数的限流模式后,我们不需要再显式地去进行线程池隔离,Sentinel 会控制资源的线程数,超出的请求直接拒绝,直到堆积的线程处理完成,可以达到信号量隔离的效果。
---------------------------------------------------------------------------------------------------------------------------------------
参考:
Sentinel 为 Dubbo 服务保驾护航 http://dubbo.incubator.apache.org/zh-cn/blog/sentinel-introduction-for-dubbo.html