1. 背景
以滴滴內部某業務爲例，從BI監控、流量晚的流量高峯、夜間的流量低谷。但把週期拉長，可以看到業務單量及服務流量的增加趨勢。
對應該服務的資源使用，比如CPU Idle，長期看則有一定的下降趨勢。
基於此，我們能否從中找到規律，回答幾個重要的問題：
- 隨着業務單量增長，該服務的流量也會增加，峯值會是多少？
- 隨着該服務的流量增加，該服務消耗更多的資源，容量上限是多少？
- 以及終極問題：隨着業務單量增長，該服務是否需要擴容，擴容多少？
2. 容量預估的思路
懵懂中有這樣的猜想，服務的流量應該取決於業務單量。所以換個角度考慮，把上面三幅圖的橫座標改爲業務單量，縱座標改爲服務流量。如果關係成立，預測流量增長自然不難。
不出意外，資源使用率（如CPU Idle）應該取決於服務流量。如果關係成立，評估容量上限也會迎刃而解。
想法是否成立，我們快速驗證一下，採集了5個線上服務，生成服務流量與業務單量的關係圖，結果顯示，有3個服務存在較強的關係：
接下來是資源使用率與服務流量，採集了多個資源使用率指標，比如內存、CPU Idle、磁盤IO等，結果顯示，應用類服務的CPU Idle與流量存在較強的關係：
3. 容量預估的方案
評估容量上限
流量高峯時，如果某個服務的主要資源指標下降到一定程度，我們會覺得其容量到了上限。前面分析驗證過，應用類的服務大多數是CPU類型，CPU使用率或者CPU Idle是主要的資源指標。有一定的理由相信，如果CPU Idle下降到基線標準，我們可以說該服務的容量達到了上限。
但基線標準如何定義？在達到特定的容量時，該服務的錯誤率有明顯提升、或者時延SLA不達標、或者突然Crash，這就是一個經過驗證、令人信服的基線值。
在沒有驗證的基線之前，我們可以依賴歷史經驗，比如這裏取CPU Idle 40%作爲基線值。
從圖中可以看出，服務的CPU Idle與流量有較強的相關性，給出性能基線後，很容易評估其容量上限。
預測服務流量
很多時候業務上對增長有較明確的預期，比如半年之內單量增加50%，即使一些促銷的運營類活動，也應該對業務增長有粗略的估算，這樣底層的IT系統可以更好應對。
這些業務增長的預期，會直接轉化爲內部各服務的流量，前面已經分析和驗證過二者的關係，因此服務的流量也是可以預測的。
下面的左圖非常典型，流量與單量強相關。右圖則不然，呈現出兩個不同的階段。其實這種情況不難理解，某些服務的流量不只受單量影響，還受制於司機數量，即使單量增加，但司機不夠，很多訂單分不出去，相關服務的流量必然不會一直增長。所以需要綜合考慮服務流量與業務單量、司機在線數等多個因素的關係。
算法說明
持續採集線上數據，經過預處理、格式轉換，可以用來做預測。多次訓練和驗證對比，並使用節假日時的高峯流量二次驗證，爲不同的服務選擇不同的算法。
最後，由於關係圖上的點有一定的離散度，引入bootstrap 95%置信區間算法，給出的預測結果是一個範圍，而非具體的一個數值。
4. 預測結果的準確度
不難理解，大家會有很多疑問：
- 預測準不準，怎麼證明？
- 按CPU Idle 40%進行計算，會不會出現CPU Idle 60%或者50%時服務突然Crash？
當某個服務的流量繼續增加，CPU Idle持續降低，我們與哨兵壓測合作，讓該服務單臺機器的流量增加，並採集資源類數據，如下圖所示。肉眼看起來，基本符合預測的關係，並進行了量化計算，預測的準確度大概是89%。
至於是否會Crash，起碼從哨兵壓測CPU Idle降到40%的情況下，這兩個模塊未發生突然Crash。這當然避免不了流量繼續增加是否會Crash，但我們在選擇性能基線的時候可以更保守一些。容量的預估只需要採集相關的業務指標、流量數據、資源數據，幾乎不需要服務側做任何改動，僅此接入的成本較低。
5. 案例分析
容量的預估只需要採集相關的業務指標、流量數據、資源數據，幾乎不需要服務側做任何改動，僅此接入的成本較低。
案例一
以某服務爲例，集羣共有10臺機器，當前的峯值流量1000QPS（非線上實際數值，僅爲示例用途，下同），兩個主要的關係圖如下：
經過計算，該服務的結果如下：
- 若不擴容，該服務的容量上限預測結果爲：【1500-1700】
- 單量增加30%、司機增加10%時，該服務的流量峯值是：【2000-2200】
- 按悲觀估算，容量取下限1500，峯值流量取上限2200，則該服務需要擴容4~5臺
案例二
以另一個服務爲例，集羣共5個容器，當前的峯值流量是250QPS。
經過計算，該服務的結果如下：
- 若不擴容，該服務的容量上限預測結果爲：【1100-1200】
- 單量增加30%、司機增加10%時，該服務的流量峯值是：【450-500】
- 按悲觀估算，容量取下限1100，峯值流量取上限500，則該服務需要縮容2臺
案例三
從業務角度，可以看到各核心服務的容量上限、流量增長趨勢，以及建議的擴容結果：
6. 侷限性說明
線上業務面臨各種各樣的穩定性挑戰，這種常規場景下的容量預估方法，當然也有其侷限性：
性能基線如何選擇
使用CPU Idle作爲基線指標，源於本文對少量數據集的驗證結果，大部分應用類服務是CPU資源型。
使用CPU Idle 40%作爲基線值，則是源於經驗。在40%之前服務是否存在性能拐點，是否會發生crash，則需要結合全鏈路壓測、哨兵壓測等其他機制驗證。
對下游時延增加等性能抖動的容錯
一旦下游服務或基礎組件發生性能抖動，比如時延增加、錯誤率增加，對很多服務會產生致命的影響，甚至引發雪崩。
服務可以容錯多大的性能抖動，可以結合防火等手段進一步驗證。因此本文的容量預估結果，更多是對服務容量的一個參考。
作者介紹：
張曉慶
滴滴 | 高級算法專家
本文轉載自公衆號滴滴技術（ID：didi_tech）。
原文鏈接：