2019年11月29日，在滴滴拼車上線4周年之際，滴滴發(fā)布全新的拼車產(chǎn)品，同時宣布2019年12月3日在北京、上海、廣州、成都等26個城市推出拼成一折的活動，打造首個“全民拼車日”。面對類似雙11的一折促銷活動，如何應(yīng)對瞬間的流量峰值，以及平滑、高效的實現(xiàn)司乘撮合，本文就滴滴的派單引擎來闡述這些問題的解決思路。

　0.

目錄

　　1. 背景

　　2. 滴滴分單架構(gòu)概述

　　   ○ 分單模式

　　   ○ 滴滴分單架構(gòu)

　　3. 拼車日帶來的挑戰(zhàn)

　　   ○ 拼車原生屬性

　　   ○ 拼成出發(fā)預(yù)約模式

　　   ○ 服務(wù)化架構(gòu)

　　4. 穩(wěn)定性保障之路

　　   ○ 架構(gòu)優(yōu)化

　　   ○ 拼成出發(fā)預(yù)約模式 - 臨近指派

　　   ○ 過濾邏輯優(yōu)化 - 架構(gòu)與性能的折衷

　　   ○ 超時重試配置化

　　   ○ 預(yù)案建設(shè)

　　   ○ 全鏈路壓測

　　   ○ 監(jiān)控告警

　　   ○ 告警

　　   ○ 監(jiān)控

　　   ○ 集中值班

　　   ○ 通報機制

　　   ○ 快速決策方案擬定

　　5. 展望

　　   ① 背景

　　   11月29日，在滴滴拼車上線4周年之際，滴滴發(fā)布全新的拼車產(chǎn)品。同時宣布12月3日將在北京、上海、廣州、成都等26個城市推出拼成打一折的活動，打造首個“全民拼車日”。

　　   拼車推出新模式“拼成出發(fā)”和拼成打一折的活動給分單引擎帶來成倍的壓力增長，本文介紹其中的挑戰(zhàn)。

　　   ②滴滴分單架構(gòu)概述

　　   滴滴分單引擎主要做的是司機和訂單的匹配，也就是來決策如何更好的將用戶的訂單分配給司機。

　　   ▍分單模式

　　   從分單模式上，主要抽象為獨乘分單和合乘分單(拼車分單):

　　   獨乘分單解決的是單個訂單和司機的最優(yōu)決策分單，分為多種場景模式，目前承載了滴滴快車、專車、出租車、豪華車的獨乘分單業(yè)務(wù)。

　　   對于拼車單，會將順路的訂單進行打成一個“包”，在獨乘分單的基礎(chǔ)上，拼車分單還要解決“包”和司機的最優(yōu)決策分單，承載了目前快車拼車、出租車拼車、跨城拼車的合乘分單業(yè)務(wù)。

　　   ▍滴滴分單架構(gòu)

　　   分單整體流程如漏斗，訂單司機對會從頂層，層層向下篩選，最終形成一個個可匹配的訂單司機對。

　　  假設(shè)參與計算的訂單有1000，司機有4000，那么進入第一層的訂單司機對數(shù)是400萬，計算壓力與訂單數(shù)和司機數(shù)的乘積成正比。

　　  ③拼車日帶來的挑戰(zhàn)

　　  滴滴分單引擎主要做的就是司機和訂單的匹配，所以司機訂單匹配計算量基本上表征了整個系統(tǒng)的壓力。

　　  活動當天：司機訂單匹配計算量峰值相比日常峰值增長2.24倍，其中拼車計算量相比日常峰值增長6.6倍。

　　  總結(jié)下來主要是以下幾方面的原因:

　　  ▍拼車原生屬性

　　  對于一個普通的快車單來說，分給一個司機之后，在這個司機快到達目的地之前，這個司機可以認為不參與分單了，對于系統(tǒng)壓力變小。

　　  但是對于一個拼車單來說，分給一個司機之后，這個司機會繼續(xù)進到分單系統(tǒng)里面來，和別的拼車單執(zhí)行“拼”的邏輯，所以相比于快車單，司機的匹配周期更長，計算也更復(fù)雜，除了考慮司機和乘客的匹配外、還需要考慮乘客和乘客的順路度。

