導(dǎo)讀

由于網(wǎng)約車業(yè)務(wù)本身的復(fù)雜性以及我們垂直式的領(lǐng)域化架構(gòu)約束，網(wǎng)約車服務(wù)端技術(shù)團(tuán)隊(duì)在對端渲染業(yè)務(wù)需求的迭代過程中，碰到了一系列的問題，影響了研發(fā)效率。本文從這些具體問題入手，分析產(chǎn)生的原因，介紹我們的解決思路和方案，以及方案的建設(shè)落地過程。

1. 服務(wù)端架構(gòu)演進(jìn)回顧

過去幾年，滴滴網(wǎng)約車為了滿足不同用戶的個(gè)性化出行需求，逐步推出了越來越豐富的品類和功能。隨著品類功能的不斷增加，我們系統(tǒng)的復(fù)雜度也越來越高，為了應(yīng)對這一挑戰(zhàn)，網(wǎng)約車服務(wù)端技術(shù)團(tuán)隊(duì)構(gòu)建了一個(gè)「出行平臺(tái)」，內(nèi)部又稱灣流平臺(tái)。灣流平臺(tái)的演進(jìn)主要經(jīng)過了以下幾個(gè)階段。

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

在1.0階段，滴滴網(wǎng)約車的主要業(yè)務(wù)重心是豐富品類，為用戶提供更多選擇，其中包括專車、豪華車、優(yōu)享等。在這個(gè)階段，灣流平臺(tái)還是一個(gè)單體服務(wù)，主要面臨的挑戰(zhàn)是如何快速新增品類并支持多品類之間的差異化開發(fā)。

為了應(yīng)對這些挑戰(zhàn)，我們引入了配置化和插件化。配置化使得新增品類可以快速上線并進(jìn)行復(fù)用，提高開發(fā)效率。插件化則能夠隔離不同品類之間的差異邏輯，確保各品類的獨(dú)立性和靈活性

灣流平臺(tái)2.0（2018-2020）

在2.0階段，隨著品類的不斷豐富和個(gè)性化功能的增加，開發(fā)團(tuán)隊(duì)也不斷壯大，系統(tǒng)規(guī)模逐漸龐大，但日常的迭代效率和穩(wěn)定性出現(xiàn)了明顯下降。為了解決這些問題，我們從兩個(gè)方向?qū)沉髌脚_(tái)進(jìn)行了改造。

首先，按照領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（DDD）的思路，對單體服務(wù)進(jìn)行了拆分，降低整體系統(tǒng)的復(fù)雜度，同時(shí)也解決了團(tuán)隊(duì)成員并行開發(fā)導(dǎo)致的上線沖突和排隊(duì)的問題，提高了開發(fā)效率。

其次，在領(lǐng)域服務(wù)內(nèi)部，我們進(jìn)行了功能的聚合和抽象，通過將具有相似功能的業(yè)務(wù)進(jìn)行聚合，并對其進(jìn)行抽象，可以避免功能的重復(fù)開發(fā)，進(jìn)一步提高了開發(fā)效率和代碼的可維護(hù)性。

灣流平臺(tái)3.0（2020-至今）

在3.0階段，我們開發(fā)了一套名為DuKang的業(yè)務(wù)框架，它將API的業(yè)務(wù)邏輯分為兩個(gè)層次。首先是流程層，用于串接狀態(tài)流轉(zhuǎn)，提供了通用的流程實(shí)現(xiàn)，不同的品類可以根據(jù)自身需求定制自己的流程，以滿足差異化的業(yè)務(wù)要求。

其次是能力組件層，負(fù)責(zé)完成各個(gè)垂類功能。組件內(nèi)使用策略模式實(shí)現(xiàn)不同的行為，例如播單組件內(nèi)部提供了延遲播單、實(shí)時(shí)播單等不同方式，不同的品類可以根據(jù)自己的需求選擇適合自己的方式。同時(shí)，組件也支持插件機(jī)制，可以讓品類注入獨(dú)有的模式。

通過Dukang框架，我們能夠有效約束各服務(wù)系統(tǒng)的實(shí)現(xiàn)，保持統(tǒng)一的規(guī)范，讓不同的領(lǐng)域服務(wù)可以復(fù)用能力組件，提高開發(fā)效率和代碼的復(fù)用性。

