高德全鏈路壓測平臺TestPG的架構與實踐

導讀

2018年十一當天，高德DAU突破一個億，不斷增加的日活帶來喜悅的同時，也給支撐高德業務的技術人帶來了挑戰。如何保障系統的穩定性，如何保證系統能持續的爲用戶提供可靠的服務？是全部高德技術人面臨的問題，也是須要你們一塊兒解決的問題。

高德業務規模

支撐一億DAU的高德服務是什麼體量？可能每一個人的答案都不相同，這裏從基礎設施的角度給你們作個簡單的介紹，咱們有數千個線上應用，分別部署在全國各地多個機房中的數萬臺機器上。

這張圖是高德業務核心鏈路的架構，從圖中能夠看出高德業務具備至關高的複雜性。固然，真實系統遠遠要比圖表示的複雜，若是用這張圖來表明高德總體業務形態，無異於管中窺豹，太過於片面。

對於如此大規模，高複雜度的系統，如何保障系統的穩定性，是高德技術人長期面臨和解決的問題。

保障穩定性的手段

如何保障系統穩定性是幾乎全部互聯網企業都須要面對的問題。一般來說，有五種手段來從理論上保障系統的穩定性，分別是：

• 容量規劃：根據以往業務的流量，估算出將來（一般是即未來臨的大促，節假日）的流量。以總體流量爲基礎，估算出每一個子系統須要知足的容量大小。而後根據子系統的容量來計算出須要的資源數量，對系統進行適當的擴容。計算方式能夠簡單的表示爲以下公式：

<p style="text-align:center">機器數量 = 預估容量 / 單機能力 + Buffer （必定數量的冗餘）</p>

• 流量控制：系統須要防止流量超過設計的容量，對超出設計的流量進行限流。各業務也須要對超出子系統服務能力的流量進行限流，對超負荷的服務進行降級。
• 災備：一旦系統發生災難性故障，須要將流量切換到容災機房，避免對大量用戶形成損失。
• 監控：對服務進行全方面的監控，實時掌控系統的狀態，對系統中出現的問題及時預警，作到早發現，早治理。
• 預案演練：對系統可能面臨的問題要進行全面的預演，結合斷網，斷電等等災難模擬的手段來檢驗系統在災難面前的表現。

有了穩定性保障的五大法寶，咱們是否就能夠高枕無憂了呢？答案是使人遺憾的，這裏有兩個殘酷的現實例子，告誡咱們不要太樂觀。

多年前的某年春節前夕，咱們對高德核心鏈路進行了壓測，壓測設計的流量要高於預估的春節流量，系統在當時表現良好，各項指標都知足要求。但是春節期間，服務因某種緣由發出告警，而此刻線上流量的水位並無超過咱們的預期。

還有一次在某年五一期間，該服務再次發出預警，並且和春節的那次預警的緣由不同。

咱們的穩定性保障手段是基於對於系統的認知來實現的，而認知每每是真實世界在頭腦中的映射，是一種模型，或是真實系統的快照。系統的真實狀態每每和咱們觀測到的不太一致，基於觀測到的模型對系統進行的測量也每每會不夠準確，對於系統，咱們要保持敬畏。對系統進行不厭其煩的模擬，無限的接近真實系統的狀態，是永恆不變的追求。

上述穩定性保障的工做，只能在理論上保證系統的抗壓能力，可是不能肯定在真實流量到來的時候，系統的表現如何！

所以，咱們須要演習，須要讓真實的流量提早到來！

全鏈路壓測

如何讓真實的流量提早到來？咱們須要藉助全鏈路壓測，那麼什麼是全鏈路壓測呢？

個人理解是：把全鏈路壓測拆分爲兩個部分來看。一是全鏈路，一是壓測，分別來理解：

• 全鏈路：分爲兩層意思；一是自頂向下，一個請求在系統中通過的完整路徑。二是一系列動做的集合，好比從用戶登陸，到瀏覽商品，到選擇商品，到加入購物車，到支付等等這整個環節。對於高德業務而言，咱們關注的是第一種全鏈路。
• 壓測：經過對海量用戶行爲模擬的方式，對系統逐步施壓，用於檢驗系統的穩定性。

集團的戰友們把全鏈路壓測比做 "終極武器"，很是的形象。既然是 "終極武器"，那就須要有足夠的威懾力，對於高德來講，目標是：提供真實的流量，在真實的環境中來檢驗系統的穩定性。

