<kbd id="afajh"><form id="afajh"></form></kbd>
<strong id="afajh"><dl id="afajh"></dl></strong>
    <del id="afajh"><form id="afajh"></form></del>
        1. <th id="afajh"><progress id="afajh"></progress></th>
          <b id="afajh"><abbr id="afajh"></abbr></b>
          <th id="afajh"><progress id="afajh"></progress></th>

          滴滴出行平臺業(yè)務架構(gòu)演進

          共 8300字,需瀏覽 17分鐘

           ·

          2021-06-02 04:42

          點擊上方“服務端思維”,選擇“設為星標

          回復”669“獲取獨家整理的精選資料集

          回復”加群“加入全國服務端高端社群「后端圈」


          作者 | DeanWu
          出品 | 滴滴技術(shù)

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

          1. 
          項目背景
          在滴滴打車業(yè)務中,服務端API向上接收端上請求并組裝返回,向下串接訂單、計價、收銀等業(yè)務中臺的各個系統(tǒng),完成整個打車流程,灣流平臺項目期望在服務端API層打造一個「出行中臺」。在已有業(yè)務中臺的情況下,為什么還要在業(yè)務「前臺」API層打造一個「出行中臺」,這和出行業(yè)務的流量模式是分不開的。

          1.1 流量模式

          1.1.1 傳統(tǒng)和業(yè)界常規(guī)的“錐狀”流量分配模式

          傳統(tǒng)的典型中臺架構(gòu)是“大中臺小前臺”,造就這種架構(gòu)的原因與流量分配模式相關。以電商領域為例,中臺抽象了電商相關的業(yè)務實體如:訂單、收銀臺、商品等,而不同業(yè)務線之間的流量入口是分開的,不同BU間能夠以小前臺的方式閉環(huán)實現(xiàn)。這種“大中臺小前臺”的架構(gòu),可以支持快速構(gòu)建原型產(chǎn)品進行試錯探索,中臺提供電商標準的基礎能力,前臺各自閉合實現(xiàn)B2C、C2C等業(yè)務,而業(yè)務間互不影響。

          流量分配模式表現(xiàn)為:多業(yè)務(或品類)開放的前臺流量接入,轉(zhuǎn)化至統(tǒng)一有限的業(yè)務中臺,最終落至基礎平臺。


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

          滴滴網(wǎng)約車業(yè)務核心是打車,為了滿足不同用戶的需求(定價、應答率、體驗等),通過品類區(qū)分提供差異化服務能力,從最初的出租車、專車、快車延展到了如今幾十個品類。而入口始終圍繞在司乘兩端、開放平臺。

          流量分配模式表現(xiàn)為:多品類由統(tǒng)一的端接入流量入口(API)并完成各品類的主要業(yè)務邏輯處理,再交由統(tǒng)一的業(yè)務中臺,最終落至基礎平臺


          網(wǎng)約車的「菱形」流量分配模式注定:服務端API一方面需要支持一些跨BU的平臺級需求,如:春節(jié)服務費、疫情停開服等;另一方面也要支持不同BU間的差異化需求,如出租車使用打表計價不用線上計價等。

          隨著品類越來越豐富,這些差異邏輯也越來越多,導致系統(tǒng)越來越臃腫,復雜度越來越高,迭代效率下降。所以需要將服務端API通用的部分下沉,并且開放差異定制的機制,同時兼顧隔離和復用,灣流平臺項目應運而生。

          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)

          1.0階段主要解決的是快速增加新品類和不同BU間代碼隔離的問題,使用配置化插件化解決。配置化主要是統(tǒng)一了上下游產(chǎn)品描述協(xié)議,形成產(chǎn)品描述N元組,并抽象一套通用的N元組到功能的映射規(guī)則;插件化利用插件包隔離不同BU間的代碼,運行時插件選擇器根據(jù)流量特征分發(fā)到對應插件包。


          ◎ 遺留問題
           
          1. 配置化依賴于功能抽象,需要一套統(tǒng)一的抽象方法

          2. 插件化依賴于穩(wěn)固的流程,以及清晰的功能邊界。按差異開放插件點會導致插件定義不明確、粒度無法把控、插入點不穩(wěn)定等問題,長期維護困難。

          1.3.2 灣流平臺2.0(2018)

          2.0一方面要解決1.0遺留的功能抽象、流程固化等問題,一方面還要面臨復雜度越來越高的服務端api系統(tǒng)。為此我們借鑒了DDD的思路,開啟了灣流平臺2.0的改造。

          • 宏觀上,根據(jù)核心數(shù)據(jù)&職能對服務進行了拆分,將一個大模塊拆分成多個垂直閉環(huán)的子模塊,即領域化。通過分治的方式,降低了整體的復雜度,同時也解決了所有團隊成員在一個模塊開發(fā)導致的上線沖突和排隊情況。


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


          ◎ 遺留問題

          1. 未做系統(tǒng)性的框架約束,迭代容易破壞原有結(jié)構(gòu)

          2. 側(cè)重于分治和抽象,未同步考慮品類間隔離問題


          2. 
          灣流平臺3.0詳細方案
          2.1 總體思路



          前面也提到,灣流平臺核心要解決隔離和復用的問題。3.0整體思路是把服務端API的業(yè)務邏輯分為兩層,一層是用于串接狀態(tài)流轉(zhuǎn)的流程層,一層是用于完成各個垂類功能的能力組件層。流程層既包含從預估、發(fā)單到完單的宏觀打車流程,也包含每個接口的執(zhí)行流程。宏觀的打車流程基本品類間是統(tǒng)一的,與端的交互協(xié)議也是統(tǒng)一的;每個接口執(zhí)行流程不同品類間由于業(yè)務形態(tài)差異,會有部分不一致。我們把接口的執(zhí)行流程做環(huán)節(jié)抽象,形成一個個的step,沉淀一套接口標準通用的執(zhí)行step,品類可以根據(jù)各自的差異,重載step。

          能力組件抽象聚合了一些垂直的功能,組件內(nèi)部按照策略模式,根據(jù)不同的品類場景使用不同的策略完成組件行為。如播單組件,提供了延遲播單、實時播單、輪次播單等模式,專車預約采用延遲播單,這種是在播單組件中通過配置實現(xiàn)。如果一些有特別大的差異,比如出租車要實現(xiàn)一個全新的播單模式并且不具備通用性,也可以由出租車實現(xiàn)這個新的模式,通過插件的形式掛載進來。

          經(jīng)過這樣改造之后,同時配套誕生了一些平臺產(chǎn)品,輔助提高開發(fā)效率。如流程編排中心,可以根據(jù)不同的品類場景,對接口流程環(huán)節(jié)進行編排;特征管理平臺,統(tǒng)一管控業(yè)務特征,保持業(yè)務描述統(tǒng)一;品類配置中心,從品類場景視角,配置不同能力的行為模式,快速上線新品類場景。

          2.2 框架介紹

          為了實現(xiàn)總體思路,我們開發(fā)了一套代碼運行框架,命名為DuKang,何以解憂,唯有DuKang!依托DuKang框架,解決我們隔離和復用的難題。

          DuKang框架,針對每個接口,按照下圖流程執(zhí)行調(diào)度,涉及InputSource、Transport、TransportFactor、StepRuntime、Step、Ability等核心概念。


          其中核心的要點是,Transport作為流程承載器,提供了一個base的基礎流程實現(xiàn),不同品類可繼承BaseTransport,然后可以針對差異的流程環(huán)節(jié)step進行重載,但整個流程是由流程驅(qū)動引擎調(diào)度,各品類保持一致。ability是能力組件,組件內(nèi)部提供了一組通用的mode,不同品類場景通過配置化方式復用這些mode,同時也向業(yè)務開放了定制mode的機制,業(yè)務可以通過使用biz定制自己獨有的mode,掛載到ability下,實現(xiàn)差異化功能。

          服務端API語言棧以php和golang為主,其中老的服務主要是用php寫的,整體逐步在往golang上遷移,新服務都是直接采用的golang。Dukang框架同時支持了php和golang兩個版本,下面以php版本,成單接口為例,展示dukang框架的運行過程:

          //配置文件,管理流程環(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的一些核心概念進行講解


          2.2.1 Transport - 業(yè)務傳輸器/承載器

          ◎ 定義

          • 針對單接口內(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è)務特征概念歸納


          • 業(yè)務表達:播單計劃 =  $sStartAddDuseTime + $bIsDelayBroadcast + $bIsRepeatAssign+ $iBroadcastAssignType + $iBroadcastExpire

          ◎ 業(yè)務特征解決的問題

          • 規(guī)范業(yè)務屬性或字段語義,避免歧義和未知語義

          • 定義:業(yè)務 = 有序流程 * 控制(特征X, 特征Y, 特征Z, ...), 控制 = 染色 | 填充 | 復寫  |  合并  |  標記

          2.2.6.3 能力組件抽取過程

          針對一組業(yè)務特征,將圍繞這些業(yè)務特征的生產(chǎn)、修改操作聚合,形成能力組件。如圍繞播單特征的播單組件、價格特征的計價組件等等

          ◎ Ability擴展性

          支持以Addtional 的業(yè)務擴展Ability Mode,即前面提到的biz形式定制化mode,從而達到不同品類在Ability上的隔離。

          ◎ Ability+品類場景配置最終思路

          復用:基于品類+場景(N元組)配置化,mode selector靈活決策能力組件的執(zhí)行模式
          差異化:業(yè)務通過biz實現(xiàn)mode的定制,配置化動態(tài)加載


          2.3 應用框架目錄結(jié)構(gòu)

          php模塊目錄結(jié)構(gòu)示例,golang模塊整體類似

          // 模塊根目錄├── 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é)束 —


          ● 漫談設計模式在 Spring 框架中的良好實踐

          ● 顛覆微服務認知:深入思考微服務的七個主流觀點

          ● 人人都是 API 設計者

          ● 一文講透微服務下如何保證事務的一致性

          ● 要黑盒測試微服務內(nèi)部服務間調(diào)用,我該如何實現(xiàn)?



          關注我,回復 「加群」 加入各種主題討論群。



          對「服務端思維」有期待,請在文末點個在看

          喜歡這篇文章,歡迎轉(zhuǎn)發(fā)、分享朋友圈


          在看點這里
          瀏覽 309
          點贊
          評論
          1收藏
          分享

          手機掃一掃分享

          分享
          舉報
          評論
          圖片
          表情
          推薦
          點贊
          評論
          1收藏
          分享

          手機掃一掃分享

          分享
          舉報
          <kbd id="afajh"><form id="afajh"></form></kbd>
          <strong id="afajh"><dl id="afajh"></dl></strong>
            <del id="afajh"><form id="afajh"></form></del>
                1. <th id="afajh"><progress id="afajh"></progress></th>
                  <b id="afajh"><abbr id="afajh"></abbr></b>
                  <th id="afajh"><progress id="afajh"></progress></th>
                  日韩成人电影在线观看 | 67194久久 | 亚洲天堂在线视频 | 成人无码做爱视频 | 自拍偷拍激情网 |