灣流平臺(tái)詳細(xì)的建設(shè)思路，可以參考之前的文章「滴滴出行平臺(tái)業(yè)務(wù)架構(gòu)演進(jìn)」，系統(tǒng)的架構(gòu)簡單示例如下：

2. 新問題和挑戰(zhàn)

在討論新問題挑戰(zhàn)之前，我們先統(tǒng)一一些基本概念。

頁面：指用戶在終端上看到的整體區(qū)域，包含各種UI控件，例如打開app看到的乘客首頁、司機(jī)接單后趕來的等待接駕頁等。

組件：頁面中獨(dú)立展示的功能區(qū)塊，通常具有特定的業(yè)務(wù)屬性，例如下圖的小助手組件，主要用于展示當(dāng)前場景下的一些重要業(yè)務(wù)提示和部分營銷活動(dòng)。

模板：組件內(nèi)的不同UI展示樣式，依賴于組件的定義和存在。

功能：表示一些具體的業(yè)務(wù)場景，例如保障車隊(duì)功能、自選車功能等。

數(shù)據(jù)源：提供組件渲染數(shù)據(jù)的后端服務(wù)接口。

在灣流平臺(tái)的持續(xù)建設(shè)過程中，渲染類需求的迭代效率始終上不去，經(jīng)過進(jìn)一步的深入分析，我們發(fā)現(xiàn)雖然領(lǐng)域服務(wù)能夠通過能力層實(shí)現(xiàn)功能邏輯的復(fù)用，但在做對端的渲染邏輯時(shí)出現(xiàn)了一些問題。不同位置的組件是由不同領(lǐng)域服務(wù)負(fù)責(zé)的，而這些領(lǐng)域服務(wù)各自有自己的渲染規(guī)范，因此，同一個(gè)功能想要在不同組件上進(jìn)行展示時(shí)，就需要按照這些組件的渲染規(guī)范進(jìn)行適配，例如有的組件要求直接通過接口返回渲染數(shù)據(jù)，而有些則要求在平臺(tái)上進(jìn)行數(shù)據(jù)配置，這就導(dǎo)致一個(gè)功能在渲染對接上需要花費(fèi)大量成本。同時(shí)，除了服務(wù)端系統(tǒng)內(nèi)部的問題外，還有一些外部溝通協(xié)作、數(shù)據(jù)開發(fā)等挑戰(zhàn)。

下圖是當(dāng)前系統(tǒng)內(nèi)渲染處理現(xiàn)狀，具體的問題可以結(jié)合下圖進(jìn)行討論。

多端問題

滴滴涵蓋了多個(gè)終端，包括Android、iOS和小程序等。由于我們劃分了不同的領(lǐng)域服務(wù)，每個(gè)領(lǐng)域服務(wù)都需要直接向終端提供相關(guān)展示數(shù)據(jù)，例如，售賣領(lǐng)域服務(wù)提供首頁相關(guān)數(shù)據(jù)，交易撮合領(lǐng)域服務(wù)提供等待應(yīng)答頁的相關(guān)數(shù)據(jù)等。然而，這就導(dǎo)致了所有領(lǐng)域服務(wù)需要同時(shí)與所有終端進(jìn)行對接，增加了溝通和協(xié)作的成本，影響迭代效率。

同時(shí)，網(wǎng)約車產(chǎn)品在大多數(shù)情況下要求多終端的體驗(yàn)保持一致，然而，由于各端獨(dú)立開發(fā)和實(shí)現(xiàn)，又沒有地方統(tǒng)一進(jìn)行管控，導(dǎo)致不一致的問題經(jīng)常出現(xiàn)。例如，相同的標(biāo)簽展示內(nèi)容在長度超過限制時(shí)，iOS會(huì)截?cái)嗾故?，而Android則采用跑馬燈展示等。多端實(shí)現(xiàn)不一致同樣也會(huì)影響我們的迭代效率，例如當(dāng)產(chǎn)品希望對線上展示內(nèi)容進(jìn)行動(dòng)態(tài)更換時(shí)，由于各端實(shí)現(xiàn)不同，導(dǎo)致動(dòng)態(tài)化能力參差不齊，產(chǎn)品不得不針對各端進(jìn)行差異化實(shí)現(xiàn)；還有同一個(gè)功能上線后，由于各端埋點(diǎn)實(shí)現(xiàn)不一致，收集的數(shù)據(jù)差異很大，每次都需要排查原因，甚至需要為不同端制定不同的數(shù)據(jù)分析策略。總之多端一致有利于產(chǎn)品體驗(yàn)的提升，也能提升效率。