　　  ▍拼成出發(fā)預(yù)約模式

　　  在正常情況下，一個快車單的生命周期只有有限幾分鐘，生命周期內(nèi)沒應(yīng)答，就會自動取消，那么系統(tǒng)就沒有壓力了。

　　  拼成出發(fā)，分為隨時可走和預(yù)約模式，預(yù)約模式最長生命周期1天，雖然初期預(yù)約單占比不高，但隨著時間推移，預(yù)約單越堆積越多，系統(tǒng)壓力越來越大。

　　  拼成出發(fā)只能分配載人車，或者作為一個包分給司機，本身條件就更苛刻，在訂單池里面的存活時間也更長一些。

　　  總結(jié)來說，拼成出發(fā)模式使得訂單的生命周期更長。

　　  ▍服務(wù)化架構(gòu)

　　  目前的司機訂單過濾架構(gòu)簡化圖如下:

　　  整體分單流程是一種漏斗形式，輸入是需要匹配的司機和訂單，輸出是匹配成功的匹配對。

　　  第一層漏斗是通用過濾層，對于通過了通用過濾模塊的司機訂單組合，才會漏到拼成過濾層進行過濾。

　　  無論是通用過濾模層還是拼車過濾層，都是先進行過濾，對于沒有被過濾的司機訂單組合，再進行訪問下游的工作。

　　  對于在2.1部分過濾的司機訂單組合來說，在1.2部分訪問的下游數(shù)據(jù)很多是無用的，也就是說給下游帶來的壓力是浪費的，這也是服務(wù)化架構(gòu)引入的代價。

　　  拼成出發(fā)模式因為拼成了才能派車，而是否可以拼成的邏輯都在拼車過濾模塊中，隨著時間的積累，能通過1.1但是無法通過2.1的司機訂單組合越來越多，這也是下游壓力增長過大的一個原因。

　　  ④穩(wěn)定性保障之路

　　  我們的穩(wěn)定性保障工作主要分為架構(gòu)優(yōu)化、容量評估、預(yù)案建設(shè)、監(jiān)控告警、全鏈路壓測幾個部分:

　　  ▍架構(gòu)優(yōu)化

　　  我們對現(xiàn)有架構(gòu)進行了審視：

　　  其中拼成出發(fā)預(yù)約模式和服務(wù)化架構(gòu)引入的代價部分，給下游帶來的壓力過大，不能完全按照現(xiàn)有模式進行擴容，我們需要對現(xiàn)有架構(gòu)進行優(yōu)化。

　　  拼成出發(fā)預(yù)約模式 - 臨近指派

　　  針對拼成出發(fā)預(yù)約模式，用戶發(fā)單之后，訂單會同時進入分單的訂單池和拼車的拼友池。拼友池：進入拼友池的訂單，拼車打包模塊會給當前用戶尋找拼友，也就是進行打包操作。

　　  訂單池：進入訂單池的訂單，就會進入分單引擎進行分單。但拼成出發(fā)預(yù)約模式，會在訂單出發(fā)時間的前k分鐘，才真正開始給用戶找車，在找車之前的計算都是無效的。

　　  針對這種情況，對拼成出發(fā)預(yù)約模式進行了優(yōu)化，將發(fā)單進入訂單池的操作改為臨近進入訂單池，有效降低訂單池規(guī)模。

　　  過濾邏輯優(yōu)化 - 架構(gòu)與性能的折衷

　　  針對服務(wù)化架構(gòu)引入的代價，拼車分單的同學將拼車過濾中過濾比例較高的策略，遷移到了通用過濾模塊中。這算是在現(xiàn)有架構(gòu)下，為了性能的一種妥協(xié)。

　　  后續(xù)應(yīng)該會探討出一種更合理的架構(gòu)來解決這種問題。

　　  經(jīng)過評估，上面2部分的業(yè)務(wù)架構(gòu)優(yōu)化，在同樣用戶呼叫單量的前提下，對下游的訪問壓力可以下降50%以上。

　　  超時重試配置化

