從滴滴出行業務中台實踐聊聊如何構建大中台架構

「

經歷了 5 年的發展，滴滴出行現已擁有 4.5 億用戶、超過 2100 萬車主，業務覆蓋 400+ 城市。

在創業初期，為了快速擁抱業務，架構的建設在體系化、完善度等方面會有所不足。隨著時間的推移，架構在可持續性、穩定性等方面不斷進步。

2017 年 12 月 1 日，在 51CTO 主辦的 WOTD 2017 全球軟體開發技術峰會主會場上，滴滴出行執行總監賴春波做了主題為《如何構建滴滴出行業務中台》的精彩演講。

從中我們可以了解到滴滴出行構建業務中台的原因及在發展過程中遇到的問題和應對的策略。

構建業務中台的四個原因

2015 年末，滴滴出行在短時間內形成了包括快車、計程車、專車、順風車、代駕等多業務的垂直化架構。隨之，滴滴啟動了中台戰略整合業務系統。

決定構建業務中台主要出於四方面考慮：專業深度、人力資源、用戶體驗、全局打通。

專業深度。由於是多業務垂直化的架構，會有多個團隊開發同樣的架構，這就需要很多的工程師。

每個團隊都是用最快速的方式構建流程，所以技術很難做深。這樣一來，導致客戶端的流暢度不高，後端不穩定，影響可擴展性。

人力資源。從原則上來說把每個團隊加到足夠的人，每個架構都能有很好的發展。但工程師的薪資都非常高，招聘大量工程師來做同樣的架構，研發成本高昂。還有些時候，即使你願意花錢，也招聘不到合適的人。

用戶體驗。流暢度、穩定性、擴展性、界面、交易流程等都是影響用戶體驗的重要因素。

在當時的組織結構和研發情況下，會出現業務的應用場景不同，交易流程卻相同的問題，這樣很影響用戶的體驗。

全局打通。所有業務本質都是出行，出行本質具有協同效應。但在各自獨立發展情況下，業務間完全沒有協同性，在構建中台過程中，我們可以逐步把協同性建立起來。

構建出行業務中台的挑戰

構建出行業務中台並不是只有好處，也一定會帶來很多問題，最大的問題是軟體複雜度。

從業務角度來說，把所有業務合併到一個體系下，本身就是很難的事，再加上滴滴出行是實時性 O2O 業務，場景差異很大，而且作為互聯網公司，不僅有很多需求不明確，還會不斷持續變化。

這種情況下，想要用一套相對穩定、相對固定的架構去支持所有業務，十分困難。

從組織角度來說，滴滴出行有多個事業部，業務涉及 400 多個城市，組織和個人的變化更快。

針對軟體複雜度的挑戰，中台制定了最基本的實現目標：在業務多元化發展的組織中，去構建一套工程架構，構建一套組織結構及對應的管理機制，以保證業務可持續的又快又好的發展。

滴滴業務中台的架構實踐

在談具體對策與實踐之前，先來看看整個業務中台的架構設計，如下圖：

整個的架構設計分幾個邊界的上下文，好處在於把相關性不強的邏輯拆開，同時在一個相關性下面，通過分層對業務進行更好的建模。

調度層作為入口去牽引多個業務線，業務流程層為調度層做服務，狀態智能層用來支持上面的兩層。

在對業務和產品進行更好建模的基礎上，進行了「五化」：服務化、非同步化、配置化、插件化、數據化。

服務化

服務化很常見，以下單為例，如下圖：

下單流程能夠調用很多服務，在多個層次，以介面層次結果進行拆解。

這裡需要提醒的是服務化要注意如下三點：

• 服務之間的協議和規範要建立好。

• 注意控制力度，力度太小、太大都會有問題。

• 隨著時間的發展，服務化本身要不斷的演進。

非同步化

對每個事件的非核心或不需要實時反饋給客戶端的邏輯進行拆解，核心的主流程會變簡潔。對非核心的邏輯在事件上做訂閱之後，進行二級處理。

以結束訂單為例，如下圖：

結束訂單的時候有很多邏輯要做，但是都是通過 MysqlBinlog 處理或 MQ 處理。

配置化

服務化和非同步化能解決很多迭代效率的問題，但由於系統、業務的複雜性，各個業務都有些差異，體現在不同的產品線、城市、區域、時間等等。

配置化的核心是對這些進行建模，把每個對象模型化，抽象成 ID，在不同的服務化里把這些可配置的能力進行抽象。

具體抽象過程，如下圖：

第一級抽象採用的是類 iptables 的規則引擎判定產品分類，第二級的規則引擎由模塊自定義。