渲染邏輯管理困難

端上的組件位置是有限的，但是功能卻是不斷累積的，這導(dǎo)致在一個(gè)組件上需要根據(jù)不同的業(yè)務(wù)場景，展示不同的內(nèi)容。經(jīng)過統(tǒng)計(jì)，一些熱點(diǎn)組件上，擁有四五十種展示形式，上百種展示場景，面對如此復(fù)雜的情況，流量分發(fā)、優(yōu)先級排序等管理十分復(fù)雜，而且所有的領(lǐng)域服務(wù)都需要重復(fù)實(shí)現(xiàn)這些復(fù)雜的邏輯，存在大量的重復(fù)工作。

功能跨流程接入難

有很多功能需要在全流程進(jìn)行透出感知，比如拼車權(quán)益卡，在冒泡、等待應(yīng)答、行程結(jié)束等很多階段都需要進(jìn)行感知透出，這些階段的頁面由不同的領(lǐng)域服務(wù)處理，這些服務(wù)又歸屬于不同的團(tuán)隊(duì)，在渲染接入上都有自己獨(dú)立的一套規(guī)范，導(dǎo)致拼車權(quán)益這樣一個(gè)功能接入跨流程的展示時(shí)，需要和不同的領(lǐng)域服務(wù)進(jìn)行對接，而且需要進(jìn)行逐一適配，接入成本很高。

數(shù)據(jù)看清難

各個(gè)組件的前后端埋點(diǎn)都是由不同團(tuán)隊(duì)的開發(fā)同學(xué)進(jìn)行自定義實(shí)現(xiàn)，缺乏統(tǒng)一的規(guī)范，下圖以拼車權(quán)益示例，可以看到，雖然各個(gè)位置都有埋點(diǎn)，但是大家的規(guī)范都不一樣，想要把這些數(shù)據(jù)串起來非常的困難，每次要看數(shù)據(jù)時(shí)，都需要數(shù)據(jù)產(chǎn)品單獨(dú)提需求進(jìn)行開發(fā)實(shí)現(xiàn)，周期長，成本也很高。

以上就是我們在渲染上遇到的一系列問題，從上面的問題中可以看到，當(dāng)前架構(gòu)中最核心的問題，是系統(tǒng)各個(gè)層級間缺乏統(tǒng)一的渲染標(biāo)準(zhǔn)和規(guī)范，導(dǎo)致出現(xiàn)了很多的重復(fù)工作以及相互間信息打不通，主要可以歸納為這三個(gè)方面：

前端 & 后端：如何構(gòu)建統(tǒng)一的組件認(rèn)知，如何保證多端一致，如何減少多終端的協(xié)作成本。

后端：如何管理組件內(nèi)復(fù)雜的功能展示邏輯，如何保證單一功能在全流程進(jìn)行感知時(shí)，可以快速接入。

數(shù)據(jù) & 前端 & 后端：如何建設(shè)統(tǒng)一的前后端數(shù)據(jù)規(guī)范，如何快速看清數(shù)據(jù)

3. 解決思路

解決這幾個(gè)問題的核心思路是進(jìn)行標(biāo)準(zhǔn)化，通過不同層次的標(biāo)準(zhǔn)化配合，形成一套統(tǒng)一的跨端渲染平臺(tái)，詳細(xì)的方案思路如下所示。

組件標(biāo)準(zhǔn)化

組件標(biāo)準(zhǔn)化的思路是將我們頁面按功能模塊劃分成不同的組件，然后對這些組件進(jìn)行UI規(guī)范和數(shù)據(jù)交互協(xié)議的統(tǒng)一，各端再根據(jù)統(tǒng)一的UI規(guī)范和交互協(xié)議進(jìn)行組件的開發(fā)，同時(shí)在研發(fā)流程和研發(fā)模式上進(jìn)行管控，讓各終端架構(gòu)層面保持統(tǒng)一，盡可能地實(shí)現(xiàn)各端體驗(yàn)的一致。針對多端實(shí)現(xiàn)一致的問題，Android和IOS也在探索跨端技術(shù)等方式，本文不對此展開。

