首次公開！菜鳥彈性調度系統的架構設計

03-12

摘要： 為什麼菜鳥需要彈性調度？在彈性調度出現之前，菜鳥整體資源使用率都處於一個比較低的水平，這是因為： 1.在線應用一般是通過單機性能壓測，並且結合經驗預估業務流量的方式來確定所需容器數量。這種方式很大程度上會受到評估者主觀因素的干擾，在估算業務流量時也通常會保留較大的冗餘。

原文：http://click.aliyun.com/m/43526/

為什麼菜鳥需要彈性調度？

在彈性調度出現之前，菜鳥整體資源使用率都處於一個比較低的水平，這是因為：

1.在線應用一般是通過單機性能壓測，並且結合經驗預估業務流量的方式來確定所需容器數量。這種方式很大程度上會受到評估者主觀因素的干擾，在估算業務流量時也通常會保留較大的冗餘。

2.以往的模式下，一個應用分組的擴縮容操作頻率很低，這使估算業務流量時，需要以每天的峰值流量以及未來一段時間（通常以月為單位）內業務的發展情況來作為評估標準。而一般峰值流量出現時段可能只佔全天時間的一小部分，非峰值時段就出現大量的資源浪費。

從接入的彈性應用分組表現來看，容量評估不準確是非常普遍的現象，而且與實際偏差值非常大。彈性調度作為一種在線動態評估系統運行狀態並且做出擴縮容決策的系統，它讓應用的開發者以及運維人員對資源的關注點，從具象化的容器數轉換成抽象程度更高的「目標」（例如合理的資源使用率目標，服務的合理rt目標），降低了人工評估時不可避免引入的主觀因素影響。另外，結合方舟平台提供的可靠、高效的擴縮容能力，對應用分組的擴縮容操作時效性可以達到分鐘級，從而真正意義上實現資源的「按需使用」。對於菜鳥來說，彈性調度是提升資源使用率最為行之有效的一種方式。

為什麼菜鳥更適合落地彈性調度？

彈性調度雖然能夠帶來較大的使用收益，但並不是適用於所有的公司或組織，而其之所以能夠成功在菜鳥進行落地，主要取決於以下幾點原因：

菜鳥的業務特點決定系統是協調商家，cp，消費者之間的信息流轉，而且物流訂單流轉的長鏈路多交互的特點也決定了信息流大於實操流即可，所以我們的系統面臨導購秒殺型的脈衝峰值菜鳥方舟彈性調度系統場景微乎其微。
菜鳥在2017年年初全面實現容器化並且接入混合雲架構體系後，已經完成了資源管理從「面向機器」到「面嚮應用」的轉變，應用的部署、擴縮容等核心運維流程得到了極大的簡化和提效。方舟平台作為容器資源管控平台，在經歷了2017年618、雙十一等大促活動的考驗後，其穩定性已經得到了充分的驗證，這就為彈性調度的落地創造了充分的技術基礎。
菜鳥的核心應用絕大多數都屬於無狀態的在線計算應用，每天業務壓力峰谷值差距明顯，這就為彈性調度的落地提供了足夠的業務場景基礎。
彈性調度並不是一項獨立的工程，需要很多基礎服務進行協助，並且依賴於統一、規範的系統環境。而菜鳥的應用遵從阿里集團規範，彈性調度可以直接讀取alimonitor、鷹眼、alimetrics等工具提供的監控運維數據，並且核心應用所使用的技術棧基本上得到了收斂，這就位彈性調度的落地提供了充分的環境基礎。

基於如上四點，菜鳥才能以較小的成本快速實現了彈性調度。

與同類產品有什麼區別？

在集團內部已經有不少團隊開發了針對某個業務域的彈性調度產品，而業內部分公有雲服務商也提供了彈性伸縮服務，菜鳥彈性調度所面對的問題以及對應的產品思路上與這些同類產品有什麼區別呢？

首先，菜鳥彈性調度所期望覆蓋的應用範圍是菜鳥所有的無狀態核心應用，這些核心應用所涉及的業務鏈路、邏輯特性、資源傾向性、業務流量特性等都存在非常大的差異性，很難抽象出一種通用的業務模式來描述這些應用。因此，不同於針對某個特定的業務域的彈性調度，菜鳥彈性調度在進行設計時不能進行過多的業務假設，在設計調度演算法和策略模式時必須考慮到足夠的通用性；在配置上需要給予使用者充分的個性化能力以應對不同的業務場景；在系統結構設計時，需要考慮到策略橫向擴展能力，當有新的特殊業務場景出現時，能夠進行快速線性擴展。

