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