有了這些多端統(tǒng)一的標(biāo)準(zhǔn)化組件之后，為了實(shí)現(xiàn)組件的復(fù)用以及減少終端和后端的溝通協(xié)作成本，我們建設(shè)了組件管理平臺(tái)和渲染網(wǎng)關(guān)。終端研發(fā)在管理平臺(tái)上對頁面進(jìn)行配置，配置頁面上有哪些組件，這些組件通過什么樣的形式進(jìn)行布局，組件的數(shù)據(jù)從哪來等等。有了這些配置之后，終端進(jìn)行頁面渲染時(shí)，不再和各個(gè)組件下游服務(wù)交互，而是和渲染網(wǎng)關(guān)進(jìn)行交互，渲染網(wǎng)關(guān)會(huì)根據(jù)終端傳入的頁面標(biāo)識(shí)，在配置后臺(tái)拿到對應(yīng)頁面的配置，代理請求下游服務(wù)，拿到各組件的數(shù)據(jù)統(tǒng)一進(jìn)行下發(fā)。通過這樣的形式，可以有效地減少終端和各后端的溝通協(xié)作成本，同時(shí)這種標(biāo)準(zhǔn)化構(gòu)建的組件，可以很方便地進(jìn)行跨頁面的復(fù)用，提升迭代效率。

組件標(biāo)準(zhǔn)化除了對開發(fā)的收益之外，對產(chǎn)品業(yè)務(wù)同樣有很大的幫助，之前的產(chǎn)品迭代過程缺乏集中的沉淀，導(dǎo)致每次新功能需要做展示時(shí)，即使展示樣式跟之前的功能很類似，但由于沒有地方查閱，依然會(huì)找UI重新設(shè)計(jì)，研發(fā)重新開發(fā)實(shí)現(xiàn)。這也是導(dǎo)致一個(gè)組件上展示樣式爆炸式增長的主要原因。進(jìn)行標(biāo)準(zhǔn)化之后，產(chǎn)品業(yè)務(wù)能夠在平臺(tái)上看到組件上當(dāng)前所有的展示樣式，新功能可以選擇復(fù)用之前的模板，提升研發(fā)效率，同時(shí)也能集中對組件和模板進(jìn)行管控，保持體驗(yàn)的統(tǒng)一。

通過組件的標(biāo)準(zhǔn)化，整體的需求開發(fā)模式變成了如下的形式：

組件標(biāo)準(zhǔn)化建設(shè)過程，主要是渲染網(wǎng)關(guān)和組件管理平臺(tái)的建設(shè)，下面重點(diǎn)展開介紹下這兩部分的詳細(xì)方案：

渲染網(wǎng)關(guān)

渲染網(wǎng)關(guān)主要提供了兩個(gè)接口，layout接口和data接口，layout接口負(fù)責(zé)下發(fā)頁面的布局信息，包括頁面的一些靜態(tài)配置以及有哪些組件等信息，data接口則負(fù)責(zé)獲取組件渲染所需的數(shù)據(jù)。在實(shí)際運(yùn)行過程中，考慮到性能和體驗(yàn)的問題，在layout接口，會(huì)將核心組件的數(shù)據(jù)也進(jìn)行返回，端上拿到layout的數(shù)據(jù)之后就能夠進(jìn)行頁面的渲染，對于頁面上一些非核心可異步加載的組件，端上在拿到layout數(shù)據(jù)后，會(huì)再請求data接口獲取這些組件的數(shù)據(jù)。詳細(xì)的交互如下所示。

組件管理平臺(tái)

組件管理平臺(tái)主要是提供一個(gè)配置后臺(tái)，管理組件相關(guān)的內(nèi)容，主要功能包括：

頁面管理，管理頁面標(biāo)識(shí)和頁面組件關(guān)系等，可以在頁面管理里配置對應(yīng)頁面包含哪些組件，并且可以進(jìn)行一些組件實(shí)驗(yàn)和灰度的配置，頁面也提供了版本管理的能力。

