0.

目錄

?

1. 背景

2. 滴滴分單架構概述

• 分單模式

• 滴滴分單架構

3. 拼車日帶來的挑戰

• 拼車原生屬性

• 拼成出發預約模式

• 服務化架構

4. 穩定性保障之路

• 架構優化

• • 拼成出發預約模式 - 臨近指派

  • 過濾邏輯優化 - 架構與性能的折衷

  • 超時重試配置化

• 預案建設

• 全鏈路壓測

• 監控告警

• • 告警

  • 監控

• 集中值班

• • 通報機制

  • 快速決策方案擬定

5. 展望

?

?

1.?

背景

?

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

?

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

?

?

2.?

滴滴分單架構概述

?

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

?

▍分單模式

?

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

?

?

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

?

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

?

▍滴滴分單架構

?

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

?

?

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

?

?

3.?

拼車日帶來的挑戰

?

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

?

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

?

總結下來主要是以下幾方面的原因:

?

▍拼車原生屬性

?

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

?

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

?

▍拼成出發預約模式

?

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

?

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

?

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

?

總結來說，拼成出發模式使得訂單的生命周期更長。

?

▍服務化架構

?

目前的司機訂單過濾架構簡化圖如下:

?

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

?

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

?

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

?

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

?

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

?

?

4.

穩定性保障之路

?

我們的穩定性保障工作主要分為架構優化、容量評估、預案建設、監控告警、全鏈路壓測幾個部分:

?

▍架構優化

?

我們對現有架構進行了審視：

?

其中拼成出發預約模式和服務化架構引入的代價部分，給下游帶來的壓力過大，不能完全按照現有模式進行擴容，我們需要對現有架構進行優化。

?

拼成出發預約模式 - 臨近指派

?

針對拼成出發預約模式，用戶發單之后，訂單會同時進入分單的訂單池和拼車的拼友池。

拼友池：進入拼友池的訂單，拼車打包模塊會給當前用戶尋找拼友，也就是進行打包操作。

?

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

?

針對這種情況，對拼成出發預約模式進行了優化，將發單進入訂單池的操作改為臨近進入訂單池，有效降低訂單池規模。

?

過濾邏輯優化 - 架構與性能的折衷

?

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

?

后續應該會探討出一種更合理的架構來解決這種問題。

?

經過評估，上面2部分的業務架構優化，在同樣用戶呼叫單量的前提下，對下游的訪問壓力可以下降50%以上。

?

超時重試配置化

?

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

?

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

?

▍預案建設

?

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

?

預案的底線目標是：保障評估容量內無異常，超出評估容量不被打掛；包括五部分：

?

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

• 入口預案：活動中操作，出現重大風險和異常時執行

• 最小核心鏈路預案：活動中操作，核心節點出現風險和異常時執行

• 業務指標異常預案：活動中，系統無異常，但是業務指標出現異常

• 崩潰恢復預案：核心服務出現雪崩，如何快速恢復

  ?

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

?

▍全鏈路壓測

?

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

?

經過一輪又一輪的壓測，大家對自己的服務容量都有了更清晰的認識。

?

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

?

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

?

▍監控告警

?

告警

?

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

?

• 機器信息類：包括cpu、磁盤、句柄數、網卡錯誤、協議棧錯誤

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

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

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

  ?

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

?

針對每個告警，都有至少一個預案閾值對應，保證系統穩定性。

?

監控

?

除了完善系統各項指標監控，我們還建立了多個監控大盤。

?

• 拼車業務指標大盤：各個指揮者需要實時關注該大盤。

• 系統機器性能大盤：運維人員需要實時關注該大盤。

• 各個服務監控：為每個服務指定負責人，實時關注。

  ?

▍集中值班

?

通報機制

?

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

?

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

?

快速決策方案擬定

?

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

?

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

?

?

?

5.

展望

?

拼車相對于快車對系統在匹配復雜度、路徑規劃等方面的挑戰更大，難度更大，基于這次拼車日保障的積累，我們將不斷提升能力，提供穩定可靠的技術保障。

總結

以上是生活随笔為你收集整理的拼车日滴滴派单的那些事的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。