　　  為了更加靈活的控制下游的超時重試，整個分單主流程的調(diào)度周期，下游的超時時間，重試次數(shù)，都實現(xiàn)了配置化，修改秒級生效。

　　  為了防止流量突增時引發(fā)下游雪崩，在拼車日之前，我們將整個分單主流程的下游重試都調(diào)成了1，也就是不再重試。

　　  ▍預(yù)案建設(shè)

　　  因為活動中可能會有很多不可預(yù)知的事情發(fā)生，針對可能發(fā)生的異常，我們做了一系列的預(yù)案。

　　  預(yù)案的底線目標是：保障評估容量內(nèi)無異常，超出評估容量不被打掛;包括五部分：

　　  提前降級功能：活動前操作，主要提前降級的功能

　　  入口預(yù)案：活動中操作，出現(xiàn)重大風險和異常時執(zhí)行

　　  最小核心鏈路預(yù)案：活動中操作，核心節(jié)點出現(xiàn)風險和異常時執(zhí)行

　　  業(yè)務(wù)指標異常預(yù)案：活動中，系統(tǒng)無異常，但是業(yè)務(wù)指標出現(xiàn)異常

　　  崩潰恢復(fù)預(yù)案：核心服務(wù)出現(xiàn)雪崩，如何快速恢復(fù)

　　  每項預(yù)案都需要提前演練，保證預(yù)案有效、且符合預(yù)期。

　　  ▍全鏈路壓測

　　  全鏈路壓測是評估系統(tǒng)容量最有效的手段，拼車日一共進行了8次演練，9次正式壓測，發(fā)現(xiàn)了45個有效問題。

　　  經(jīng)過一輪又一輪的壓測，大家對自己的服務(wù)容量都有了更清晰的認識。

　　  在壓測過程中，到達系統(tǒng)容量之后，我們還會繼續(xù)加壓，觀察多個系統(tǒng)在系統(tǒng)超限情況下，是否會被打掛。

　　  在壓測過程中，我們也會演練提前制定好的預(yù)案，把壓測場景當成活動日看待。

　　  ▍監(jiān)控告警

　　  告警

　　  拼成日之前，我們重新梳理了各模塊告警。分以下幾大類：

　　  機器信息類：包括cpu、磁盤、句柄數(shù)、網(wǎng)卡錯誤、協(xié)議棧錯誤

　　  自身服務(wù)：包括存活性、服務(wù)容量水位線、服務(wù)總耗時最大值、服務(wù)各階段耗時最大值

　　  依賴服務(wù)：包括請求耗時、超時或者錯誤率、是否限流

　　  client端：請求耗時99分位、成功率

　　  同時對于各個告警都進行了報警升級，拼車日當天寧可誤報，不可錯過任何一個錯誤信息。

　　  針對每個告警，都有至少一個預(yù)案閾值對應(yīng)，保證系統(tǒng)穩(wěn)定性。

　　  監(jiān)控

　　  除了完善系統(tǒng)各項指標監(jiān)控，我們還建立了多個監(jiān)控大盤。

　　  拼車業(yè)務(wù)指標大盤：各個指揮者需要實時關(guān)注該大盤。

　　  系統(tǒng)機器性能大盤：運維人員需要實時關(guān)注該大盤。

　　  各個服務(wù)監(jiān)控：為每個服務(wù)指定負責人，實時關(guān)注。

　　  ▍集中值班

　　  通報機制

　　  各個方向值班長需要在值班群里實時通報異常情況。

　　  每隔10分鐘，各個方向值班長需在值班群里通報系統(tǒng)是否正常。

　　  快速決策方案擬定

　　  拼車日之前，已經(jīng)確定好。遇到何種問題需上報，何種問題需立即快速解決，何種問題需上下游配合解決。解決方案要盡可能得覆蓋異常情況。

　　  我們采用了扁平化的人員組織方式，以達到更高效率的問題處理。

　　  拼車相對于快車對系統(tǒng)在匹配復(fù)雜度、路徑規(guī)劃等方面的挑戰(zhàn)更大，難度更大，基于這次拼車日保障的積累，我們將不斷提升能力，提供穩(wěn)定可靠的技術(shù)保障。

　　  文章來源：滴滴技術(shù)