【51CTO.com原創稿件】2017年12月01-02日，由51CTO主辦的WOTD 2017全球軟件開發技術峰會在深圳中洲萬豪酒店召開。秉承專注技術、服務技術人員的理念，自2012年以來，WOT品牌大會成功舉辦了十四屆，積累了大量的技術專家資源，獲得了廣大IT從業者和技術愛好者的一致認可，成為了業界重要的技術分享交流平臺以及人脈拓展平臺。

本次會議分為10個技術主題，分別是：編程語言與框架，大數據系統架構設計、微服務與容器技術、前端開發實戰、物聯網（IOT）技術、軟件性能優化、深度學習與智能應用開發、創新運維探索、技術架構遇到業務架構、CTO訓練營。51CTO作為本次大會的主辦方，將全程圖文直播報道與后期視頻展示這場盛宴。

12月01日上午WOTD2017主會場，滴滴出行執行總監賴春波進行了主題為《如何構建滴滴出行業務中臺》的精彩演講。以下是演講梗概，讓我們先睹為快！

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

今天，很高興和大家分享我們在滴滴構建出行中臺的經驗和方法論。先簡單做一個自我介紹，我于2008年走出校門，便加入了百度，做了將近8年時間的基礎架構，一直在跟分布式系統、大規模存儲打交道，一開始做得非常有熱情，因為百度的數據規模和系統規模都非常大，面對的挑戰也非常大。隨時間推移，熱情逐漸減退，重要的原因是因為做底層，只負責支持業務，但業務能不能做起來，并不主要取決于你。

為什么選了滴滴呢？因為我覺得滴滴發展非常快，在業務發展非常快的公司，它的業務技術的挑戰一定很大，而且遠遠沒有做好。所以決定加入了滴滴。加入滴滴之后，比我想得要更難，因為我覺得它挑戰很大，但是我沒想到比我想的更大。從那個時候開始，慢慢的開始構建出行的中臺。

演講主要涉及五方面：

一、    簡單介紹滴滴的情況，這是為什么構建出行中臺有關系；

二、    構建出行中臺的原因，整個系統面臨的問題；

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

四、    具體的對策和實踐；

五、    簡單總結一下我們的經驗。

滴滴的情況

滴滴非常年輕，我們才發展了5年，我們2012年9月9日才出來***個版本，到現在為止我們把整個領域絕大多數的方向做了一輪變革。這是我們現在的數據，現在我們從單量來說是全球出行的***，有超過4.5億的用戶，有超過400座城市在運營，有超過2000萬的車主，只有少數像出租車和專車和租賃公司這樣的全職車主，我們日單量突破2500萬單，整個覆蓋超多個業務線。

滴滴的發展歷程，這是非常重要的點，2012年9月上線***個出租車版本，后來在持續兩年時間內，按照我們CEO的說法，一直在中國打小組賽，從最開始在北京和優步開始競爭，后來在杭州、深圳，***是和快的在全國進行競爭，***才合并成為統一的滴滴出行。但是緊接著，2014年8月開始，短短一年時間內業務多元化發展且很迅速，從專車到企業到快車到順風車到代駕到拼車，發展很快。這樣的多元化的過程，確實能夠幫助滴滴迅速的在市場上，在各個子的領域都占據著龍頭的地位，確實互聯網的發展還是唯快不破，其實也帶來了一個很大的問題。

構建出行中臺的原因，整個系統面臨的問題；

2015年末，我們的架構是多業務的垂直化的，每個業務都有自己的業務系統，都有自己的客戶端，中間有一個分發層，下面基本上是基礎架構，基礎架構也沒有什么特別的東西。

非常有意思的一點，大家現在看到的滴滴出行的頁面，其實就是因為當時的架構所設計的。當時的設計、客戶端的設計專門做了架構，做虛擬機的機制，每個都可獨立運行，不會互相干擾，每個業務都可以快速跑，而不會影響別的業務，而這樣的設計模式一直發展到今天，以至于我看到國內絕大多數小的出行領域的公司也都沿用這個架構，但沒有想到這其實是因為這樣的特殊組織結構或者研發的組織結構帶來的。

出行相似性。在這樣的架構下，其實我們看到它有很大的問題，本質還是來源于出行業務是非常相似的，雖然我們看著有這么多業務，但是從滴滴APP打進去看，出租車、快車、專車，不管是他們的界面還是交易流程其實都非常相似。

專業深度。這個相似性在當時的情況下有問題，我有這么多的工程師，可能有4、5波工程師都開發同樣一套交易流程，同樣一套出行交易流程，但技術深度很難做得那么深，因為每個地方都要有快速的方式構建自己的交易流程。我們看到客戶端，當時流暢度非常低，在后端穩定性也非常嚴重。

