??

[[208127]]

穩(wěn)定性是技術(shù)團(tuán)隊(duì)的命根子，滴滴也在搞全鏈路壓測(cè)了。雖然才四五年，滴滴內(nèi)部已經(jīng)有了眾多系統(tǒng)，而且號(hào)稱四大語言，八大框架，改造成本可想而知。

如何做到釜底抽薪，支持線上環(huán)境的全鏈路壓測(cè)?而且與一般電商不同，滴滴的交易是實(shí)時(shí)的，乘客發(fā)單，附近需要有司機(jī)能立即接單，順風(fēng)車尤為復(fù)雜，研發(fā)壓測(cè)工具又面臨著怎樣的挑戰(zhàn)?

滴滴出行創(chuàng)立于 2012 年，是全球領(lǐng)先的一站式多元化出行平臺(tái)。經(jīng)歷過各種燒錢補(bǔ)貼大戰(zhàn)、多次合并，滴滴成為繼阿里之后，國(guó)內(nèi)第二個(gè)日訂單量超過千萬的公司。

??

[[208128]]

業(yè)務(wù)飛速增長(zhǎng)，IT 系統(tǒng)面臨的挑戰(zhàn)通常更甚于業(yè)務(wù)，因?yàn)椴粌H需求規(guī)模增加，技術(shù)人員數(shù)量增加，面臨問題的復(fù)雜度也增加。

??

2016 年的滴滴，正在經(jīng)歷這樣的階段，一方面日單量從百萬沖到千萬，另一方面 IT 系統(tǒng)屢次出現(xiàn)線上故障，穩(wěn)定性建設(shè)成為支撐業(yè)務(wù)發(fā)展的重要保障。在此背景下，滴滴啟動(dòng)了全鏈路壓測(cè)項(xiàng)目。

壓測(cè)方案

滴滴的業(yè)務(wù)與普通電商差別較大，一次典型的用戶打車流程是這樣的：乘客發(fā)單，0-3 分鐘內(nèi)派給附近的司機(jī)，司機(jī)搶單后，去接乘客，到達(dá)目的地。這不但要求司乘的位置相近，而且交易必須是實(shí)時(shí)的。

基于滴滴業(yè)務(wù)的特殊性，同時(shí)借鑒了業(yè)內(nèi)的經(jīng)驗(yàn)，我們制定了滴滴的全鏈路壓測(cè)方案，一句話描述就是：在線上環(huán)境，針對(duì)全業(yè)務(wù)核心鏈路，以數(shù)據(jù)隔離的方式進(jìn)行壓測(cè)，如下圖所示：

??

線上環(huán)境

基于阿里等公司之前的經(jīng)驗(yàn)，壓測(cè)在線上環(huán)境進(jìn)行，線上***的優(yōu)點(diǎn)就是環(huán)境真實(shí)，不需要擔(dān)心配置不一致、結(jié)果是否可以同比例放大等問題，壓測(cè)的結(jié)果自然也更為精確。

但在線上做壓測(cè)，需要保證安全性，風(fēng)險(xiǎn)不言而喻：不能搞垮線上系統(tǒng)。這就需要將壓測(cè)的時(shí)間窗口限定在低峰期;監(jiān)控必須給力，在系統(tǒng)出現(xiàn)單點(diǎn)故障前，要能夠提前預(yù)警，萬一真的出現(xiàn)故障，必須緊急停止壓力，最短時(shí)間內(nèi)進(jìn)行恢復(fù)。

全業(yè)務(wù)核心鏈路

它支持出租車、專車、快車、順風(fēng)車等幾個(gè)主要的業(yè)務(wù)線，覆蓋主要的業(yè)務(wù)場(chǎng)景，以出租車為例，從乘客打開 APP 輸入上車點(diǎn)、目的地、發(fā)單，到司機(jī)出車、搶單、接乘客上車、到達(dá)目的地，甚至取消訂單等完整流程。

流程圖如下所示：

??

數(shù)據(jù)隔離

壓測(cè)方案的核心是數(shù)據(jù)隔離，需要做到壓測(cè)司乘要與真實(shí)司乘區(qū)分，壓測(cè)訂單不能與真實(shí)訂單混淆，絕不能把真實(shí)乘客的單派給虛擬司機(jī)等問題。

下面將專門介紹壓測(cè)的數(shù)據(jù)隔離方案。

01數(shù)據(jù)隔離方案