組件管理，對組件進(jìn)行定義，并且對組件的模板進(jìn)行管理，包括模板的UI規(guī)范、IDL交互協(xié)議等。

數(shù)據(jù)源管理，對下游數(shù)據(jù)源進(jìn)行注冊、參數(shù)映射轉(zhuǎn)換等，組件在注冊到頁面時(shí)會(huì)配置對應(yīng)的數(shù)據(jù)源，這樣網(wǎng)關(guān)就能根據(jù)配置直接代理請求拿到組件數(shù)據(jù)。

組件全景圖，為產(chǎn)品業(yè)務(wù)打造的組件視圖，業(yè)務(wù)和產(chǎn)品可以在上面追蹤到當(dāng)前app有哪些頁面，每個(gè)頁面上是由哪些組件組成，每個(gè)組件上支持哪些展示樣式，也能看到有哪些功能會(huì)在這個(gè)組件下進(jìn)行展示，這些功能的流量是如何分配的。

除了上面提到的核心管理能力外，管理平臺(tái)在開發(fā)體驗(yàn)上也提供了一些能力，比如多版本功能，可以實(shí)現(xiàn)類似git的多分支并行配置開發(fā)測試；網(wǎng)關(guān)接口文檔和mock能力，由于所有組件交互協(xié)議是托管在平臺(tái)上的，平臺(tái)會(huì)基于此實(shí)現(xiàn)接口文檔和下游組件數(shù)據(jù)的mock功能，提高開發(fā)聯(lián)調(diào)效率。

功能接入標(biāo)準(zhǔn)化

功能接入標(biāo)準(zhǔn)化的主要思路是統(tǒng)一一套標(biāo)準(zhǔn)的渲染處理邏輯，不同領(lǐng)域服務(wù)進(jìn)行接入使用，這樣不僅能夠減少領(lǐng)域服務(wù)間的重復(fù)建設(shè)，也能夠讓功能接入方式統(tǒng)一，不再需要進(jìn)行適配。為了統(tǒng)一渲染處理邏輯，我們在Dukang框架基礎(chǔ)上擴(kuò)充了渲染框架能力，將渲染流程固化為上下文構(gòu)建->功能過濾->功能決策→功能渲染。其中上下文構(gòu)建是組裝渲染所需的必要上下文數(shù)據(jù)，功能過濾是根據(jù)地域、時(shí)間、品類等規(guī)則過濾掉當(dāng)前場景下不展示的功能，功能決策是對剩余的功能進(jìn)行優(yōu)先級排序，選擇最終展示的功能，功能渲染則是選中的功能進(jìn)行數(shù)據(jù)的填充。除了渲染框架以外，我們還沉淀了一些標(biāo)準(zhǔn)可復(fù)用的能力，比如開城、白名單、物料管理等等，這些能力的相關(guān)配置我們統(tǒng)一建設(shè)了功能管理平臺(tái)進(jìn)行集中管理。

下面介紹下渲染框架和功能管理平臺(tái)的詳細(xì)建設(shè)方案。

渲染框架

渲染框架主要思路是通過一套統(tǒng)一的功能執(zhí)行流程，對功能進(jìn)行標(biāo)準(zhǔn)化約束，框架限定了功能的執(zhí)行流程依據(jù)上下文構(gòu)建->功能過濾->功能決策->功能渲染，框架約束的只是執(zhí)行流程，具體邏輯依然是相關(guān)功能閉環(huán)實(shí)現(xiàn)。比如功能過濾，如果只是簡單的開城過濾，業(yè)務(wù)方可以直接使用標(biāo)準(zhǔn)的開城能力；如果有一些不能抽象的復(fù)雜策略，業(yè)務(wù)方可以在自己的包中編碼實(shí)現(xiàn)。這樣既能保持功能的標(biāo)準(zhǔn)化定義，也能保持業(yè)務(wù)的靈活性。

功能管理平臺(tái)

功能管理平臺(tái)主要提供功能管理能力，平臺(tái)的主要功能如下：

功能展示策略配置，結(jié)合沉淀的城市、品類、場景等展示規(guī)則，配置不同功能對應(yīng)的展示策略

功能優(yōu)先級配置，配置組件下功能間的優(yōu)先級，優(yōu)先級支持多個(gè)分組，比如不同城市，優(yōu)先級可能是不一樣

