導讀

2018年十一當天，高德DAU突破一個億，不斷增長的日活帶來喜悅的同時，也給支撐高德業務的技術人帶來了挑戰。如何保障系統的穩定性，如何保證系統能持續的為使用者提供可靠的服務？是所有高德技術人面臨的問題，也是需要大家一起解決的問題。

高德業務規模

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

這張圖是高德業務核心鏈路的架構，從圖中可以看出高德業務具有相當高的複雜性。當然，真實系統遠遠要比圖表示的複雜，如果用這張圖來代表高德整體業務形態，無異於管中窺豹，太過於片面。

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

保障穩定性的手段

如何保障系統穩定性是幾乎所有網際網路企業都需要面對的問題。通常來講，有五種手段來從理論上保障系統的穩定性，分別是：

• 容量規劃：根據以往業務的流量，估算出未來（通常是即將來臨的大促，節假日）的流量。以整體流量為基礎，估算出每個子系統需要滿足的容量大小。然後根據子系統的容量來計算出需要的資源數量，對系統進行適當的擴容。計算方式可以簡單的表示為如下公式：

機器數量 = 預估容量 / 單機能力 + Buffer （一定數量的冗餘）

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

有了穩定性保障的五大法寶，我們是否就可以高枕無憂了呢？答案是令人遺憾的，這裡有兩個殘酷的現例項子，告誡我們不要太樂觀。

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

還有一次在某年五一期間，該服務再次發出預警，而且和春節的那次預警的原因不一樣。

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

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

因此，我們需要演習，需要讓真實的流量提前到來！

全鏈路壓測

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

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

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

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

這裡麵包含三個關鍵點：

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

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

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

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

分散式系統的特性

• 不確定性

我們認為的流量有序的，而真實的流量卻是隨機的，不確定的。

• 抖動性

在理論的世界裡面，吞吐量是請求量的函式，可以表示為如下的公式：

Throughput=f(load)

如果沒有其他因子的干擾，在系統達到飽和之前，吞吐量和請求量的關係應該是線性的。而現實世界裡面，這種理論模型幾乎是不可能出現的。為什麼？因為抖動。為什麼會出現抖動？因為網路，磁碟等等的不確定性。

• 排隊系統的特性

我們的業務可以簡單的抽象成為一個排隊系統，請求從左邊隨機的進入系統，等待被處理，處理完成之後，從右邊離開佇列。在系統未達到飽和狀態時，系統可以很好的處理使用者的請求，而一旦佇列接近飽和，那麼佇列的長度可能會顯著的增加，而且請求的平均響應時間也會出現增加，甚至會出現部分請求超時的情況。對於一個理論上能處理 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平臺的中期目標是要支撐高德業務的全鏈路壓測，成為高德系統穩定性的試金石。但現在我們離真正的全鏈路壓測的距離還很遠，我們的壓測場景只覆蓋了讀請求，還不具備支援寫請求壓測的能力，原因是系統還不具備全鏈路流量識別的能力，還不具備隔離壓測流量的能力。未來，全鏈路壓測，全場景覆蓋是必經之路。

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

&n