其次，在應對複雜場景時，系統越是通用，所帶來的配置選項也就越多，公有雲上的彈性調度服務通常提供非常多的配置參數，正是因為他們希望通過這種「把問題拋給用戶」的方式，來抵消問題的複雜性，讓使用者自己為自身的穩定性和成本負責。這種彈性調度帶來的穩定性風險和成本節約效果完全依賴於用戶本身對於這項技術的了解。與之不同，我們作為菜鳥的基礎技術團隊，我們把自己的角色定義為穩定性和成本問題的解決者，而不是向我們的用戶拋去更多的問題，我們希望提供給菜鳥所有應用owner的不僅僅只是像公有雲上彈性這樣的一種新的資源管理功能，而是替我們的用戶解決降低成本、提升穩定性。因此，在產品設計之初時，我們就希望絕大多數應用分組能夠做到一鍵接入彈性，把絕大多數應用的配置問題在使用者感知之前就進行解決，將策略參數配置納入到我們的核心職責範圍內。而對於那些具有特殊性要求的應用，為其提供輔助性建議，幫助其進行少量的配置即完成彈性能力的引入。

彈性調度應用現狀

截止到目前為止，菜鳥已經基本實現了對容器數量15台以上（接入前）的無狀態應用分組進行彈性接入，接入應用分組的整體全天CPU平均使用率達到20%以上（計算方法為取分組CPU使用率與分組容器數的加權平均值）。每天擴縮容總容器數在3000台以上。在2017年雙十一時，彈性調度作為輔助手段從11月12日0點起對部分應用分組進行縮容，使菜鳥佔用物理CPU核數與包裹數的比例得到顯著下降。

以下圖一展示的是一個應用分組一天當中CPU使用率與容器數的變化曲線對比；圖二展示的是該應用分組某個核心服務同時段流量變化曲線：

菜鳥方舟彈性調度方案介紹

彈性調度的基本模式

如前文所言，方舟的彈性調度希望提供給用戶的不只是一種彈性操作集群資源的能力，而是要對所有用戶的成本和穩定性優化這件事負責。由於目標應用在各方面差異性很大，所涉及的配置項數以千計並且一直處於動態變化狀態，全靠我們人工進行配置管理非常不現實。

由此，方舟彈性調度提出了一種閉環反饋式的模式（如上圖所示）。彈性調度基礎能力基於應用分組運行情況和不同應用分組的策略配置參數，做出擴縮容決策，並通過方舟的容器操作服務調整集群容器數量；應用分組集群受到集群容器數量變化的影響，會產生不同的表現行為（例如擴容時集群平均CPU使用率會發生變化，服務rt會在一定範圍內下降等）；應用分組的表現在以實時數據提供給彈性決策的同時，也會進行歷史數據的離線存儲（Alimonitor/EagleEye等集團標準監控系統都提供了這樣的數據服務）；自動策略配置會周期性獲取這些歷史數據，並依照一定的演算法，對不同的應用分組進行不同的策略配置，從而再次影響到彈性調度策略的決策。

這種模式的優越性在於：

1.具備一定程度的自我進化能力。當應用分組剛剛接入彈性時，其大多數的策略參數都為默認值；而當彈性運行一段時間後，結合自動評估方式，各種參數會得到不斷的修正以達到更好的彈性效果。以服務安全策略為例：服務安全策略在實時決策階段概括起來就是對當前服務rt於服務的sla閾值進行比較，剛剛接入彈性時，服務的sla是基於服務接入彈性前的歷史rt來得到的，一般來說非彈性狀態下服務rt的表現，與彈性狀態下服務rt的表現是有很大的區別的，可能一開始由於服務sla設置得不合理（一般來說是過小），會出現「多擴」的現象，由服務rt違反sla引起的擴容會佔到整體擴容原因的大多數。這種現象會被每天定時執行的分析任務捕捉到，判斷出sla設置得不合理，結合最近幾天的運行狀態，重新計算服務sla，由此提高閾值設置的合理性；

