【51CTO.com原創稿件】經歷5年發展，滴滴出行已擁有4.5億用戶、超過2100萬車主，業務覆蓋400+城市。在創業初期，為了快速擁抱業務，架構的建設在體系化、完善度等方面會有所不足。隨時間推移，架構在可持續性、穩定性等方面需不斷進步。

2017年12月1日，在51CTO主辦的WOTD 2017全球軟件開發技術峰會主會場上，滴滴出行執行總監賴春波做了主題為《如何構建滴滴出行業務中臺》的精彩演講，從中可以了解到滴滴出行構建業務中臺的原因及在過程中遇到的問題和應對的策略。在峰會現場，賴春波老師也接受了我們的專訪，進一步交流構建業務中臺的一些實踐經驗。

[[211958]]

賴春波·滴滴出行執行總監

構建業務中臺的原因

2015年末，滴滴出行在短時間內形成了包括快車、出租車、專車、順風車、代駕等多業務的垂直化架構。滴滴啟動了中臺戰略整合業務系統。決定構建業務中臺主要出于四方面考慮：專業深度、人力資源、用戶體驗、全局打通

專業深度。由于是多業務垂直化的架構，會有多個團隊開發同樣的架構，這就需要很多的工程師。每個團隊都是用最快速的方式構建流程，所以技術很難做深。這樣一來，導致客戶端的流暢度不高，后端不穩定，影響可擴展性。

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

用戶體驗。流暢度、穩定性、擴展性、界面、交易流程等都是影響用戶體驗的重要因素。在當時的組織結構和研發情況下，會出現業務的顏色各異，交易流程卻相同的問題，很影響用戶的體驗。

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

構建出行業務中臺在軟件復雜度上的挑戰

構建出行業務中臺并不是只有好處，也一定會帶來很多問題，***的問題是軟件復雜度。

從業務角度來說，把所有業務合并到一個體系下，本身就是很難的事，再加上滴滴出行是實時性O2O業務，場景差異很大，而且作為互聯網公司，不僅很多需求不明確，還會持續變化。這種情況下，想要用一套相對穩定、相對固定的架構去支持所有業務，十分困難。

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

針對軟件復雜度的挑戰，中臺的目標是：在業務多元化發展的組織中，去構建一套工程架構，構建一套組織結構及對應的管理機制，以保證業務可持續的又快又好的發”。

攻破軟件復雜度問題的具體對策與實踐

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

整個的架構設計分幾個邊界的上下文，好處在于把相關性不強的邏輯拆開，同時在一個相關性下面，通過分層可以去把業務進行更好的建模。調度層做為入口去牽引多個業務線，業務流程層為調度層做服務，狀態智能層用來支持上面兩層。

在對業務和產品進行更好建模的基礎上，進行“五化”：服務化、異步化、配置化、插件化、數據化。

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

下單流程能夠調用很多服務，在多個層次，以接口層次結果拆解。這里需要提醒的是服務化要注意如下三點：

• 服務之間的協議和規范要建立好。
• 注意控制力度，力度太小、太大都會有問題。
• 隨著時間的發展，服務化本身要不斷的演進。

異步化。對每個事件的非核心或不需要實時反饋給客戶端的邏輯進行拆解，核心的主流程會變簡潔。對非核心的邏輯在事件上做訂閱之后，進行二級處理。以結束訂單為例，如下圖

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

配置化。服務化和異步化能解決很多迭代效率的問題，但由于系統、業務的復雜性，各個業務都有些差異，體現在不同的產品線、城市、區域、時間等等，配置化核心是對這些進行建模，把每個對象模型化，抽象成ID，在不同的服務化里把這些可配置的能力進行抽象。具體抽象過程，如下圖。

***級抽象采用是類 iptables 的規則引擎判定產品分類，第二級的規則引擎，由模塊自定義。所有配置化都是用自生成平臺，要配置什么，自定義配置即可，這個過程是動態進行的。當前業務中臺已經可以支持上千個配置點，比如不同層次的計價規則不一樣、不同產品線的車樣子不同、不同的場景，如拼車和接送機，管控規則也不一樣等等。

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

在FPI的能力上，不同的團隊可以開發很多插件，在特定的配置點下，把它的邏輯去進行加載。真正業務流程到這兒，可以調起它對應的插件做出來。對于一些沒有差異化需求的業務，可以用開發的default邏輯，這是更極端的靈活性的體現。

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

通過插件的形式在每個系統加載它的插件，它就可以跟著業務思考、跟著產品思考這個業務怎么走、這個產品怎么演化。相對的邏輯是更加專注的，這也帶來很好的組織結構對中臺的適應性。

數據化。在大數據時代，數據是不得不考慮的問題，所以在業務中臺，要實現全局打通，本質是要把數據打通。所以制定了離線分析與在線決策的方案，如下圖。

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

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

• 讓數據更加規范和標準化。
• 構建完整的數據流，從在線到離線，從日志到模型的在線使用。
• 引入機器學習的算法、人工智能的算法去構建在線數據智能的決策。

這是業務中臺的五個對策，主要解決傳統的系統架構問題，怎么做到高耦合和內聚，怎么提高迭代。配置化和插件化解決靈活性問題，把靈活性開放給不同團隊。數據化實際上是中臺賦能業務，有中臺的賦能才能變得更好。

經驗總結

***點：從***的業務孵化中臺是滴滴出行構建業務中臺***經驗，因為***的業務最復雜，把最復雜的業務搞定，用最復雜的業務落地別的業務會容易。從快車開始做，逐步整合專車、出租車、代駕等。

第二點：穩定，中臺對業務有收益，最根本的是保證穩定，穩定是發展的前提和基礎。在整個構建中臺的過程中非常重視穩定性，有各種機制，包括灰度發布、分層次發布、流量回放、全鏈路壓測等等，保證代碼的質量和系統的穩定。

第三點：加強溝通，平衡多業務的優先級。滴滴出行有多個業務，有很多大區和城市，每個地方都有很多需求，要有一套機制和資源池，如何保證相應每個業務都能按照所對應的在公司的重要性的部分資源，要保障它的靈活性和效率，所以要有很多溝通工作，有很多平衡的工作。

第四點：中臺系統要不斷演進，不能一層不變，要發現問題、解決問題。業務中臺不是一蹴而就，而是要在發展過程中不斷的變化，持續迭代。

第五點： “沒有***，只有最合適”！所有中臺都一定是適合某個公司特點，最合適的中臺是當你深入了解業務、產品、系統、組織，而且不僅了解今天在哪里，還要了解過去是怎么演變而來，未來又會怎么演化。只有當了解所有的東西之后，才能做出***的中臺架構的設計。

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】