在典型的一天，峰值請求率約為日常平均值的3倍。在一年中的某些時候（例如中國農曆新年期間），峰值工作負載可以上公升到日常平均值的10倍。
傳統的過載控制機制是為具有少量服務元件、相對狹窄的「前門」和普通依賴關係的系統而設計的。
特定請求的服務呼叫圖可能依賴於特定於請求的資料和服務引數，即使對於相同型別的請求也是如此。因此，當特定服務出現過載時，很難確定應該限制哪些型別的請求以緩解這種情況。
過多的請求中止浪費了計算資源，並由於高延遲而影響了使用者體驗。
由於服務dag極其複雜，而且在不斷演化，導致有效的跨服務協調的維護成本和系統開銷過高。
由於乙個服務可能會向它所依賴的服務發出多個請求，並且還可能向多個後端服務發出請求，因此我們必須特別注意過載控制。作者發明了乙個術語，叫作後續過載，用於描述呼叫多個過載服務或多次呼叫單個過載服務的情況。
後續過載給有效的過載控制帶來了挑戰。當服務過載時隨機執行減載可以讓系統維持飽和的吞吐量。但後續過載可能會超預期大大降低系統吞吐量…試想乙個簡單的場景，其中服務a兩次呼叫服務b，如果b開始拒絕一半傳入的請求，那麼a的成功概率就降到了0.25。
我們需要完成兩個基本的任務：過載檢測，並在檢測到過載之後決定如何處理它。
對於過載檢測，dagor使用了待處理佇列中的請求的平均等待時間（即排隊時間）。排隊時間可以抵消呼叫圖中較低的延遲所帶來的影響（與請求處理時間相比）。即使本地伺服器本身沒有過載，請求處理時間也會增加。dagor使用基於視窗的監控，每個視窗是一秒鐘，或者2000個請求，以先達到者為準。
一旦檢測到過載，我們就必須決定如何處理它，或者直接丟棄某些請求。我們發現，並非所有的請求都是平等的：
為了以服務無關的方式處理這個問題，每個請求在首次進入系統時都會被賦予業務優先順序。這個優先順序會隨所有下游請求一起流動。使用者請求的業務優先順序由請求的操作型別來決定。雖然有數百個入口點，但只有幾十個具有顯式優先順序，其他入口點具有預設（較低）優先順序。優先順序保留在複製的雜湊表中。
當過載控制被設定為業務優先順序n時，將刪除所有級別為n + 1的請求。這對於混合工作負載來說非常有效，但是假設我們有大量的付款請求，所有這些請求都具有相同的優先順序（例如p）。系統將出現過載，這個時候將過載閾值降至p-1。一旦過載消失，過載閾值再次增加到p，於是我們又處於過載狀態。要在相同優先順序的請求發生過載時避免這種翻轉，我們需要比業務優先順序更細粒度的控制級別。
入口服務通過以使用者id作為引數的雜湊函式來動態生成使用者優先順序。每個入口服務每小時更改其雜湊函式。因此，來自同一使用者的請求很可能在一小時內被分配了相同的使用者優先順序，但在幾小時內被分配了不同的使用者優先順序。這提供了一種公平性，同時還在相對長的時間段內為個人使用者提供一致的體驗。它還有助於解決後續過載問題，因為具有高優先順序的使用者請求更有可能在整個呼叫圖中得到處理。
通過組合業務優先順序和使用者優先順序，可以為每個業務優先順序提供128個使用者優先順序准入級別。
由於每個業務優先順序的准入級別具有128個使用者優先順序，因此復合准入級別數量可以達到數萬。復合准入級別的調整是按照使用者優先順序的顆粒進行的。這裡有個有趣的問題，為什麼使用會話id代替使用者id就不起作用：在遇到糟糕的服務時，這樣會導致使用者登入登出，那麼在過載問題之上又會多出來乙個使用者登入問題！
dagor為每個伺服器維護乙個請求的直方圖，用於跟蹤超過准入優先順序的請求的大致分布情況。當在視窗期間檢測到過載時，dagor移動到第乙個桶，將使預期負載減少5％。如果沒有發生過載，它會移動到第乙個桶，將使預期負載增加1％。
伺服器將准入優先順序嵌入到傳送給上游伺服器的每個響應訊息中。通過這種方式，上游伺服器獲知下游服務的當前准入控制設定，可以在傳送請求之前對請求執行本地准入控制。
dagor過載控制系統的端到端檢視如下所示：
與codel和seda相比，在進行一次後續呼叫時，dagor的請求成功率提高了50％，隨後出現過載。後續請求數量越多，好處就越大：
最後，在公平性方面，codel在壓力下更傾向於使用較小的扇出服務，而dagor在各種請求中表現出大致相同的成功率。
即使你不使用dagor，作者還是為你總結了三個寶貴的經驗教訓：
英文原文：
DAGOR 微信微服務過載控制系統
在典型的一天，峰值請求率約為日常平均值的3倍。在一年中的某些時候 例如中國農曆新年期間 峰值工作負載可以上公升到日常平均值的10倍。傳統的過載控制機制是為具有少量服務元件 相對狹窄的 前門 和普通依賴關係的系統而設計的。特定請求的服務呼叫圖可能依賴於特定於請求的資料和服務引數，即使對於相同型別的請求...
微服務的微
微服務已經流行了好幾年了，現在已經是行業普遍的認識，技術方向的元件化也已經很成熟，dubbo，eurake，springboot，springcloud等等。大家也都張嘴就來服務註冊發現，api閘道器，服務熔斷，好像不了解微服務，不說上幾句就是技術不到位，就不能通過技術面試。大家都在說，都集中在技術...
微服務流控防護場景與應對措施
前言 微服務成了網際網路架構的標配模式，對微服務之間的呼叫的流量治理和管控就尤為重要。哪些場景需要流量防控，針對這些場景又有哪些應對措施。有沒有乙個通用的措施來降低風險呢？這篇文章咱就聊聊這個。一 服務被過載呼叫 當服務d的某個介面服務被上游服務過載呼叫時，如果不對服務d加入保護，可能整體將服務d整...