2.以更高的抽象層次來進行海量參數的配置，以解決普遍問題。還是以服務rt的sla閾值為例，當我們把配置視角關注到一個具體服務時，我們可能會糾結於一個服務它所對應的具體業務邏輯是什麼、它涉及的調用鏈路是什麼、上游服務對它的容忍性等等細節問題，那麼這樣一來，面對菜鳥不同應用提供的成千上萬個服務，逐一配置根本不可能做到（註：每天都會服務會上線和下線，服務的業務邏輯也可能發生變化，配置是需要進行經常性更新的，這無疑使人工配置更加變得不現實）。而自動策略配置邏輯以更高的抽象層次來看待各項參數，對於服務rt，基於一個普遍適用的假設：「服務rt在一天當中的絕大多數時間都是處於合理狀態」，並且通過概率分布計算（服務rt真正的分布情況也可以通過歷史數據統計得到），可以得到一個數學意義上的sla閾值（以正態分布為例，求得一段時間內服務的平均rt和rt分布標準差，即能得到在不同概率下應該設置的閾值）。

如上圖的正態分布曲線，我們如果把閾值定為平均rt + 2個標準差，那麼依照概率粗略計算，我們假設一天當中有將近33分鐘服務處於rt過高狀態（1440分鐘 * （1 - 0.9544）/ 2），由此就得到了一個數學上合理的閾值（這部分邏輯只是服務安全策略邏輯的一小部分，具體在後文介紹該策略時具體說明）。這樣一來，對於各式各樣的服務，只要能獲取到它的歷史監控數據，就能自動、快速地得到這個數學上的閾值。

彈性調度的架構體系

這部分就不在此做過分冗餘的解讀了，本文的其他部分或多或少會涉及到。

為什麼採用三層決策的模式？

首先介紹一下方舟彈性調度的三層決策：

1.第一層是策略決策，策略決策層由多個不同的策略組成，並且支持快速擴展。策略之間邏輯完全隔離，每個策略計算完成後都會獨立輸出動作（擴容、縮容、不變）和數量。為了能夠適應不同應用之間的異構，每個應用分組也可以根據實際情況啟動或關閉不同的策略。

2.第二層是聚合決策，聚合決策收集第一層所有策略的決策結果，並依據聚合規則得到一個合併後的<動作，數量>組。這一層的規則十分簡單：當同時存在擴容和縮容決策結果時，以擴容為準，忽視縮容結果；當存在多個擴容結果時，以擴容數量最多的結果作為最終結果；當存在多個縮容結果時，以縮容數量少的結果作為最終結果。

3.第三層是執行決策，這部分決策主要會考慮到一些規則，最終告訴擴縮容服務：要不要擴縮，要擴縮多少個容器，如果是縮容那麼要縮容哪幾個具體容器，如果是擴容那麼具體的容器規格、擴容到的機房等。執行決策進行判斷時需要考慮到的規則非常複雜，這裡簡單羅列一些相對重要的規則：

機房均攤規則；
當前應用分組的擴縮容狀態規則，例如如果本次為擴容：如果正在擴容，當本次擴容目標數量大於正在擴容的目標數量時，取差值再次發起一個擴容，由此實現並行擴容；當本次擴容目標數量小於正在擴容的目標數量時，忽略本次的擴容請求；若正在進行縮容，則立即停止縮容，並根據目標容器數和當前容器數發起擴容。
模式規則：彈性調度目前支持全自動擴縮模式、人工審批模式兩種，如果當前分組為人工審批模式，那麼本次決策會需要管理員進行審批。
最大值最小值保護規則：應用分組可以配置最大值最小值，執行決策會保證由彈性調度發起的擴縮任務，不會使最終容器數超過最大值或小於最小值。

此外，執行決策層對於單個分組來說是強一致的，並且第二層輸出的決策結果，是集群需要達到的目標容器數量，這種設計是前兩層能夠做到完全無狀態且冪等的重要因素。

三層決策器使每一層只需要關注自己本身的決策邏輯，分離了「變與不變」的業務邏輯，對擴縮容的最終確定進行層層驗證，是實現「覆蓋菜鳥大多數應用」目標的基礎。

如何做到計算的無狀態、冪等和高可用？

1.方舟彈性調度深度依賴了ISS，ISS作為一款經歷過大促考驗，並且為菜鳥很多核心業務提供非同步任務調度服務的高可用中間件，在功能、性能和穩定性上都非常可靠。方舟彈性調度對於在線數據的獲取採用了「短頻周期性主動拉取」的模式，通過ISS提供的周期性非同步任務調用功能，為每個應用分組在接入彈性時自動註冊一個獨立的ISS周期任務。ISS在發起任務時，會在目標集群中隨機進行選取，並且對任務執行時的生命周期進行管理，支持任務的重試。此外，ISS的客戶端也提供資源保護能力，當集群中的某個進程壓力過高時會更換目標機進行重試。

