提供服務暴露的介面，在流量低的情況或許並不需要考慮限流，因為在資料庫或快取的允許下就能正常的工作，但是當呼叫突然飆公升的時候，那麼就會出現異常情況，比如資料庫的連線池和執行緒池就是一種限流手段，通過限制只有指定數量的工作執行緒，其他執行緒進行佇列等待或是進行拋棄。
目前和dubbo一起運用較多的為alibaba sentinel，而springcloud中主要是運用了hystrix（併發執行緒模式）。
限流實現主要有1、計數器演算法，2、滑動視窗演算法，3、令牌桶演算法，4、漏桶限流演算法。令牌桶和漏桶
計算器演算法，最簡單的一種演算法，原理就是在指定週期內只能執行n個請求，超過n的請求直接限流。假設週期為1分鐘，最多執行100個請求。1-60s 最多100個請求，同時60-120s也最多100個請求，但是在30s和60s期間執行著50個請求，60s-90s期間執行著51個請求，這時候計數器是根據每分鐘進行重置為0，那麼他並未達到限流的條件，因為在60s的時候他已經重置為0了，但實際上呼叫的卻是101個請求，導致限流區域性失效。
為了解決計數器演算法的區域性未生效臨界問題，引入了滑動視窗演算法。以下圖位列，將乙個週期內分為4塊，每次只能執行4個視窗數量的請求，每次往前移動一塊，可以重新統計當前4個視窗的請求數，進行解決對應的臨界值問題。
sentinel運用的就是滑動視窗演算法。
也就是令牌+桶進行實現限流，令牌會根據一定的速度生成，而其中桶用於存放對應的令牌，當桶的容量滿的時候，不再往桶中放入令牌，而每次請求都會消耗一定的令牌，當請求消耗的速度大於令牌生成的速度之後，就會限流。
對請求速度不做限制，但是限制了處理的速度恆定速度的限流演算法，如訊息中介軟體，無論生產者的請求量，訊息的最終消費由消費者決定。
服務a->服務b->服務c
個人理解就是當某個提供服務的服務端異常的時候，但是所有請求還是過來，這時候就會出現所有的前驅呼叫服務端，都在等待該服務端的響應，久而久之造成了服務雪崩。也就是當服務c異常會導致，服務b一直等待，然後請求一多導致服務b也異常，一直到整條線都崩潰，服務雪崩的時候沒有一條伺服器是無辜的，那麼此時就需要為那些異常的伺服器，實現直接返回異常進行熔斷。（通常基於異常比例進行判斷是否熔斷）
降級更像是為了讓服務呼叫方有更好的體驗，比如呼叫突然增多的時候，會導致部分請求可能被限流或是熔斷等原因，這時候需要給使用者乙個稍微友好的提示。如搶購的時候很多會提示稍後再試等。
限流規則：qps模式或是併發執行緒模式
hystrix解決方案：不同的業務邏輯使用不同的執行緒池來隔離業務之間的資源爭搶問題但是會造成執行緒數量過多時的上下文切換問題。
sentinel解決方案：通過統計執行緒數與使用者設定的閾值進行比較，如果小於等於閾值則放行；大於閾值則進行限流策略。統計的模型還是基於滑動時間口
qps代表queries per second每秒的查詢數，當qps達到限流的閾值就會促發限流策略。
直接拒絕（預設策略）、勻速排隊（相當於漏桶限流演算法）、預熱（請求數量逐步遞增）
1、平均響應時間，當該時間超過閾值直接熔斷
2、異常比例，異常總數佔總量比超過閾值
3、異常數
dubbo原始碼解析（dubbo容器部分）
dubbo 解析 dubbo中也有內建的容器介面就是類 com.alibaba.dubbo.container.container 如下所示 spi spring public inte ce container 也同樣是 spi擴充套件點。而且介面非常的簡單，乾淨，在 dubbo 框架中一共出現了...
dubbo負載均衡演算法及原始碼解析
二 最少活躍呼叫數負載均衡策略 leastactive loadbalance 三 輪詢負載均衡策略 roundrobin loadbalance 四 隨機負載均衡策略 random loadbalance dubbo中的負載均衡策略有四種如下 隨機 random 輪詢 roundrobin 最少活...
dubbo原始碼解析 簡單原理
dubbo原始碼解析 簡單原理 與spring融合 dubbo是乙個分布式服務框架，致力於提供高效能和透明化的rpc遠端服務呼叫方案，以及soa服務治理方案 面向服務的體系架構 soa service oriented architecture 各服務是部署在不同的伺服器上,那服務間的呼叫就是要通過...