與其談隔離方案，不如讓我們想象幾種數(shù)據(jù)隔離不好的場(chǎng)景：

• 某真實(shí)司機(jī)的歷史訂單突然多了一些假訂單，積分、券、余額等出錯(cuò)。
• 某真實(shí)乘客的訂單被派給了虛擬司機(jī)，乘客一直在等待司機(jī)來接。
• 某城市的 BI 報(bào)表出錯(cuò)，莫名其妙的多了一些訂單，貌似財(cái)務(wù)也對(duì)不上。
• 某城市的運(yùn)力估計(jì)及動(dòng)調(diào)出現(xiàn)異常波動(dòng)。
• 清理虛擬訂單及相關(guān)數(shù)據(jù)時(shí)，不小心誤刪了真實(shí)訂單和數(shù)據(jù)......

虛擬訂單方案

隔離不好的場(chǎng)景，光是想想就不寒而栗，可以讓我們輕易排除這種看似最簡(jiǎn)單的方案：使用真實(shí)司機(jī)乘客，發(fā)送虛擬訂單。

虛擬訂單通過 ID 或者標(biāo)志字段進(jìn)行區(qū)分，派單時(shí)做特殊處理。這種方式對(duì)業(yè)務(wù)有較大的侵入性，不僅是修改派單那么簡(jiǎn)單，還需要從各個(gè)維度適時(shí)地屏蔽司乘與虛擬訂單的關(guān)系，如訂單歷史、通知推送、積分統(tǒng)計(jì)等，不但多而且是強(qiáng)依賴，顯然不是一種合理的方案。

提升虛擬的層次

每個(gè)城市啟用一批虛擬的乘客，發(fā)送虛擬訂單，派發(fā)給虛擬司機(jī)，司乘及訂單上通過 ID 或者標(biāo)志字段進(jìn)行區(qū)分。

這可以解決司乘及訂單強(qiáng)依賴的問題。但從城市的角度看，需要隔離真實(shí)司乘與虛擬司乘，又會(huì)涉及到城市的動(dòng)態(tài)調(diào)價(jià)、供需預(yù)測(cè)、BI 統(tǒng)計(jì)等各個(gè)方面的隔離。

再提升虛擬的層次

與傳統(tǒng)電商不同，Uber、滴滴這樣的出行平臺(tái)，都是按城市運(yùn)營(yíng)的，通過配置的方式開城，從而實(shí)現(xiàn)業(yè)務(wù)的橫向快速擴(kuò)展。

那有沒有可能在中國(guó)開辟一個(gè)甚至多個(gè)虛擬的城市呢，壓測(cè)只在虛擬城市進(jìn)行呢? 開辟虛擬城市，可以避免前面提到的諸多問題，尤其是隔離問題，但需要考慮虛擬乘客發(fā)布路線、虛擬司機(jī)地圖導(dǎo)航的問題，城市的位置、道路怎么模擬?

干脆再進(jìn)一步，虛擬一個(gè)完整的中國(guó)了，看似比較瘋狂，但這就是滴滴全鏈路壓測(cè)時(shí)的隔離方案。

在某虛擬國(guó)家，有很多虛擬的城市，每個(gè)虛擬城市都有一群虛擬的司機(jī)和乘客，他們使用虛擬的手機(jī)號(hào)和客戶端，進(jìn)行線上交易，由此產(chǎn)生了虛擬的訂單。

這里仍然要解決位置、道路的問題，我們把中國(guó)的坐標(biāo)全部偏移到太平洋，“太平洋足夠大，完全容得下中美兩個(gè)國(guó)家”，那一個(gè)中國(guó)自然不再話下。至于虛擬城市的位置、道路，把真實(shí)城市偏移一定的經(jīng)緯度就可以。

02壓測(cè)流量標(biāo)記方案

考慮這樣的場(chǎng)景：在新開辟的虛擬城市，某虛擬的乘客要打車，他打開虛擬的手機(jī)端，輸入目的地，點(diǎn)擊“立即預(yù)約”，請(qǐng)求發(fā)送到滴滴的后臺(tái)系統(tǒng)，后臺(tái)應(yīng)該怎樣處理?

談?wù)摲桨钢埃攘私庖幌卢F(xiàn)狀：

??

傳說有一種系統(tǒng)叫別人家的系統(tǒng)，有一個(gè)語言叫別人家的語言，有一種協(xié)議叫別人家的協(xié)議。