2.方舟彈性調度的在線計算數據源自於內嵌式監控系統alimetrics。alimetrics是伴隨web容器的一種嵌入式metrics系統，包含非常豐富的監控項。當需要獲取應用分組的細粒度監控數據時，這種數據查詢、讀取、傳輸壓力是被分攤到每一個目標容器的，而非一個集中式的數據中心，這種設計使得數據源不存在單點，數據源的可靠性和壓力容忍能力相比於依賴一個中心式的數據服務來說，要優越很多。

3.為了過濾毛刺，所有計算都基於或大或小的滑動時間窗口。通過alimetrics獲取較短時間窗口（1小時以內）數據時能擁有非常高的性能，並且對應用的干擾非常小，這樣就降低了計算的重試成本。基於這一能力，彈性調度的計算任務可以在每次執行時重新獲取一個時間窗口內的全部監控數據，而不需要在自身內存中維護一個滑動窗口，這是彈性調度計算無狀態的基礎；

4.彈性調度三層決策器中，第三層與其他兩層部署在不同的集群中。由於無論應用分組狀態如何，第一層和第二層都要進行短頻周期性計算，而只有在需要進行擴縮容時（只佔一天中很小的一部分）才會將任務發往第三層，因此將強一致性的範圍限定在第三層，在保證可靠性的同時，對性能影響最少。而第二層輸出到第三層的決策數量，以「目標容器數」而非「擴縮容數量」的形式給出，這樣一來，即使在同一時刻對於一個應用分組有多個彈性決策任務在執行，向第三層輸出多個決策結果，也不會影響最終的擴縮容行為。

決策策略

方舟彈性調度的決策策略支持快速橫向擴展，目前已經包含多個決策策略，部分策略處於測試驗證狀態，這裡對幾個最為核心，同時也是最早上線運行的策略進行介紹：

資源安全策略

資源安全策略關注的是系統資源使用情況。目前，基於以往的運維經驗以及菜鳥的業務特點，資源安全策略關注CPU、LOAD1和Process Running隊列三個系統參數。當其中有一項以上，在近期時間窗口內的集群平均（為了消除毛刺和流量不均帶來的影響）違反上限閾值時（支持個性化配置），發起擴容。當存在多項違反時，取需要擴容數量最大的一項為當前策略決策結果（數量計算方法在後面給出）。

上圖是一個資源安全策略得到擴容結果時的資源使用情況。

資源優化策略

資源優化策略同樣關注的是系統資源的使用情況，但是它的存在是為了在系統空閑時回收資源。同樣關註上述三個系統參數，當這三項同時低於下限閾值時，發起縮容。注意，由於第二層決策器的存在，當有其他決策器要求擴容時，資源優化策略產生的縮容需求就會被抑制。

上圖是一個資源優化策略得到縮容結果時的資源使用情況。

時間策略

目前的彈性決策模式是後驗的，即在發生閾值違反後，才發起擴容。對於有些業務來說，存在有規律的流量突然上揚，例如一些定時計算任務。自動策略配置基於應用的歷史流量變化情況，當判定流量變化為周期性變化，且變化幅度過大，後驗式彈性無法及時跟上時，會為這個分組生成一個時間策略配置，即在每天的指定時間段內，將集群容器數維持在一個指定數量之上。由於第二層決策器的存在，當其他策略在這個時間段內判斷需要的容器數，大於配置的指定數量，那麼以較大的一項作為結果；而在這段時間內，由於時間策略會持續生成擴容結果（如果數量已經滿足，那麼生成擴容決策，但數量為0），其他的縮容決策結果會被持續抑制。

服務安全策略

服務安全策略是目前最為複雜的一個策略，目前，服務包含消息隊列Consumer、RPC服務、HTTP服務三種。每天有至少一半以上的擴容任務是由服務安全策略發起的。

選擇qps還是rt？

很多的彈性調度系統會選擇服務的qps作為最重要的一個考慮因素，但是我們在經過前期的一系列思考討論後，決定放棄qps而使用rt，主要出於以下幾點原因：

