滴滴出行平臺業(yè)務架構(gòu)演進
點擊上方“服務端思維”,選擇“設為星標”
回復”669“獲取獨家整理的精選資料集
回復”加群“加入全國服務端高端社群「后端圈」

桔妹導讀:為了滿足不同用戶在價格、體驗等方面的差異化訴求,滴滴提供了越來越豐富的品類,這些品類大體流程是類似的,在一些細節(jié)體驗上有差異,一套架構(gòu)如何兼顧隔離和復用,同時支持這些品類,且看滴滴服務端技術(shù)的灣流平臺怎么做。


▎1.1.2 網(wǎng)約車獨特的“菱形”流量分配模式

▍1.2 服務端API職責定位
在開始前,需要先明確服務端API的核心職責。

流量染色:識別和定義接入流量中的品類、場景、功能,并轉(zhuǎn)義標識為統(tǒng)一的業(yè)務特征。
流程串接:根據(jù)不同事件/請求按照相應的邏輯和流程調(diào)用下游服務,以完成具體的功能。
數(shù)據(jù)渲染:將處理結(jié)果數(shù)據(jù)按不同的端或品類/場景要求渲染成對應的數(shù)據(jù)視圖。
復用:what(復用什么,復用到什么級別), how(怎么實現(xiàn)復用)
隔離:what(隔離的是什么),how(隔離機制是什么)
▍1.3 灣流平臺演進
▎1.3.1 灣流平臺1.0(2017-2018)

配置化依賴于功能抽象,需要一套統(tǒng)一的抽象方法
插件化依賴于穩(wěn)固的流程,以及清晰的功能邊界。按差異開放插件點會導致插件定義不明確、粒度無法把控、插入點不穩(wěn)定等問題,長期維護困難。
▎1.3.2 灣流平臺2.0(2018)
宏觀上,根據(jù)核心數(shù)據(jù)&職能對服務進行了拆分,將一個大模塊拆分成多個垂直閉環(huán)的子模塊,即領域化。通過分治的方式,降低了整體的復雜度,同時也解決了所有團隊成員在一個模塊開發(fā)導致的上線沖突和排隊情況。

微觀上,按流程和功能對領域服務進一步分析,進行功能聚合與抽象,即組件化。提高復用性,解決業(yè)務擴展性和開發(fā)效率的問題。

未做系統(tǒng)性的框架約束,迭代容易破壞原有結(jié)構(gòu)
側(cè)重于分治和抽象,未同步考慮品類間隔離問題
▍2.1 總體思路

//配置文件,管理流程環(huán)節(jié),以及提供給不同品類注冊各自transport{"name": "ConfirmOrder,"transports": {"default": "\\DuKang\\Transport\\ConfirmOrderaseTransport","express": "\\DuKang\\Express\\Transport\\ConfirmOrderExpressTransport","luxury": "\\DuKang\\Luxury\\Transport\\ConfirmOrderLuxuryTransport","taxi": "\\DuKang\\Taxi\\Transport\\ConfirmOrderTaxiTransport",},"steps": [{"step_id": "fetchInfoStep","description": "獲取基本信息"},{"step_id": "confirmTravelStep","description": "確認行程信息"},{"step_id": "confirmBillStep","description": "確認計價信息"},{"step_id": "checkStep","description": "成單檢查"},{"step_id": "fillOrderDetailStep","description": "訂單維度填充"},{"step_id": "sendOrderCommandStep","description": "訂單處理操作"},{"step_id": "sendDriverCommandStep","description": "司機處理操作"},{"step_id": "sendSchedulingCommandStep","description": "調(diào)度處理操作"},{"step_id": "buildResponseStep","description": "構(gòu)建響應"},{"step_id": "asyncOperationStep","description": "異步操作"},{"step_id": "writeLogStep","description": "日志處理"}]}// dukang框架核心執(zhí)行過程try {// 加載并解析接口配置,包括BizConfig、StepConfig$oBizConf = BizConfig::load($sConfigStr);// 獲取輸入源數(shù)據(jù),包括Request和基礎數(shù)據(jù)獲取$oInputSource = new ConfirmOrdernputSource();// 構(gòu)造StepRuntime$oStepRuntime = new ConfirmOrdertepRuntime($oInputSource);// 將接口配置對象、StepRuntime放入流程調(diào)度器$oFlowScheduler = new FlowScheduler($oBizConf, $oStepRuntime);// 初始化傳輸器路由因子$oTransportSelectFactor = new ConfirmOrderTransportSelectFactor($oInputSource);if($oFlowScheduler->selectTransport($oTransportSelectFactor)){// 執(zhí)行流程調(diào)度$oFlowScheduler->run();}// 異常處理原則:接口外層只處理DuKangException和Exception,Step或者Ability處理異常則先處理邏輯再拋異常} catch (DuKangException $e) {$aResp = ['errno' => $e->getCode(),'errmsg' => $e->getMessage(),];echo json_encode($aResp);} catch (\Exception $e) {$aResp = ['errno' => $e->getCode(),'errmsg' => $e->getMessage(),];echo json_encode($aResp);}
接下來,再展開對dukang的一些核心概念進行講解
◎ 定義
針對單接口內(nèi)不同運力(或品類)進行抽象得來的流程載體
任一業(yè)務必有其承載的流程和執(zhí)行順序
◎ 約束
BaseTransport覆蓋當前接口業(yè)務的通用流程
任一接口內(nèi)有且只有一個BaseTransport
XxxTransport覆蓋不同運力(或品類)的差異化實現(xiàn)
任一接口內(nèi)的差異化XxxTransport必須繼承自BaseTransport
任一Transport至少包含一個StepTransport <=> [N]Step (N >= 1)
▎2.2.2 Step - 流程環(huán)節(jié)
◎ 定義
針對單接口內(nèi)的業(yè)務進行抽象出來的環(huán)節(jié)載體
單一Step是某一段業(yè)務環(huán)節(jié)或功能的具體實現(xiàn)
◎ 特性
單一Step是大粒度差異化(如豪華車/出租車)的有效手段, 可通過Override Step實現(xiàn)
Step間的通信通過統(tǒng)一運行時數(shù)據(jù)總線StepRuntime串聯(lián),理論上可實現(xiàn)熱拔插
◎ 圖例
業(yè)務流程驅(qū)動型接口:以串聯(lián)各個處理流程為主
數(shù)據(jù)驅(qū)動型接口:以構(gòu)建業(yè)務特征數(shù)據(jù)為主

