服務可用性
sentinel的限流、熔斷降級與隔離
保證服務穩定的幾種策略
服務限流的幾種演算法
隔離設計的幾種思路
其他
筆者特別喜歡阿里的中介軟體，緣由很簡單，在於他詳盡的文件說明，無論dubbo也好，還是今天聊的哨兵中介軟體也好，官網裡都很詳細地描述了它們的設計思路。比起閱讀它們的原始碼，我更願意關注設計者將要解決的問題以及圍繞著這個問題給出的答案。
sentinel是阿里的中介軟體團隊研發的面型分布式服務架構的輕量級高可用的流量控制項，其核心目的則是為了保障服務的穩定性。
那麼它以流量控制為切入點，從以下幾個維度提供了技術方案：
降級 熔斷降級
負載保護
由於本文主要圍繞sentinel的限流以及隔離，並不打算針對sentinel的每乙個功能特性一一展開描述，感興趣的童鞋可以自行前往官網學習。
筆者總結了sentinel的流量控制設計的思路，其解決方案包含以下幾方面：
（1）根據什麼指標來判斷需要進行流量控制？
（2）一旦觸發了流量控制所設定的閾值，採取的什麼手段？
（3）流量控制的範圍？
首先來回答第乙個問題：
流量控制主要有兩種統計的型別，一種是統計併發執行緒數，另一種則是統計qps。
併發執行緒數流量的控制，主要還是作用於保護業務執行緒數不被耗盡，這種情況往往發生於下游的應用由於某種原因導致服務不穩定，響應延遲，一旦遇到下游這種情況，上游則很容易因為執行緒無法得到釋放，導致執行緒池crash掉。業內一種解決的方案是通過執行緒池的隔離，比如hystix則是採用這種方式，但是這種方式本身有執行緒切換的額外成本。sentinel給出另一種解決方案，則是做一層簡單的統計，如果執行緒池的使用已經達到了閾值了，此時則直接拒絕。
基於qps的流量控制，針對流量達到閾值後，採用的手段有以下：
（1）直接拒絕
（2）warm up
（3）勻速排隊
直接拒絕無需過多的展開，重點**warm up和勻速排隊。
warm up
預熱/冷啟動方式，這個詞並非sentinel獨有，在很多中介軟體和框架（比如dubbo）都會有這個過程。之所以採用warm up的方式，主要是為了防止系統流量突增，直接將系統沖垮，因此通過緩慢增加流量的方式，將系統做好充分的預熱，防止沖垮系統。那麼為什麼系統會分冷熱呢？
這裡我們經常會遇到以下這種場景，我們通常為了減少開銷，會構造執行緒池或者資料庫連線池，在一開始，初始建立階段，建立連線的成本是十分高的，因此我們在系統剛啟動時，則會有這些額外開銷。
sentinel在這裡採用了令牌桶演算法的方式進行限流。令牌桶演算法由於在下面限流演算法章節會提到，這裡不再贅述。
勻速排隊
勻速排隊採用的則是另一種思路，如果說令牌桶的演算法是控量，那麼對於勻速排隊採用的漏桶演算法則是採用控制速度的方式。勻速排隊使用的場景往往是請求以突刺狀來到，此時對於系統來說，不希望一下子就把系統給擊穿，以均衡穩定的速度對請求進行處理，此時會讓系統更加穩定。
在乙個呼叫關係中，會有兩種角色，呼叫方與被呼叫方。在進行流量控制時，sentinel採用的時針對呼叫關係不同資源的流量控制：
在這裡，彙總了下當前業內主要限流框架的一些常用的演算法，除了漏桶演算法和令牌桶演算法，常用的限流演算法還有以下幾種
（1）計數器演算法
在一定時間範圍內，對請求進行計數，如果該段時間內，請求總數超過閾值，則進行限流操作。
計算器演算法就是乙個很簡單的統計單位時間請求數的演算法。
優點：
缺點:
（2）滑動視窗演算法
如果說計數器演算法是固定時間視窗內對請求進行統計的一種演算法，它會產生上述的臨界值的問題，而滑動視窗演算法則是固定視窗演算法的一種特例，它將計數器演算法的時間視窗進行細分，同時也不是對時間計數器暴力清零，而是一種更加平滑的手段進行對計數器進行更新。
它是否可以解決上述的計數器演算法的缺陷呢？
答案是可行的。我們將1s劃分為四個視窗，此時每乙個視窗為250ms，假設依然有攻擊者企圖在1s的臨界值進行攻擊，他先放出100個請求，之後準備在臨界點過後再放出100個請求，此時他會面臨什麼樣的情況呢？當滑動視窗向前滑動乙個時間塊，此時由於之前的100個請求仍屬於整個滑動視窗以內，此時滑動到下乙個時間塊時，統計到的請求為200個，成功監測到超過閾值。
優點：
缺點：
（3）漏桶演算法(leaky bucket)
漏桶演算法，我的理解其實它是乙個控制流出速度的演算法。
請求以不確定的速度進入到漏桶裡，然後漏桶以一定的速度響應請求，如果請求總量超過了閾值導致了溢位，此時會強行限制請求。這裡其實就是訪問頻率超過介面響應速率一定時間後，就拒絕請求了。
因此可以看到影響漏桶的兩個要素：
優點
缺點
（4）令牌桶演算法
令牌桶假設我們有乙個固定容量的桶，桶裡存放著令牌，令牌會隨著時間不斷地往桶裡填充，直到桶的容量，請求過來時，只有獲取到桶裡的令牌，則允許通過，否則則拒絕通過。
優點
如果說限流是針對外部請求流量的一種干預，是圍繞外部來做的優化策略，那麼熔斷降級則是針對呼叫鏈路中某個資源出現不穩定時，自身對該呼叫進行降級優化的處理。
那麼要做好熔斷降級處理，這裡是存在幾個關鍵問題：
（1）什麼時候觸發熔斷降級機制？什麼指標
（2）降級後採用什麼策略
先來回答第乙個問題，其實無論限流也好，還是熔斷也好，指標無非是以下幾個：
（1）平均響應時間
（2）異常比例
（3）異常數
一旦上述的指標超過閾值，sentinel則對資源的呼叫採用預設的行為，進行自動熔斷，預設丟擲degradexception。
關於隔離的幾種設計思路
熔斷降級常用到的乙個庫是netflix hystrix。我們可以通過對hystrix和sentinel的比對，進一步加深我們對熔斷降級的理解。
hystrix的隔離策略有兩種：執行緒池隔離、訊號量隔離
執行緒池的隔離方式是十分常用的一種方式，也是比較好理解的。在流量大的情況下，由於請求無法及時響應，直接反映出來的就是執行緒池資源被耗盡。那麼我們是否可以針對不同的服務呼叫，劃分級別，然後使用各自不同的執行緒池呢，執行緒池隔離就是基於這種思路。但是執行緒池隔離的代價也是高昂的，上下文切換的成本太高，會對呼叫有較大的影響。
另一種隔離策略為訊號量隔離。本身也不難理解，給定固定個數的訊號量，如果呼叫請求時，先獲取訊號量，如果獲取到，則進行服務的呼叫，否則則進入佇列進行排隊。由於沒有執行緒切換，因此開銷比較小。
sentinel 可以通過併發執行緒數模式的流量控制來提供訊號量隔離的功能。
關於熔斷的設計模型
無論是sentinel還是hystrix，採用的都是熔斷器模式。熔斷器模式不展開說明，如果有興趣的童鞋，可以參考這篇文章：熔斷器模式
sentinel官網
聊聊服務穩定性保障這些事
剖析暴增流量下的限流演算法和最強哨兵sentinel
sentinel 與 hystrix 的對比
如何提公升系統可用性？
相傳魏文王和名醫扁鵲之間曾經發生過這樣一段對話 魏文王 你們兄弟三人，誰是醫術是最好的呢?扁鵲 大哥最好，二哥差些，我是三人中最差的乙個。魏文王 那為什麼你的名氣最大？扁鵲 大哥治病，是治病於病情發作之前，病人尚未發病即已 使得他的醫術沒有得到認可，沒什麼名氣 二哥治病，是治病於病情初起時，二哥藥到...
網頁設計必讀！125個小優化提公升網頁可用性（四）
程式設計驛站 www.cppcns.com 注 本文為 網頁設計你應該知道的125個小技巧 系列文章中的第四篇，由 企業官網設計精選編譯，主要講述了網頁設計中如何做到兼顧不同使用者的知識和技能水平。盡可能兼顧不同使用者的知識和技能水平 使用者可能是新手 專家或介於兩者之間，要根據使用者情況設計介面。...
Istio 1 1 版本發布，效能和可用性提公升
3月20日，istio 1.1版本發布，距離istio 1.0版本發布已經過去了7個月。istio 1.0版本發布的時候，一些主要新功能包括 n n 當前發布的1.1版本投入了很多精力在資料平面和控制平面的效率上。因為 istio 在投入生產中時，使用更大的集群以更高的容量執行更多服務，可能會遇到了...