人力資源。在2015年的10月份掛過半天，在之后也遇到過類似的宕機，非常明顯。其實也會嚴重影響這些系統的可擴展性，因為開發者都是為了快，沒有考慮任何未來的發展。 但是有人說，那加人就好了，把每個業務加到足夠的人，它***都可以發展很好。原則上來說都是這樣子，但現在的工程師都非常貴。如果一個公司要招這么多工程師開發同樣四五套系統，研發的成本也是非常高的。那時候滴滴說我不缺錢，因為每年燒的錢比工程師成本高多了，只要工程師愿意來就可以，即使這樣的情況下也很難招到這么多工程師。

用戶體驗。流暢度、穩定性、擴展性等都是影響用戶體驗的重要因素。其實還有很多的是直接影響用戶體驗，如每個業務進去顏色不一樣，交易流程，一個滴滴用戶進去是很崩潰的，完全不知道打快車和專車的流程是一個樣子，這是不可理解的。在當時的組織結構和研發情況下就會產生這樣的問題。

全局打通。因為有這么多業務，這些業務本質都是出行，出行本質有協同效應，我們想要把網絡協同起來，那如果在各自獨立發展情況下，這個協同性就完全沒有，而我們在構建中臺過程中，逐步把協同性加起來。

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

中臺并不是只有好處，它一定會帶來很多問題，***的問題是軟件復雜度，因為你要把這些多業務合到一個體系下去，那是很挑戰的。尤其像滴滴，它是實時性的O2O業務，它的場景差異很大，它有很多不同，北京和上海不一樣、上海和杭州不一樣，這種差異性甚至可能會到一個區域，中關村和國貿就不一樣。第二個，大家知道互聯網公司的需求不明確，他不知道今天做的事情明天會怎么樣，很多的需求是不明確，而且持續變化，而且非常快。這種情況下，你們怎么用一套相對穩定、相對固定的架構去支持？這是具備很大的挑戰。

第二個挑戰是組織的復雜性，在滴滴，我們有7個以上的出行事業部，前面講有400多個城市，他們的組織變化和結構變化很快，怎么應對組織的挑戰？在阿里，我知道他們的中臺相對是偏底層，其實天貓、淘寶還是有自己的研發團隊的，滴滴我們怎么走得更近一些、更快一些，更進一步，核心的原因是因為在出行上的相似度可能會比電商更強一些。我們現在絕大多數事業部沒有它的研發，像出租車、快車、代駕都沒有研發，研發團隊都在我這兒。如果有人和業務打過交道應該有這個感受，這種情況下怎么解決這個問題？我覺得這就是中臺。所以我把中臺的定義總結為這樣，“中臺的目標是要在業務多元化發展的組織中，我們去構建一套工程架構，構建一套組織結構，以及對應的管理機制，以保證這個業務可持續的，又快又好的發展”。這就是我們的目標。這里有三個關鍵詞，快、好、可持續。如果失去任何一個詞，都會讓這個平臺變得沒有那么有價值，這就是中臺的挑戰。

具體的對策和實踐：服務化、異步化、配置化、插件化和數據化

我們的對策和實踐，首先先簡單給大家一個整個的架構層次的設計，我們分幾個邊界的上下文，邊界上下文的好處是把相關性不強的邏輯拆開，同時在一個相關性下面，通過分層能夠去把這個業務進行更好的建模，服務編排層，是我們的入口去牽引多個業務線，業務流程再服務上面的服務編排，下面我們有對應的狀態去支撐上面的兩層。我們要對業務和產品進行更好的建模，在建模的基礎上，我們要做的事情是用我自己的抽象的話說，建設五話，因為我們小時候講建設四話，我把中臺建設總結為“建設五化”。

一是服務化，大部分人都非常熟悉，以下單為例，我們下單的流程能夠調用下面很多服務，在多個層次，以接口層次結果拆解。需要注意的是，服務化要注意三點，一個是建立很好的服務之間的協議和規范。第二點是注意控制力度，這個力度不能太小，也不能太大，太小、太大都會有問題。第三點是說還要考慮這個系統是不斷演化的，今天設計的服務不一定合適明天，所以隨著時間的發展，你的服務化本身要不斷的演進。所以這就是服務化的過程。

二是異步化，很多人在做，滴滴做得特別多，因為每個事件我們都會把它作為事件拆解，在事件拆解的情況下，我們把非核心的邏輯或者說不需要在當時反饋給客戶端的邏輯進行拆解，有這個拆解之后就可以把核心的主流程變得更加簡潔，而剩下的邏輯在事件上做訂閱再做二級處理就好，以結束訂單為例，結束訂單的時候有很多邏輯要做，但是都是通過Binlog網站處理，或者在MQ網下處理。如果你是一個新用戶，打開滴滴登錄，那這時候我們就會有用戶登錄的事件，緊接著會有拉新的模塊會訂閱這個事件，然后自己識別和判斷你是不是新用戶，你是新用戶就會給你一個券的禮包，像這樣的邏輯都是很異步化的方式處理。

