知識星球經歷了 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 月加入滴滴，領導了專快車系統的平臺化、服務化技術改造工作，目前擔任平臺技術部高階技術總監、工程技術委員會副主席，負責核心出行平臺的研發工作。此前就職於百度，擔任百度基礎架構部主任架構師，儲存方向技術負責人。長期專註於大規模分散式儲存和計算系統的研發，領導了百度新儲存體系的建設，支撐了百度網頁儲存、在離線檔案儲存和百度雲儲存等業務。
高可用架構
改變網際網路的構建方式
長按二維碼 關註「高可用架構」公眾號