這裏麪包含三個關鍵點：

• 真實的流量：流量的量級和特徵貼近真實的世界。
• 真實的環境：直接在線上環境進行。
• 提早進行：在流量洪峯到來以前。

作到這三點，才能稱得上是一次真正意義上的演習，才能夠叫作全鏈路壓測。

高德全鏈路壓測面臨的挑戰

高德全鏈路壓測面臨衆多方面的挑戰，除了分佈式系統固有的挑戰外，高德全鏈路壓測還面臨着業務特殊性的挑戰。

分佈式系統的特性

• 不肯定性

咱們認爲的流量有序的，而真實的流量倒是隨機的，不肯定的。

• 抖動性

在理論的世界裏面，吞吐量是請求量的函數，能夠表示爲以下的公式：

<p style="text-align:center">Throughput=f(load)</p>

若是沒有其餘因子的干擾，在系統達到飽和以前，吞吐量和請求量的關係應該是線性的。而現實世界裏面，這種理論模型幾乎是不可能出現的。爲何？由於抖動。爲何會出現抖動？由於網絡，磁盤等等的不肯定性。

• 排隊系統的特性

咱們的業務能夠簡單的抽象成爲一個排隊系統，請求從左邊隨機的進入系統，等待被處理，處理完成以後，從右邊離開隊列。在系統未達到飽和狀態時，系統能夠很好的處理用戶的請求，而一旦隊列接近飽和，那麼隊列的長度可能會顯著的增長，並且請求的平均響應時間也會出現增長，甚至會出現部分請求超時的狀況。對於一個理論上能處理 1000q/s的系統，在不一樣流量的狀況下，可能的狀態以下（特定系統的測量結果）：

從圖中能夠看出：

1. 請求達到率增長2倍，隊列的長度會增長約60倍。
2. 當系統接近飽和時，請求端極小的變化將會對系統形成很大的影響。請求達到率從0.95 ~ 0.99，隊列的長度將增長40%。

排隊系統的特徵是：系統會在接近飽和時出現擁堵，擁堵會致使服務的時間變長，而這反過來又會加劇擁堵的程度。隨着狀況的惡化，系統的資源（cpu，mem）最終會被耗盡。擁堵和服務質量降低表現爲正相關性，這種特性會隨着時間急劇的惡化，最終拖垮系統，出現故障。

高德業務特色

出行業務有其特有的特殊性，會受到諸多因素的影響。具體到高德業務而言，系統的行爲會受到區域，地形，路況，路網密度，季節，天氣，政府活動等等因素的影響。

以駕車導航爲例，導航系統會受到以下因素的影響：

• 區域：不一樣的區域經濟發展水平不一致，人們選擇出行的交通工具也會不同，經濟發達地區的人們汽車擁有率會更高，使用汽車出行的頻率也會更高。
• 地形：山區，城市繁華地區會因gps信號遮擋致使定位不許確，可能被系統認爲偏航，從而引起路徑從新規劃。
• 路況：事故，擁堵，施工，限行，管制 這些路況都對導航服務形成影響。
• 路網密度：導航算法所要求的計算資源和路網的密度有很強的關聯，路網越密，路徑規劃所消耗的cpu資源，內存資源就會越大，同時計算的時間也會越長。
• 距離：路徑規劃的距離越長，導航算法對計算資源的要求就越高。
• 季節&天氣：人們的出行行爲和季節也會呈現相關性，如 五一，端午 人們可能集中前往景區旅遊。十一，春節 人們可能會集中返鄉。這樣在導航行爲上就會出現導航距離分佈不一樣的狀況，不一樣的導航距離對服務的要求會不同，越長距離的導航對服務資源的要求越高。
• 政府活動：交通管制，修路，限行等等。

對於高德而言不能單純的經過放大流量來對系統進行壓測，在流量構造階段咱們須要考慮到流量的特徵，考慮到全部影響服務行爲的因素。

高德全鏈路壓測平臺的自建原由

身在阿里，提及全鏈路壓測，首先想到的確定是大名鼎鼎的Amazon平臺，Amazon 誕生於2013年，自2013年起，Amazon一直做爲淘寶、天貓穩定性保障體系中神通常的存在。通過多年的發展和演進，Amazon平臺已經日臻穩定和成熟，在施壓能力，鏈路治理，數據構造，用戶模擬方面已經作到極致。

