當前服務器配置能承受多大的QPS？如何評估？

LinkedIn的基礎設施上運行著數百個應用，它們為4.67億的LinkedIn會員提供服務。在發布新功能、規劃流量增長規模和分析數據中心失效備援方案的過程中，我們經常會遇到以下幾個問題：

目前的服務配置最大可以承擔多大的QPS（每秒查詢數）？

這些服務器能夠處理比當前峰值高出50%的流量嗎？

從基礎設施來看，服務潛在的容量瓶頸是什么？

作為LinkedIn的性能團隊工程師，我們的工作就是要在短時間內為上述的問題尋找準確的答案。

不過，因為服務的增長過于迅速，在對服務的容量極限進行評估時，我們面臨著巨大的挑戰。這些挑戰來自于持續變化的流量模式、不均衡的基礎設施特征，以及持續變化的瓶頸。為了能夠準確地對服務容量極限進行評估，并有效地識別出容量瓶頸，我們的解決方案需要具備如下特點。

利用生產環境來突破實驗室的局限

使用真實的流量作為負載

最小化對用戶體驗造成的影響

低運營成本和開銷

自動伸縮

我們的解決方案：Redliner

我們使用生產環境的真實流量，通過Redliner實現自動化的容量評估和準確的余量分析。Redliner在目標服務上運行壓力測試，逐步增加流量，直到服務無法處理更多的流量為止，以此來評估服務的吞吐量。

Redliner自動從生產環境引入流量，并確保對用戶只有很小的影響。在設計Redliner時，我們遵循了兩個原則：影響最小化和完全自動化。

影響最小化

在進行流量重定向時，最主要的問題是如何避免對站點和用戶造成影響。Redliner使用以下的策略來緩解對生產環境性能造成的影響。首先，通過增量的方式將流量導向redline實例。其次，Redliner對服務進行實時的監控，并根據實際情況來分發流量。Redliner捕捉實時的性能指標，并基于EKG健康評估規則（見圖1和圖2）的計算結果來確定服務的健康狀況。另外，在進行redline實例的測試過程中，Redliner也會評估流量測試對上游和下游服務所產生的影響。

圖1 Redliner內部度量指標規則示例

圖2  Redliner系統度量指標規則示例

完全自動化

為了克服手動測試的缺點（缺乏一致性、高昂的運營成本，等等），我們需要一個完全自動化的方式來運行測試、確定吞吐容量、檢測系統性能衰退告警，并在出現問題時停止測試或回滾。我們借助LinkedIn的技術平臺保證Redliner自動化的健壯性和伸縮性。Redliner能夠運行調度測試，通過EKG檢測性能狀態，還能利用A/B測試平臺XLNT來動態地調整導向目標服務的流量。在經過幾輪的迭代之后，Redliner就可以確定單個服務能夠處理的最大QPS。一般整個過程需要不到一個小時的時間。Redliner會生成測試報告，報告里包含了QPS和延遲趨勢走向以及資源瓶頸信息。如果某個服務出現過載或者尚有余量，Redliner會向相關人員發送郵件，郵件里會為他們提供具體的建議。

Redliner生態系統

圖3是Redliner的架構圖，包含導流組件和容量評估組件。主要組件如下：導流層（代理/負載均衡器）、服務健康狀態分析器和服務度量指標收集器。

圖3  Redliner和它的依賴組件

導流層（代理/負載均衡器）

Redliner目前只支持無狀態的服務。也就是說，發送給這些服務的請求可以被路由到數據中心SUT（Service Under Test）的任意服務實例上，不涉及粘性會話（sticky session）。負載均衡機制負責控制流量負載，從而能夠實現動態導流。

導流層是Redliner實現動態調整流量的關鍵組件。Redliner確定目標服務的流量等級，并通過LiX（LinkedIn實驗服務）將其轉換成代理和負載均衡器的配置變更。LinkedIn使用LiX（以及A/B測試）作為默認的流量探測工具，它提供了更為可控和安全的導流。通過改變代理和負載均衡器的配置，Redliner就可以自由地控制從客戶端發送給目標服務的流量。