正所謂人比人氣死人，回頭看看自己家的，雖然與很多前輩不敢相提并論，但已號(hào)稱四大語言八大框架，這個(gè)鍋得讓歷史遺留問題來背，而這段歷史，只有短短的幾年而已。

也有好消息，與 Google 的 Dapper、阿里的鷹眼類似，滴滴內(nèi)部有一套自己的 Trace 系統(tǒng)，專門用來跟蹤系統(tǒng)之間的調(diào)用鏈路，其基本原理如下圖所示：

??

但并不全是好消息，全鏈路壓測(cè)啟動(dòng)的時(shí)候，Trace 系統(tǒng)在滴滴內(nèi)部并未完全推廣，不少系統(tǒng)不支持。

壓測(cè)流量標(biāo)記方案面臨兩重選擇：

• 每個(gè)系統(tǒng)使用業(yè)務(wù) ID 或標(biāo)記來判斷壓測(cè)流量，只要能拿到司乘、訂單等業(yè)務(wù)數(shù)據(jù)，系統(tǒng)就可以正確區(qū)分。
• 擴(kuò)展 Trace 通路，在通路上添加壓測(cè)標(biāo)記，統(tǒng)一使用 Trace 來判斷壓測(cè)流量。

最終我們選擇了方案 2，不但與業(yè)務(wù)完全解耦，還可以避免方案 1 中某些系統(tǒng)或接口無法拿到業(yè)務(wù)標(biāo)記的情況。而且這種方式，客觀上也可以推進(jìn) Trace 通路在公司的應(yīng)用。

做不到語言和框架收斂，盡量讓中間件收斂，為每種語言提供一個(gè)基礎(chǔ)組件類庫，中間件盡量收斂到該類庫。

??

于是結(jié)合全鏈路壓測(cè)，開始了內(nèi)部系統(tǒng)痛苦的改造之路，最終基于 Trace 通路的壓測(cè)標(biāo)記在主要系統(tǒng)之間可以跑通。

03工具端方案

鏈路已通，該考慮工具端的實(shí)現(xiàn)方案了，內(nèi)部我們管工具端叫做虛擬的“司機(jī)端”和“乘客端”，可以用來模擬批量甚至大量的用戶，而不僅僅是一個(gè)用戶。

分布式的虛擬司乘端： 滴滴的客戶端與后臺(tái)通信，不僅僅有 HTTP 協(xié)議，還有 TCP 長(zhǎng)連接，甚至還有 Thrift 協(xié)議。

拿司機(jī)來說，接單等消息是通過 TCP 長(zhǎng)連接下發(fā)的，意味著 TCP 長(zhǎng)連接協(xié)議是必須的，而且需要為每個(gè)司機(jī)維護(hù)一個(gè)長(zhǎng)連接。

考慮到需要模擬的司乘數(shù)量，虛擬的司機(jī)端、乘客端是分布式部署的，每個(gè)司乘端從數(shù)據(jù)中心獲取司乘用戶，包含基本信息、乘客路線、司機(jī)起始位置等信息，并且模擬批量司乘的發(fā)單等行為。

使用數(shù)據(jù)中心的目的是，當(dāng)端需要擴(kuò)展時(shí)，拉取的司乘不能重復(fù)，不然重復(fù)登錄可能導(dǎo)致被踢下線。

??

可動(dòng)態(tài)調(diào)整的業(yè)務(wù)模型： 虛擬端要模擬相對(duì)復(fù)雜、實(shí)時(shí)的交易模型，并且需要模擬不同的業(yè)務(wù)場(chǎng)景，以順風(fēng)車舉例，平日高峰期的訂單多為市內(nèi)訂單，而節(jié)假日的跨城訂單比率增加很多。

如何在不改代碼的情況下可以壓測(cè)不同的業(yè)務(wù)場(chǎng)景?我們實(shí)現(xiàn)了可動(dòng)態(tài)調(diào)整的業(yè)務(wù)模型。

??

該模型中，司乘基本的交易過程、狀態(tài)變化可以通過模型編輯完成，通過權(quán)重，可以調(diào)整用戶本地單、跨城單的比例。即使更多的業(yè)務(wù)場(chǎng)景，只需生成業(yè)務(wù)模型即可支持。