因此，在落地高德全鏈路壓測的時候，首先考慮的就是藉助Amazon平臺。通過充分的調研和部分項目的試用，咱們發現Amazon平臺並不能知足咱們的要求。

Amazon平臺誕生於淘寶，做爲淘寶，天貓穩定性保障體系中重要的成員。Amazon 追求的是超高的施壓能力和極強的平臺穩定性。另外，淘寶的雙11，雙12全鏈路壓測是多團隊合做的項目，一次全鏈路壓測可能須要數百人的參與，對於這種超大規模的全鏈路壓測項目，成敗的關鍵在於團隊的合做。平臺須要搞定的是人沒法搞定的事情，對於Amazon來說，要作的就是把事情作到極致。

高德的全鏈路壓測流量的要求遠遠不及淘寶的全鏈路壓測，而且一般全鏈路壓測的週期都不會太長（一般在2周左右，這個時間還須要縮減），因此咱們比較關注壓測成本的問題，例如壓測數據的構形成本，壓測資源申請的成本，錯誤排查成本，以及便捷性方面的問題，例如壓測過程的可視化，壓測報告等。

另外，高德的平常環境的壓測需求比較旺盛，除了全鏈路壓測外，咱們還須要藉助別的平臺（如PAP，PAS）來知足平常的壓測需求。

從成本收益的角度出發，最終咱們選擇自研壓測平臺來知足高德的全鏈路壓測需求，以及平常的壓測需求。

高德壓測平臺的自建思路

如何打造一款全新的壓測平臺？

回答這個問題，先要回答平臺的目的是什麼。高德壓測平臺的目的是什麼？必定是爲了解決業務的問題！結合上文對全鏈路壓測的描述，對高德業務特色的描述，咱們建設壓測平臺就須要回答這幾個問題：

• 如何保證場景的真實性？
• 線上壓測，如何保證壓測流量不影響線上用戶，若是保證壓測數據不污染線上數據？
• 如何構建超高流量？
• 如何下降使用成本？
• 如何下降資源成本？

如何保證場景的真實性

壓測要保證真實，須要在壓測場景上作到全覆蓋，須要從協議支持和用戶行爲兩個方面來知足場景的真實性。

• 協議支持：

對於高德服務而言，不一樣的用戶場景使用到的通訊協議不同，例如PC端主要是http協議，而移動端則是accs協議。所以全鏈路壓測的場景設計上首先須要知足對全協議的支持。

• 用戶行爲：

除協議外，場景構造還須要考慮到真實場景的用戶行爲，目前的作法是使用線上日誌做爲原材料，對日誌進行過濾，整理，最終造成標準化語料文件，這樣能夠在必定程度上保證壓測數據的真實性。這種低成本的作法，只能藉助業務同窗的經驗去保證。人總會出錯，所以將來在場景真實性保障方面不能僅僅依靠人的經驗，平臺須要經過技術的手段，經過模型，依靠機器去保證。

線上壓測，如何保證壓測流量不影響線上用戶，如何保證壓測數據不污染線上數據？

爲了保證壓測流量不影響線上用戶，不對污染線上環境，首先要作的是：鏈路上的各系統，中間件須要作到對壓測流量進行識別，具體而言須要以下步驟：

• 接入鷹眼
• 使用集團的中間件（集團的中間件都支持壓測流量識別）
• 業務改造（結合鷹眼對壓測標進行透傳，對於某些業務可能須要在業務層面對壓測流量進行過濾，如對三方系統的調用須要替換成mock方式）

除此以外，還須要有完備的監控手段，在發現服務問題（如系統中發生限流，降級，RT忽然增高等等）時，及時的止損。

如何構建超高流量

對線上服務的壓測，須要構造出超大規模級別的壓力。這須要大量的施壓機器共同努力才能達到。要達到驗證服務穩定性的目標，全鏈路壓測就須要具有構造超大規模壓力的能力。咱們目前的策略是自建分佈式Jmeter施壓集羣，依託於Aone的快速部署和便捷的擴容能力來迅速的知足壓測流量的需求。

如何下降使用成本