所有配置化都是用的自生成平台，要配置什麼，自定義配置即可，這個過程是動態進行的。

當前業務中台已經可以支持上千個配置點，比如不同層次的計價規則不一樣、不同產品線的車樣子不同、不同的場景，如拼車和接送機，管控規則也不一樣等等。

插件化

配置化解決的是業務線差異問題，但如遇到邏輯差異較大的情況，就要做插件，統稱為 FPI。

在 FPI 的能力上，不同的團隊可以開發很多插件，在特定的配置點下，對它的邏輯進行載入。

真正業務流程到這兒，可以調起它對應的插件做出來。對於一些沒有差異化需求的業務，可以用開發的 default 邏輯，這是更極端的靈活性的體現。

有靈活性的體現後，團隊還可以做一些組織上的調整，原來每個服務或者平台是一個垂直化的架構，有些團隊是橫向，是 FT，有些 FT 是接送機 FT，專門做接送機的事情。

通過插件的形式在每個系統載入它的插件，它就可以跟著業務思考、跟著產品思考這個業務該怎麼走、這個產品怎麼演化。

相對的邏輯是更加專註的，這也帶來很好的組織結構對中台的適應性。

數據化

在大數據時代，數據是不得不考慮的問題，所以在業務中台，要實現全局打通，本質是要把數據打通。

所以我們制定了離線分析與在線決策的方案，如下圖：

第一個是離線做分析，可以做數據血緣、模型訓練，同時可以把它放到在線決策層面，構建很好的智能客戶引擎和交易引擎，這個可以干預，因為干預可以讓升艙或者多業務線的清單成為可能。

因為有這樣的決策，使在線服務的管控和判斷做得更加智能。

數據化方面，需要注意以下三方面：

• 讓數據更加規範和標準化。

• 構建完整的數據流，從在線到離線，從日誌到模型的在線使用。

• 引入機器學習的演算法、人工智慧的演算法去構建在線數據智能的決策。

這是業務中台的五個對策，主要解決傳統的系統架構問題，怎麼做到高耦合和內聚，怎麼提高迭代。

配置化和插件化解決靈活性問題，把靈活性開放給不同團隊。數據化實際上是中台賦能業務，有中台的賦能才能變得更好。

經驗總結

業務中台從無到有，到被應用的實踐過程中，積累了很多實戰經驗。主要分享以下幾點：

第一點：成功實現最大的業務孵化中台是滴滴出行構建業務中台最大的經驗。

因為最大的業務最複雜，把最複雜的業務搞定，用最複雜的業務落地別的業務會容易。也就是從快車開始做，逐步整合專車、計程車、代駕等。

第二點：穩定，中台對業務有收益，最根本的是保證穩定，穩定是發展的前提和基礎。

在整個構建中台的過程中非常重視穩定性，有各種機制，包括灰度發布、分層次發布、流量回放、全鏈路壓測等等，保證代碼的質量和系統的穩定。

第三點：加強溝通，平衡多業務的優先順序。

滴滴出行有多個業務，有很多大區和城市，每個地方都有很多需求，要有一套機制和資源池。

如何保證相應每個業務都能按照所對應的在公司的重要性來獲取部分資源，要保障它的靈活性和效率，所以要有很多溝通工作，有很多平衡的工作。

第四點：中台系統要不斷演進，不能一成不變，要發現問題、解決問題。

業務中台不是一蹴而就，而是要在發展過程中不斷的變化，持續迭代。

第五點： 「沒有最好，只有最合適」！

所有中台都一定是適合某個公司特點，最合適的中台是當你深入了解業務、產品、系統、組織，而且不僅了解今天在哪裡，還要了解過去是怎麼演變而來，未來又會怎麼演化。

只有當了解所有的東西之後，才能做出最好的中台架構設計。本文轉載自 51CTO技術棧

作者：王雪燕

編輯：陶家龍、孫淑娟

賴春波，滴滴出行執行總監。2015 年 11 月加入滴滴，領導了專快車系統的平台化、服務化技術改造工作，目前擔任平台技術部高級技術總監、工程技術委員會副主席，負責核心出行平台的研發工作。此前就職於百度，擔任百度基礎架構部主任架構師，存儲方向技術負責人。長期專註於大規模分散式存儲和計算系統的研發，領導了百度新存儲體系的建設，支撐了百度網頁存儲、在離線文件存儲和百度雲存儲等業務。

高可用架構

改變互聯網的構建方式

長按二維碼 關注「高可用架構」公眾號

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！