度量指標收集器

容量評估和余量分析通過分析性能度量指標來確定SUT是否已經達到了容量極限。LinkedIn所有的服務都會向Autometrics發送度量指標，Autometrics是一個基于推送的實時度量指標收集系統。Autometrics會收集實時的系統數據和服務數據，比如QPS、請求延遲、錯誤率，以及CPU和內存的使用情況。

 服務健康分析器

EKG是Redliner的服務健康檢測工具，它通過分析上述的性能指標來確定服務的整體健康情況。Redliner向EKG查詢正常流量負載性能與當前流量負載性能之間的比較結果，也會通過查詢服務的健康檢測結果來決定后續的導流操作。

Redliner實戰

Redliner通過在目標服務上增量運行不同的流量壓力測試來確定服務的容量極限。在對目標服務的流量負載做出變動后，Redliner等待EKG返回健康檢測結果。如果健康檢測失敗，Redliner會降低流量等級，否則，它會增加流量，給服務施加更大的壓力。Redliner就是通過這樣的反饋閉環來確定服務的流量等級的。在得到一個令人信服的紅線（redline）數字之前，這個迭代過程會一直進行，而這個數字就是服務能夠處理的最高吞吐容量。

圖4展示了Redliner一個測試案例的細節。SUT設定了一個紅線數字（紅色虛線），Redliner觸發快速坡道（ramp）算法，逐步增加流量負載，直至達到目標QPS。這個過程改進了測試效率，同時降低了測試之間的時間間隔。之后，Redliner一直保持流量的逐步增加，直到目標服務的CPU使用率和調用延遲出現顯著的增長，這個時候的健康檢測會返回異常。Redliner隨之降低目標服務的流量負載。在經過幾輪的迭代調整之后，Redliner就得到了目標服務的紅線數字。

圖4 Redliner測試結果概要：QPS和延遲vs時間

使用案例

Redliner在LinkedIn內部被用于多種用途，包括下面的幾種。

降低數據中心的成本

一般來說，服務所需要的資源需要根據未來的增長規模來調配。不過受多種因素的影響，比如功能棄用和不準確的增長規模預測，分配給服務的資源可能不夠用，所以資源分配是一件很復雜的工作。通過指定紅線區間，我們可以識別出過度分配資源的服務，并將資源收回，用作其他用途。舉個例子，當100%的流量被導向目標服務，健康檢測沒有返回錯誤，Redliner測試就隨之結束。根據這個測試結果，工程師們可以減少生產環境的服務實例，或者利用LPS對資源進行更有效的分配。圖5展示了使用Redliner對生產環境的服務器資源進行回收的例子。

圖5 服務資源減持趨勢示例

前瞻性容量規劃

生產環境的容量問題總是很難緩解。通過運行Redliner的自動化測試，服務所有者和運維團隊會收到潛在的容量告警。在Redliner識別出資源競爭問題（CPU、內存、網絡、線程池）之后，做出緩解計劃就會變得相對容易。另外，通過分析容量歷史和可視化紅線QPS趨勢，工程師們可以建立評估模型，并作出適當的預測，提前為流量增長規劃好資源。

吞吐量衰退檢測

工程師們可以使用Redliner來檢測應用程序的衰退情況，還可以通過自動化測試識別出新的資源瓶頸。Redliner支持同時運行canary環境的測試和生產環境的測試。工程師們可以在不同的服務實例上運行相同等級的流量負載：一個服務實例包含了新的配置、屬性變更或者代碼變更，另一個服務實例是當前的生產環境版本。負載測試結果可以作為部署的參考，可以避免部署包含了可能導致性能衰退的代碼。

原文來自:聊聊架構

免責聲明：以上內容為本網站轉自其它媒體，相關信息僅為傳遞更多信息之目的，不代表本網觀點，亦不代表本網站贊同其觀點或證實其內容的真實性。