• 壓測引擎：以往高德線下的壓測屬於工具形式，你們使用Jmeter對被測服務進行壓力測試，負責壓測的同窗都對Jmeter比較熟悉。考慮到平臺使用的成本，和工具轉平臺的便捷性，咱們使用Jmeter做爲TestPG的壓測引擎。
• 快速壓測：高德有很是多的單鏈路壓測需求，並且服務的接口數量比較少，也比較簡單。對於此類型的壓測需求，平臺須要提供開速開始的能力，簡化語料->場景->任務的標準化流程。
• 壓測數據管理：全鏈路壓測使用的壓測數據（語料文件）的大小達到數十G，文件的存儲和分發對系統的設計而言都是不小的挑戰。目前採起的作法是使用OSS來存儲壓測數據，經過必定的策略和算法在施壓機器上對語料進行預加載。

如何下降資源成本

高德每一年會進行兩次大型的壓測（春節和十一），其餘時間如：清明，五一，端午視各業務線的狀況而定。在大型壓測時，須要大量的壓測資源（幾百臺，4C16G），而平時少許的壓測資源（幾十臺）就足以知足平常的壓測需求，所以在壓測資源的管理上要保證靈活，須要時快速知足，不須要時釋放，避免資源浪費。

目前TesgPG提供兩種施壓集羣擴容的方式：一是使用Aone部署，經過Normandy平臺進行快速擴容（pouch）；二是支持用戶自主提供壓測機，技術方案是使用Docker + StarAgent 方式來實現施壓機的自動部署。

壓測資源調度：除了支持全鏈路壓測外，還須要支持平常的壓測。對於不一樣的壓測，系統在設計上要知足多租戶，多任務的需求，在壓測資源的管理方面作到按需分配（目前是人工評估）。

高德壓測平臺的自建目標

• 短時間目標：

支撐高德全鏈路壓測。

爲高德全部服務提供線下壓測的能力。

• 中期目標：

成爲高德線上系統穩定性的試金石。

• 長期目標：

產品化，服務於集團的更多業務。

高德壓測平臺架構與特色

高德壓測平臺架構

• 高德壓測平臺業務架構

• 高德壓測平臺技術架構

高德壓測平臺特色

• 極速壓測：

對於大部分簡單壓測需求，TestPG提供極速壓測的能力，只須要填寫被測服務地址，設定壓測必須的url，請求類型，請求字段，QPS，壓測時長等信息，就能夠開始壓測。對於初次使用平臺的用戶，平均15分鐘即能上手壓測。

• 調試能力：

TestPG平臺提供兩種調試手段：擋板調試和服務調試。

1. 擋板調試：請求不會發往真實的服務，施壓機做爲調試擋板，對語料格式，url格式，請求參數進行校驗。
2. 服務調試：平臺將壓測請求（默認20條請求）發往真實的被測服務，並詳細記錄請求的上行數據和下行數據，格式化後，經過平臺展現給用戶。

調試的目的式幫助用戶調整壓測的參數，爲正式的壓測作好準備。

• 錯誤定位輔助：

TestPG平臺會詳細記錄壓測過程當中出現異常的請求，對請求的上行數據和下行數據進行格式化保存，用戶能夠在壓測過程當中經過平臺查看異常日誌，定位錯誤緣由。

• 詳細的壓測報告&基線對比：

TestPG平臺在壓測完成後自動產出壓測報告，壓測報告詳細包括本次壓測的總體、各場景、全部接口的QPS，RT，最大、最小RT，百分統計RT，錯誤請求數量，錯誤請求率。而且還包含壓測時的實時QPS ，RT圖表，以及被測服務的基礎監控數據。

此外，壓測報告還支持基線對別，若設定了基線報告，後續產出的壓測報告都會和基線進行對比，在報告中就會體現出服務性能的變化。壓測報告的詳細信息能夠查看下文平臺展現中壓測報告部分。

高德壓測平臺展現

壓測看板

調試

錯誤排查

壓測報告

高德全鏈路壓測的實踐

2018年十一是我參加了高德全鏈路壓測，當時團隊的同窗一塊兒聚在穩定性保障會議室裏，對高德的核心鏈路進行了爲期兩週的全鏈路壓測。

高德的全鏈路壓測流程是比較傳統的方式，下圖是歷年全鏈路壓測的大體流程：

高德壓測平臺的現狀

高德壓測平臺從2018年開始啓動，通過大半年的發展，已經成功支持了高德2019年春節全鏈路壓測，2019年五一全鏈路壓測，在施壓能力方面達到百萬級別。

