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