三是配置化，雖然服務化和異步化能解決很多迭代效率的問題，但是我剛才講了，由于我們的系統、我們的業務非常復雜，各個業務都有些差異，體現在不同的產品線、不同的城市、不同的區域、不同的時間等等，配置化的核心是對這些東西進行建模，把每個對象模型化，然后抽象成ID，在不同的服務化里把這些可配置的能力進行抽象。我們有一個非常有意思的一點，我們***級的抽象用的是類似于iptables這樣的規則引擎，你可以有很多特征，根據不同特征的差異，我們會對你進行一個抽象，然后再到第二層的規則引擎，由模塊自定義。所有配置化都是用自生成平臺，你要配置什么，你自己定義要配置什么就可以，它是一個動態，通過這樣的方式，我們現在的系統已經可以支持上千個配置點，不同層次的計價規則不一樣，不同產品線的車樣子不同。不同的場景，比如拼車和接送機，他們管控規則不一樣，他們有很多的可配置的點。

四是插件化，這比配置化要更進一步，配置化解決的是這個業務線有差異，你找我，我重新配置解決這個問題。但是有些邏輯確實差異會比較大，這時候怎么辦？我們要做一些插件，所以我們叫FPI。在FPI的能力上，不同的團隊可以開發很多插件，在特定的配置點下，把它的邏輯去進行加載。真正的業務流程到他這兒，可以調起它對應的插件做出來。也有一些業務說，我沒有差異化的需求，你可以用我們開發的default邏輯，也可以，這是更極端的靈活性的體現。有這個靈活性的體現之后，我們的團隊還可以做一些組織上的調整，原來看起來，每個服務或者平臺是一個垂直化的架構，有些團隊是橫向的，是FT，有些FT是接送機FT，他們專門做接送機的事情，通過插件的形式在每個系統加載它的插件，它就可以跟著業務思考、跟著產品思考這個業務怎么走、這個產品怎么演化，他們相對的邏輯是更加專注的，這也帶來了很好的組織的結構對中臺的適應性。

五是數據化，在大數據時代，數據是我們不得不考慮的問題，所以在我們的系統，剛才講了我們要實現全局打通，本質是要把數據打通，所以在我們的核心在線交易流程之外，我們有兩個數據決策，***個是離線做分析，可以做數據血緣、模型訓練，同時可以把它放到在線決策層面，構建很好的智能客戶引擎和交易引擎，這個可以干預，因為干預可以讓升艙或者多業務線的清單成為可能。因為有這樣的決策，使我們在線服務的管控和判決做得更加智能。在數據化這塊，可能有三個做工作，***個是讓數據更加規范和標準化，其實這個事情是沒那么容易的，因為不同的公司，我知道很多時候數據的標準差異都特別大，不同的系統差異特別大，所以要把這步做好不容易，做好這步之后，要構建完整的數據流，從在線到離線，從日志到模型的在線使用，要構建完整的數據流，在數據流的基礎上，我們要引入機器學習的算法、人工智能的算法去構建在線數據智能的決策。 這就是我們剛才講的五條對策，所以剛才講要多記15字，就是這“五化”，服務化、異步化、配置化、插件化和數據化，服務化和異步化主要解決傳統的系統架構問題，怎么做到高耦合和內聚，怎么提高迭代下面。配置化和插件化解決靈活性問題，把靈活性開放給不同團隊。數據化實際上是中臺賦能業務，有中臺的賦能才能變得更好。

經驗總結

***點，滴滴做的***經驗就是從***的業務孵化中臺，***的業務最復雜，把最復雜的業務搞定了，用最復雜的業務落地別的業務會容易，反過來非常難。滴滴，我從快車開始做，因為快車是***的業務，逐步用快車整合專車、出租車、代駕等，是這樣的過程。

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

三是加強溝通，我們要平衡多業務的優先級，剛才講我們有七個業務，有很多大區和城市，每個地方都有很多需求，要有一套機制和資源池，怎么保證相應的每個業務都能按照他所對應的在公司的重要性的那部分資源，要保障它的靈活性和效率，所以要有很多溝通工作，有很多平衡的工作，這是一門藝術。

四是中臺系統要不斷演進，你不能一層不變，要發現問題、解決問題。我們今天的中臺系統也不是***天就想清楚的。在未來的發展中，我們也會不斷的變化。所以這是持續迭代的過程。這是我們在中臺建設中總結的經驗。

***還有一點，本次演講只要記住9個字就可以，把前面所有講的東西都忘掉，只要記住“沒有***，只有最合適”，為什么呢？因為所有的中臺都一定是適合某個公司特點，最合適的中臺是當你深入了解業務、深入了解產品、深入了解你的系統、深入了解你的組織，而且不僅了解他們今天在哪里，還要了解他們過去是怎么演變而來的，未來又會怎么演化。只有當你了解所有的東西之后，你才能做出***的中臺架構的設計。

所以我相信每個公司、每個多元化的公司，都會有自己最合適的中臺的機制和架構的設計。 我也希望未來能夠有越來越多的人來分享你們的中臺建設的經驗。

以上是51CTO.com記者從一線為您帶來的精彩報道。后續我們還有更加精彩的獨家報道，敬請關注。

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