目前高德壓測平臺包括語料生產，場景構造，壓測資源管理，壓測任務調度，壓測過程監控，壓測調試，壓測錯誤排查，壓測報告生成，壓測報告評估（對比基線，從QPS，rt，cpu，mem這幾個維度進行壓測結論的評估）等功能。

平臺從2018年末投入使用至今，共執行幾千次的壓測。經過開放api的方式，平臺開放壓測能力，現已成功和持續交付平臺打通，爲持續交付提供可靠的性能指標。

自春節後，平臺主要致力於下降壓測門檻，提高壓測效率。對於大部分簡單的壓測需求，從原有的語料->場景->任務逐級構造模式簡化爲一鍵壓測模式，在初次使用平臺成本方面，簡單的壓測工做預計能從平均3小時，減少爲平均30分鐘。

雖然高德壓測平臺在近一年的時間裏，取得了一些成果，咱們也支撐了幾回全鏈路壓測。可是咱們的全鏈路壓測還不能徹底知足上文的三個要求，其中最關鍵的場景真實性還沒法獲得保證，"全鏈路壓測" 對於高德來講，仍是遠方，咱們還有不少路要走，還有不少困難要克服。

高德壓測平臺的將來

在可見將來裏，咱們指望在如下幾個方面去探索和實踐：

全鏈路監控

TestPG目前的監控是基於用戶自定義鏈路的監控，在鏈路真實性上沒法獲得保障。將來咱們將會與運維團隊合做，打造基於EagleEye鏈路自動梳理的全鏈路監控。除了基本的系統指標監控功能外，TestPG平臺還會在下面的幾個方面進行探索：

• 監控大盤，全面的展現系統的狀態
• 短板機器，短板服務的識別
• 基於時間序列的性能問題挖掘
• 結合郵件，釘釘等手段，對發現的問題進行及時的報警

簡化語料生成流程

目前壓測語料的生成採用的是用戶自定義腳本的方式。平臺定義好語料目錄格式，語料文件格式，用戶編寫語料處理（通常以日誌文件爲基礎）的程序，而後上傳到平臺。平臺會執行用戶提供的程序，而後在將程序的輸出文件存儲在OSS上，以備壓測之用。

這種方式下降了平臺的實現成本，也給用戶提供了足夠靈活度，可是增長了語料的處理門檻。將來咱們會將這部分工做所有交由平臺來處理，用戶只須要提供原材料，配置生成規則便可。

豐富壓力模型

TestPG平臺目前的壓力模型是Jmeter原生的，爲了最大限度的接近真實場景，在壓力模擬上，咱們還須要具有以下幾種壓力模型：

• 步進施壓
• 抖動施壓
• 脈衝施壓

壓測置信度評估

壓測場景可否表明真實的用戶場景？這是一個TestPG目前還沒法回答的問題。場景的真實性如今依託於業務同窗的經驗，業務同窗按照本身抽象出來的業務模型對原材料（一般是線上日誌）進行處理，生成平臺規定格式的預料文件。語料對平臺和用戶來說，都是黑盒子，除了被測系統外，沒人知道語料的模型是否接近真實世界的用戶場景。

所以，咱們指望經過一些技術手段來對壓測場景的真實性進行一個科學的評估，這即是壓測置信度評估。置信度評估的目標是評估壓測的場景和咱們指望的場景類似度，下面是壓測置信度評估須要探索的方向：

• 建設場景特徵庫（例如五一，十一，春節）
• 基於特徵庫的壓測場景置信度評估
• 基於地理位置的壓測場景置信度評估
• 基於鏈路覆蓋度的壓測場景置信度評估
• 基於流量模型的壓測場景置信度評估

結合上述維度的評估數據，咱們能夠給出一個具備價值的評估報告，做爲一個重要的參考，能夠幫助用戶評估壓測的效度。

鏈路改造

TestPG平臺的中期目標是要支撐高德業務的全鏈路壓測，成爲高德系統穩定性的試金石。但如今咱們離真正的全鏈路壓測的距離還很遠，咱們的壓測場景只覆蓋了讀請求，還不具有支持寫請求壓測的能力，緣由是系統還不具有全鏈路流量識別的能力，還不具有隔離壓測流量的能力。將來，全鏈路壓測，全場景覆蓋是必經之路。

關注高德技術，找到更多出行技術領域專業內容