功能文案物料配置，配置對應(yīng)功能展示所需的文案以及相關(guān)物料，這部分由于不同功能的配置方式差別很大，我們結(jié)合了內(nèi)部的一個(gè)通用配置平臺(tái)實(shí)現(xiàn)，在通用配置平臺(tái)上，rd先根據(jù)實(shí)際需求，進(jìn)行功能的文案和物料的配置模板開發(fā)，功能管理平臺(tái)和該通用配置平臺(tái)打通，將對應(yīng)的配置頁面集成進(jìn)來，形成統(tǒng)一的配置平臺(tái)。

功能全鏈路視圖，該視圖主要提供給產(chǎn)品業(yè)務(wù)使用，之前由于缺少統(tǒng)一的規(guī)范和沉淀，一個(gè)功能在哪些地方進(jìn)行了透出，各個(gè)地方的效果轉(zhuǎn)化如何，很難在一個(gè)集中的地方看到。通過我們的標(biāo)準(zhǔn)化之后，我們可以提供功能的全鏈路視圖，方便的看到每個(gè)功能在哪些組件上進(jìn)行了透出，對應(yīng)的流量分布是怎樣的，轉(zhuǎn)化漏斗如何等等。

數(shù)據(jù)標(biāo)準(zhǔn)化

對組件和功能接入進(jìn)行標(biāo)準(zhǔn)化之后，數(shù)據(jù)標(biāo)準(zhǔn)化就水到渠成了，我們只需要在每個(gè)階段的日志中，記錄前面定義的頁面、組件、模板、功能等唯一標(biāo)識(shí)，同時(shí)打通數(shù)據(jù)鏈路，按照統(tǒng)一的規(guī)范進(jìn)行數(shù)據(jù)上報(bào)、采集、清洗和聚合，就能夠形成一套標(biāo)準(zhǔn)的數(shù)據(jù)方案，在后面的功能開發(fā)過程，不需要再進(jìn)行額外的數(shù)據(jù)開發(fā)，根據(jù)組件或功能的標(biāo)識(shí)就能夠看到需要的數(shù)據(jù)。

埋點(diǎn)協(xié)議統(tǒng)一

埋點(diǎn)協(xié)議統(tǒng)一的核心就是讓不同服務(wù)的埋點(diǎn)信息能夠聚合起來，只要大家采用一套固定協(xié)議，約定好聚合的字段，通過數(shù)據(jù)采集清洗等步驟進(jìn)行聚合，就可以實(shí)現(xiàn)數(shù)據(jù)的統(tǒng)一。我們制定了前端上報(bào)、網(wǎng)關(guān)下發(fā)日志、數(shù)據(jù)源服務(wù)日志等一系列的協(xié)議，統(tǒng)一了頁面、組件、模板和功能等標(biāo)識(shí)。整體的思路如下所示，通過平臺(tái)統(tǒng)一管控埋點(diǎn)統(tǒng)一配置，各個(gè)服務(wù)利用sdk的方式對上報(bào)埋點(diǎn)進(jìn)行統(tǒng)一。

數(shù)據(jù)鏈路打通

打通從終端到后端服務(wù)的數(shù)據(jù)鏈路，通過標(biāo)準(zhǔn)的協(xié)議，將數(shù)據(jù)聚合到統(tǒng)一的數(shù)倉中，進(jìn)而形成統(tǒng)一的數(shù)據(jù)看板。主要數(shù)據(jù)鏈路示意如下所示：

總結(jié)

綜上所述，我們通過組件、功能接入和數(shù)據(jù)的標(biāo)準(zhǔn)化，完成了整個(gè)跨端統(tǒng)一渲染平臺(tái)的建設(shè)，目前該平臺(tái)還在持續(xù)建設(shè)推廣中，渲染網(wǎng)關(guān)、組件管理平臺(tái)、渲染框架、埋點(diǎn)規(guī)范等已經(jīng)建設(shè)完成，功能管理平臺(tái)、數(shù)據(jù)鏈路還在建設(shè)中。當(dāng)前該統(tǒng)一渲染平臺(tái)已經(jīng)接入了20+頁面，未來將繼續(xù)覆蓋到所有的渲染場景。

平臺(tái)的整體的系統(tǒng)架構(gòu)圖如下所示：