更多實(shí)現(xiàn)細(xì)節(jié)： 當(dāng)然除了上面提到的，方案上還有很多細(xì)節(jié)需要考慮。為了與線上實(shí)際場(chǎng)景更貼近，我們從線上高峰期截取了一段時(shí)間內(nèi)的乘客路線和司機(jī)位置，分階段壓測(cè)時(shí)，逐漸投放更多的司乘到虛擬城市，但這樣有一個(gè)問題。

假設(shè) A 城市有 1 萬司機(jī)，高峰期有 1 萬乘客在發(fā)單，他們都是隨機(jī)而均勻分布的，如果把全部司機(jī)瞬間投放完成，所有乘客立即發(fā)單，絕大多數(shù)訂單應(yīng)該是可以派出并完成交易的。

但是考慮分階段投放的場(chǎng)景：投放 1% 的司乘，上百名司機(jī)，上百個(gè)訂單，雖然司機(jī)位置、乘客路線來自線上真實(shí)訂單的采樣，由于位置的隨機(jī)性，成單量可能很少。即使投放了 10%，上千名司乘，實(shí)際成單量也遠(yuǎn)遠(yuǎn)達(dá)不到 1000 個(gè)。

??

而我們分階段投放要求的 10%，不光是投放數(shù)量達(dá)到線上 10%，也期望成單量等數(shù)據(jù)同步達(dá)到 10%，這樣才能驗(yàn)證工具端方案是否合理、線上壓力是否正常。

在這里，我們采用了一個(gè)簡(jiǎn)單的算法：東單是北京的一個(gè)熱點(diǎn)區(qū)域，***個(gè)司機(jī)、乘客投放在東單，基本上可以保證成單;前 1000 名司機(jī)、乘客投放在東單附近，成單量雖不能上千，但比完全隨機(jī)要好很多。

控制好司乘投放的位置，基本可以保證成單量與投放數(shù)量成比例增長(zhǎng)。

??

壓測(cè)實(shí)錄

2016 年上半年是滴滴 Uber 合并前***的瘋狂，運(yùn)營(yíng)活動(dòng)頻繁，業(yè)務(wù)峰值不斷攀升，平臺(tái)出現(xiàn)的線上事故也較為多些。

??

從 2016 年中項(xiàng)目啟動(dòng)，經(jīng)過多次嘗試、探索，終于在線上成功進(jìn)行了全鏈路壓測(cè)。為了不影響線上業(yè)務(wù)，壓測(cè)的窗口期選擇在凌晨，并且嚴(yán)格掌控壓測(cè)節(jié)奏，把壓測(cè)過程劃分成幾個(gè)不同階段，逐漸提升壓力，邊壓測(cè)邊監(jiān)控后臺(tái)系統(tǒng)的壓力：

??

幾個(gè)主要的業(yè)務(wù)線先后進(jìn)行了十余次壓測(cè)，并發(fā)現(xiàn)了一些線上問題，如某 API 接口耗時(shí)明顯增長(zhǎng);長(zhǎng)連接服務(wù)器的參數(shù)配置有誤;分單服務(wù) codis 訪問超時(shí);日志過多導(dǎo)致分單算法超時(shí)等。

除了驗(yàn)證線上系統(tǒng)的穩(wěn)定性，全鏈路壓測(cè)項(xiàng)目還帶來一些附加的收益：

• 不同語言下的基礎(chǔ)組件類庫趨向收斂，Trace 通道覆蓋了更多模塊。
• 建立了一套完整隔離的線上環(huán)境，未來可以在線上做更多正確性驗(yàn)證。

現(xiàn)在的滴滴，越來越重視平臺(tái)穩(wěn)定性，對(duì)事故的預(yù)警、降級(jí)處理和事故處理預(yù)案越來越成熟，事故時(shí)長(zhǎng)也明顯縮短，但仍然存在單點(diǎn)故障、魯棒性不高等潛在風(fēng)險(xiǎn)。

展望將來，期望全鏈路壓測(cè)能在更多領(lǐng)域發(fā)揮作用：

• 線上環(huán)境的故障注入和故障演練。
• 線上灰度發(fā)布環(huán)境的正確性驗(yàn)證。
• 線上系統(tǒng)的容量預(yù)估等。

??

[[208133]]

張曉慶

滴滴出行技術(shù)專家

全棧工程師，現(xiàn)任滴滴技術(shù)專家，曾就職于 ThoughtWorks，有多年的軟件開發(fā)、敏捷咨詢經(jīng)驗(yàn)。