1.qps是一個服務的變數，它的變化受限於使用者的使用情況。你可以判斷對於xx業務，在當前時刻的qps是否合理，但是對系統來說，只要能夠承載，服務成功率和rt在合理範圍內，qps取任何值都是合理的。換句話說，當前總qps可以作為業務健康度判斷依據，但不能作為系統（狹義）健康程度的判斷依據（單機最大可承受qps與之不同，注意區別）。rt和服務成功率才是一個服務最為根本的表現特性。

2.通過當前qps和單機最大可承受qps來得到當前容器數，在資源完全隔離，且每個query使用的資源近乎相等時才成立。而對於菜鳥的應用來說：

很多核心應用是跨業務鏈路的，服務千姿百態。一個數據查詢服務和一個涉及業務操作的服務很可能出現在同一個應用分組上，此時，總qps這個概念變得毫無意義，而獲取不同服務單個請求與資源的關係根本不可能。
目前的容器隔離效果並不是特別完美，在全鏈路壓測時經常出現同物理機容器使用同構資源互相爭搶的現象，這就使線上實際運行環境與單機性能壓測的環境無法做到相同，單機性能壓測數據的參考意義值得懷疑。
服務可能隨時都在變化，而單機性能壓測並不能在每次發生變化時及時跟進，時效性無法保證。

閾值比較與多服務投票

如何為海量服務的rt自動配置閾值已經在前面的例子中已經對此做過介紹，此處不再進行贅述。但是需要注意的是：由於這種閾值設定只是數學上的「合理閾值」，還需要其他手段進行修飾。因此我們又引入一個假設：如果是資源不足引起的rt違反閾值，那麼該分組中所有的服務都會受到影響。這是因為應用分組內服務之間所使用的資源是沒有隔離的，他們使用同一個系統環境（受到影響並不意味著所有服務都會違反閾值，不同的服務所依賴的資源種類並不相同，對資源短缺的耐受能力也不相同）。

因此，我們採用了一種「多服務投票」模式來進行rt判斷。每個服務分別進行獨立的閾值比較，當rt違反閾值的服務佔總服務的比例達到一定程度時，才做出擴容決策，服務安全決策的擴容數量由閾值違反程度（按違反百分比來計算）最高的服務決定。

從實際運行的情況來看，當採用「只要有服務違反閾值就進行擴容」的方式運行時，出現誤擴、多擴的頻率非常高，而引入這種「多服務投票」模式後，誤擴、多擴基本上被消除了（實際上人工判斷一個擴容是否為誤擴、多擴時也常常採用這種模式，發現多個服務的rt同時飆高時，則認為擴容合理）。此外，一個應用分組所提供的服務越多，這種模式運行的效果越好。

下游分析

並不是所有的rt違反閾值情況都需要擴容，如果是所依賴的中間件或下游服務導致的rt升高，擴容並不能解決問題，甚至還有可能造成更壞的影響（例如db線程池滿）。因此，服務安全策略在進行計算時，如果發現一個服務違反了它的閾值，會先查詢它的下游依賴服務、中間件調用rt是否違反各自的sla，只有在服務自身違反閾值，但下游服務和中間件沒有違反閾值時，才會參與擴容投票。離線任務基於歷史數據計算服務的sla時，同時也會計算它的依賴服務與中間件的閾值，其中鏈路結構數據來自於鷹眼的離線數據。

一些其他的專項問題

如何處理毛刺？

彈性調度需要保證擴容足夠及時，但又要對系統的毛刺有足夠的耐受能力，否則會造成誤擴、誤縮。毛刺在實際環境中是普遍現象，不僅流量不均、網路抖動等環境問題會導致毛刺的發生，監控統計系統潛在的異常和bug也有可能會誘發毛刺。

為此，方舟彈性調度在進行任何計算時，都會引入時間窗口數據作為計算源頭，而每塊時間的數據內，包含的是一個集群所有容器的數據：

計算時，對於每個所需的監控項，會去掉時間窗口內的最大值和最小值，然後求取平均，以此來抹去毛刺帶來的影響。另外，時間窗口的大小對於去毛刺以及及時性也會有很大的影響。目前，方舟彈性調度中存在5分鐘和10分鐘兩種不同規格的時間窗口。對於可能會導致擴容的策略來說，選取較小的時間窗口，而對於可能會導致縮容的策略來說，選取較大的時間窗口（我們希望擴容相對於縮容來說，更加激進）。

