1. <strong id="7actg"></strong>
    2. <table id="7actg"></table>

    3. <address id="7actg"></address>
      <address id="7actg"></address>
      1. <object id="7actg"><tt id="7actg"></tt></object>

        滴滴出行平臺(tái)業(yè)務(wù)架構(gòu)演進(jìn)

        共 8300字,需瀏覽 17分鐘

         ·

        2021-06-02 04:42

        點(diǎn)擊上方“服務(wù)端思維”,選擇“設(shè)為星標(biāo)

        回復(fù)”669“獲取獨(dú)家整理的精選資料集

        回復(fù)”加群“加入全國(guó)服務(wù)端高端社群「后端圈」


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

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

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

        1.1 流量模式

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

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

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


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

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

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


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

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

        1.2 服務(wù)端API職責(zé)定位

        在開始前,需要先明確服務(wù)端API的核心職責(zé)。

        ◎ 核心職責(zé)


        • 流量染色:識(shí)別和定義接入流量中的品類、場(chǎng)景、功能,并轉(zhuǎn)義標(biāo)識(shí)為統(tǒng)一的業(yè)務(wù)特征。

        • 流程串接:根據(jù)不同事件/請(qǐng)求按照相應(yīng)的邏輯和流程調(diào)用下游服務(wù),以完成具體的功能。

        • 數(shù)據(jù)渲染:將處理結(jié)果數(shù)據(jù)按不同的端或品類/場(chǎng)景要求渲染成對(duì)應(yīng)的數(shù)據(jù)視圖。

        ◎ 終極問題

        • 復(fù)用:what(復(fù)用什么,復(fù)用到什么級(jí)別), how(怎么實(shí)現(xiàn)復(fù)用)

        • 隔離:what(隔離的是什么),how(隔離機(jī)制是什么)

        1.3 灣流平臺(tái)演進(jìn)

        在過去幾年時(shí)間里,基于上述背景我們一直在不斷探索,以下簡(jiǎn)單介紹下灣流平臺(tái)項(xiàng)目前兩個(gè)版本迭代的情況。

        1.3.1 灣流平臺(tái)1.0(2017-2018)

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


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

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

        1.3.2 灣流平臺(tái)2.0(2018)

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

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


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


        ◎ 遺留問題

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

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


        2. 
        灣流平臺(tái)3.0詳細(xì)方案
        2.1 總體思路



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

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

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

        2.2 框架介紹

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

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


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

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

        //配置文件,管理流程環(huán)節(jié),以及提供給不同品類注冊(cè)各自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": "確認(rèn)行程信息"    },    {      "step_id": "confirmBillStep",      "description": "確認(rèn)計(jì)價(jià)信息"    },    {      "step_id": "checkStep",      "description": "成單檢查"    },    {      "step_id": "fillOrderDetailStep",      "description": "訂單維度填充"    },    {      "step_id": "sendOrderCommandStep",      "description": "訂單處理操作"    },    {      "step_id": "sendDriverCommandStep",      "description": "司機(jī)處理操作"    },    {      "step_id": "sendSchedulingCommandStep",      "description": "調(diào)度處理操作"    },    {      "step_id": "buildResponseStep",      "description": "構(gòu)建響應(yīng)"    },    {      "step_id": "asyncOperationStep",      "description": "異步操作"    },    {      "step_id": "writeLogStep",      "description": "日志處理"    }  ]}
        // dukang框架核心執(zhí)行過程try { // 加載并解析接口配置,包括BizConfig、StepConfig $oBizConf = BizConfig::load($sConfigStr);
        // 獲取輸入源數(shù)據(jù),包括Request和基礎(chǔ)數(shù)據(jù)獲取 $oInputSource = new ConfirmOrdernputSource();
        // 構(gòu)造StepRuntime $oStepRuntime = new ConfirmOrdertepRuntime($oInputSource);
        // 將接口配置對(duì)象、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);}

        接下來,再展開對(duì)dukang的一些核心概念進(jìn)行講解


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

        ◎ 定義

        • 針對(duì)單接口內(nèi)不同運(yùn)力(或品類)進(jìn)行抽象得來的流程載體

        • 任一業(yè)務(wù)必有其承載的流程和執(zhí)行順序

        ◎ 約束

        • BaseTransport覆蓋當(dāng)前接口業(yè)務(wù)的通用流程

          • 任一接口內(nèi)有且只有一個(gè)BaseTransport

        • XxxTransport覆蓋不同運(yùn)力(或品類)的差異化實(shí)現(xiàn)

          • 任一接口內(nèi)的差異化XxxTransport必須繼承自BaseTransport

          • 任一Transport至少包含一個(gè)StepTransport <=> [N]Step (N >= 1)

        2.2.2 Step - 流程環(huán)節(jié)

        ◎ 定義

        • 針對(duì)單接口內(nèi)的業(yè)務(wù)進(jìn)行抽象出來的環(huán)節(jié)載體

        • 單一Step是某一段業(yè)務(wù)環(huán)節(jié)或功能的具體實(shí)現(xiàn)

        ◎ 特性

        • 單一Step是大粒度差異化(如豪華車/出租車)的有效手段, 可通過Override Step實(shí)現(xiàn)

        • Step間的通信通過統(tǒng)一運(yùn)行時(shí)數(shù)據(jù)總線StepRuntime串聯(lián),理論上可實(shí)現(xiàn)熱拔插

        ◎ 圖例

        • 業(yè)務(wù)流程驅(qū)動(dòng)型接口:以串聯(lián)各個(gè)處理流程為主

        • 數(shù)據(jù)驅(qū)動(dòng)型接口:以構(gòu)建業(yè)務(wù)特征數(shù)據(jù)為主


        2.2.3 StepRuntime - 運(yùn)行時(shí)數(shù)據(jù)總線

        ◎ 定義

        • 流程串聯(lián)運(yùn)行時(shí)數(shù)據(jù)總線

        ◎ 約束

        • StepRuntime只能作為Ability的輸入,不能在Ability及下層邏輯中對(duì)StepRuntime的業(yè)務(wù)特征和數(shù)據(jù)進(jìn)行修改

        ◎ 圖例


        2.2.4 InputSource - 輸入源

        ◎ 定義

        • 外部輸入數(shù)據(jù)源,為TransportFactor準(zhǔn)備數(shù)據(jù)

        • 用于消除外部執(zhí)行環(huán)境差異化,隔離外部入?yún)?/span>

        ◎ 約束

        • 進(jìn)入Step之后具有只讀屬性,被StepRuntime引用,后續(xù)業(yè)務(wù)邏輯不可修改其包含的所有特征及數(shù)據(jù)內(nèi)容

        ◎ 圖例


        2.2.5 Transport Factor - 傳輸器因子

        ◎ 定義

        • 業(yè)務(wù)傳輸器Transport決策因子

        • 不同接口可能會(huì)采取不同的因子進(jìn)行Transport決策

          • 目前實(shí)現(xiàn)的有針對(duì)訂單維度product_id,針對(duì)司機(jī)維度car_level

          • 可選擇端來源作為決策因子,如滴滴出行app、開放平臺(tái)、禮橙專車app等

        ◎ 約束

        • Factor必須是確定可選擇的幾類因子,不能由RD同學(xué)自由編寫

        • 同類業(yè)務(wù)接口原則上TransportFactor要盡量保持一致

        2.2.6 Ability - 能力組件

        2.2.6.1 概念描述


        ◎ 定義

        • 以特征數(shù)據(jù)為視角,對(duì)聚焦業(yè)務(wù)進(jìn)行提煉和抽象,形成能力組件

        ◎ 設(shè)計(jì)原則

        • 面向可復(fù)用設(shè)計(jì)

        • 面向可擴(kuò)展差異化設(shè)計(jì)

        2.2.6.2 業(yè)務(wù)特征

        ◎ 業(yè)務(wù)特征概念歸納


        • 業(yè)務(wù)表達(dá):播單計(jì)劃 =  $sStartAddDuseTime + $bIsDelayBroadcast + $bIsRepeatAssign+ $iBroadcastAssignType + $iBroadcastExpire

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

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

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

        2.2.6.3 能力組件抽取過程

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

        ◎ Ability擴(kuò)展性

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

        ◎ Ability+品類場(chǎng)景配置最終思路

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


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

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

        // 模塊根目錄├── Dukang // 新引入的內(nèi)容,區(qū)隔老代碼,未來將替代hermes│   ├── Ability // 能力目錄│   │   ├── Common // 公用能力│   │   │   ├── DispatchOrder│   │   │   │   └── DispatchOrderComponent.php│   │   │   └── VirtualPhone│   │   │       └── VirtualPhoneComponent.php│   │   └── Express // 品類特有能力擴(kuò)展│   │       └── DispatchOrder│   │           └── DispatchOrderComponent.php│   ├── Config // 接口配置│   │   └── ConfirmOrder.json│   ├── InputSource // 接口輸入│   │   └── ConfirmOrderInputSource.php│   ├── StepRuntime // 全局?jǐn)?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,標(biāo)準(zhǔn)dto)            └── src  // 框架代碼

        — 本文結(jié)束 —


        ● 漫談設(shè)計(jì)模式在 Spring 框架中的良好實(shí)踐

        ● 顛覆微服務(wù)認(rèn)知:深入思考微服務(wù)的七個(gè)主流觀點(diǎn)

        ● 人人都是 API 設(shè)計(jì)者

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

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



        關(guān)注我,回復(fù) 「加群」 加入各種主題討論群。



        對(duì)「服務(wù)端思維」有期待,請(qǐng)?jiān)谖哪c(diǎn)個(gè)在看

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


        在看點(diǎn)這里
        瀏覽 309
        點(diǎn)贊
        評(píng)論
        1收藏
        分享

        手機(jī)掃一掃分享

        分享
        舉報(bào)
        評(píng)論
        圖片
        表情
        推薦
        點(diǎn)贊
        評(píng)論
        1收藏
        分享

        手機(jī)掃一掃分享

        分享
        舉報(bào)
        1. <strong id="7actg"></strong>
        2. <table id="7actg"></table>

        3. <address id="7actg"></address>
          <address id="7actg"></address>
          1. <object id="7actg"><tt id="7actg"></tt></object>
            男人的天堂伊人 | 日韩高清无码一区二区三区 | 免费看60分钟高潮v片视频 | 成人毛片在线播放 | 人人色人人看 | 日本性色爽歪歪网 | 国产乱伦一级aa视频 | 操骚B| 国产丝袜91久久久久久久久久久 | 乱轮毛片 |