▎2.2.3 StepRuntime - 運行時數(shù)據(jù)總線
◎ 定義
流程串聯(lián)運行時數(shù)據(jù)總線
◎ 約束
StepRuntime只能作為Ability的輸入,不能在Ability及下層邏輯中對StepRuntime的業(yè)務特征和數(shù)據(jù)進行修改

▎2.2.4 InputSource - 輸入源
◎ 定義
外部輸入數(shù)據(jù)源,為TransportFactor準備數(shù)據(jù)
用于消除外部執(zhí)行環(huán)境差異化,隔離外部入?yún)?/span>
◎ 約束
進入Step之后具有只讀屬性,被StepRuntime引用,后續(xù)業(yè)務邏輯不可修改其包含的所有特征及數(shù)據(jù)內(nèi)容

▎2.2.5 Transport Factor - 傳輸器因子
◎ 定義
業(yè)務傳輸器Transport決策因子
不同接口可能會采取不同的因子進行Transport決策
目前實現(xiàn)的有針對訂單維度product_id,針對司機維度car_level
可選擇端來源作為決策因子,如滴滴出行app、開放平臺、禮橙專車app等
◎ 約束
Factor必須是確定可選擇的幾類因子,不能由RD同學自由編寫
同類業(yè)務接口原則上TransportFactor要盡量保持一致
▎2.2.6 Ability - 能力組件
▏2.2.6.1 概念描述
◎ 定義
以特征數(shù)據(jù)為視角,對聚焦業(yè)務進行提煉和抽象,形成能力組件
◎ 設計原則
面向可復用設計
面向可擴展差異化設計
▏2.2.6.2 業(yè)務特征

業(yè)務表達:播單計劃 = $sStartAddDuseTime + $bIsDelayBroadcast + $bIsRepeatAssign+ $iBroadcastAssignType + $iBroadcastExpire
規(guī)范業(yè)務屬性或字段語義,避免歧義和未知語義
定義:業(yè)務 = 有序流程 * 控制(特征X, 特征Y, 特征Z, ...), 控制 = 染色 | 填充 | 復寫 | 合并 | 標記
▏2.2.6.3 能力組件抽取過程

▍2.3 應用框架目錄結(jié)構(gòu)
// 模塊根目錄├── Dukang // 新引入的內(nèi)容,區(qū)隔老代碼,未來將替代hermes│ ├── Ability // 能力目錄│ │ ├── Common // 公用能力│ │ │ ├── DispatchOrder│ │ │ │ └── DispatchOrderComponent.php│ │ │ └── VirtualPhone│ │ │ └── VirtualPhoneComponent.php│ │ └── Express // 品類特有能力擴展│ │ └── DispatchOrder│ │ └── DispatchOrderComponent.php│ ├── Config // 接口配置│ │ └── ConfirmOrder.json│ ├── InputSource // 接口輸入│ │ └── ConfirmOrderInputSource.php│ ├── StepRuntime // 全局數(shù)據(jù)總線│ │ └── ConfirmOrderStepRuntime.php│ ├── Model // 公用model│ │ ├── Dao│ │ ├── Driver│ │ │ └── DriverModel.php│ │ └── Order│ │ └── OrderModel.php│ ├── Service // 公用service│ │ └── Driver│ │ └── DriverService.php│ ├── TransportFactor // Transport因子│ │ └── ConfirmOrderTransportFactor.php│ └── Transport // 流程串接│ ├── Base│ │ └── ConfirmOrderBaseTransport.php│ └── Taxi│ └── ConfirmOrderTaxiTransport.php└── vendor└── dukang└── framework├── idl // 數(shù)據(jù)字典(Dimensions,標準dto)└── src // 框架代碼
— 本文結(jié)束 —

關注我,回復 「加群」 加入各種主題討論群。
對「服務端思維」有期待,請在文末點個在看
喜歡這篇文章,歡迎轉(zhuǎn)發(fā)、分享朋友圈