如何計算擴容和縮容數量？

在確定了是否要擴縮後，第二步便是確定擴縮容數量。首先介紹縮容，由於縮容速度相對於擴容較快，且縮容慢不會影響穩定性，所以方舟彈性調度的縮容採用一種「小步快跑」的方式，只要決定縮容，那麼固定縮容的容器數量為集群當前容器數量的10%。

擴容數量的判斷相對於縮容來說要複雜得多，我們這裡以最為常見的閾值比較類策略的數量決策為例。首先，定義一個大的原則：每次擴容數量最大不得超過集群當前容器數的50%，在這個範圍內，對閾值違反的程度越高，擴容的容器數量越多。因此我們在這裡引入sigmoid函數，通過一定的轉換使其計算結果在0~0.5之間，將閾值違反程度百分比作為入參代入sigmoid函數（當然，會進行一些參數的調整），從而得到擴容的百分比。

sigmoid函數是一個在0~1之間變化的曲線，常用於數據的歸一化計算。對於f(x)=sigmoid(x) - 0.5來說，當x > 0時，該函數的取值在0 ~ 0.5之間。

對於像CPU使用率這種數據來說，有一個區別是該項的取值最大不會超過100，存在一個上限；而諸如服務rt這類的數據則不存在上限。那麼顯然，完全用同一個公式會導致CPU觸發的擴容數量小於服務rt觸發的擴容數量。此時，只需要設置一個目標，例如我們希望當CPU使用率達到80%，即違反程度為（80% - 閾值）/ 閾值時，擴容比例接近50%，基於這個目標對f(x)進行逆運算就能得到係數a，使進行針對CPU的擴容數量計算時代入這個係數a，就能得到所期望的結果。

如何實現鏈路容量的彈性？

只要鏈路上所有應用分組都接入了彈性，那麼已經可以認為此鏈路的容量也具備彈性。

如何應對大促的場景？

方舟通過「容器計劃」和彈性調度進行配合的方式，為大促提供了完整的資源管理解決方案。容器計劃可以讓各個應用Owner在指定的大促時間段內（包括壓測和大促時段）提出容量申請。當接入彈性的應用分組在進入大促時間段內，彈性調度的擴縮容模式會立即轉變成人工確認模式，並且將會把集群容器數擴容到容器計劃所申請的數量。當大促時間段結束時，非彈性的應用分組將會直接縮容回原有容器數量；而彈性應用分組則會通過彈性策略進行緩慢資源回收。

在大促時間段內，儘管彈性調度沒有自動進行擴縮容，但是擴縮容決策依然在進行中。彈性調度會持續向管理員或大促決策小組發出容器擴縮容建議，一方面在流量超出預期、資源不足時及時發出警告並且提供建議的擴容數量，也能協助管理員對一些資源進行及時的回收，幫助進行縮容決策。

彈性調度如何推動業務本身的演進？

彈性調度推動業務本身的演進是我們一直以來的目標，對我們來說，只有這樣才可以形成真正意義上的業務閉環。這種推動主要是採用數據分析的方式進行，目前彈性調度會產出以下幾種數據：

rt|資源相關性，反映了服務rt和CPU等系統資源使用率的相關程度，相關程度越高，則服務使用情況對資源越敏感，使用彈性調度的收益也越明顯；
中間件穩定性，反映了由中間件rt超出閾值引起的服務rt違反。由於服務rt的升高直接影響到了服務的可用性，因此當這項數據過高時，會建議檢查中間件的使用情況，進行優化；
下游穩定性，反映了由下游服務rt超出閾值引起的服務rt違反。當這項數據過高時，會建議當前應用推動下游服務穩定性升級，或者推動下游彈性化；
應用啟動時效，一個擴容任務直到應用實例啟動完成，能夠對外正常服務才認為成功，應用啟動時間越短，那麼彈性調度對其擴容也就越及時，當出現流量洪峰時也能最快速度進行保護；
限流配置合理性。我們發現不少接入的應用在服務rt都處於正常範圍，且系統資源使用率極低的情況下居然觸發了自身所配置的限流值，對於這種情況，會建議應用進行合理的業務分析和測試來調整限流值配置。

本文作者：長陵

本文來自雲棲社區合作夥伴「阿里技術」

更多技術乾貨敬請關注云棲社區知乎機構號：阿里云云棲社區 - 知乎