滴滴是一家以出行爲核心、輻射單車、代駕、車服、金融、國際化等領域的科技公司，在各條業務線飛速發展的過程中會存在着很多相同或者類似的業務需求，如何通過技術的手段抽象、沉澱這些業務爲通用、穩定基礎能力，讓各業務線專注於其個性化的部分，快速的推出適合市場的新產品，是業務中臺核心價值的體現。在近期召開的QCon上海2019大會現場，InfoQ記者採訪了滴滴出行高級技術專家何修峯，他向記者分享了滴滴的業務中臺構建實踐。
滴滴業務中臺發展歷程
滴滴做中臺已經有好幾年的歷史。早在2015年，滴滴就開始組建中臺，2016年的時候方向調整做了出行中臺，目前滴滴很多出行業務都是基於這個中臺。滴滴的很多業務場景，都是配置出來的，在出行中臺裏面進行孵化，孵化了之後，通用能力像支付、定單、計價、passport等，不但能支持出行，也能支持別的業務，於是出行中臺在今年年初演進成了公司級的業務中臺，把原有中臺中更加通用的部分帶過來了。
目前整個滴滴業務中臺團隊研發有一百多人，算上產品經理團隊規模更大。目前滴滴的大部分業務場景都在使用業務中臺，已經構建了訂單中心、計價中心、支付中心、passport、用戶中心、觸達平臺六大能力。
搭建業務中臺，不應完全從技術的層面來看，因爲業務中臺最終要看到的是仍舊如何快速支撐業務。技術只是實現業務的手段，滴滴本身也有技術中臺，用來提供一些基礎的設施，像雲基礎設施、MQ、NOSQL存儲、監控平臺等，業務中臺背後有提供大量技術支撐的技術中臺。
除了技術中臺以外，滴滴還有規模龐大的大數據團隊在做數據中臺，業務中臺是依託於技術、數據中臺，更貼近於業務，主要是對業務負責。最終業務中臺能做到對整個業務進行抽象，把通用的部分沉澱下來。從整體來講，我們支持業務的發展，讓業務能跑得更快。
舉個例子，各個業務模塊過去沒有支付系統，從頭開發一套支付是很麻煩的，現在有了業務中臺可以一鍵接入支付，至於下單後，微信支付寶怎麼調用，怎麼支付，失敗後怎麼處理，就不需要業務方再去操心了，依賴業務中臺的統一接口就可以搞定，在整個業務的支持上來講，肯定是讓它更快了。
滴滴在2015年的時候就開始嘗試搭建中臺，有了一些成果，到了2016年，公司調整思路，從比較務實的角度出發，提出基於最大的業務線——出行業務線去孵化滴滴出行中臺的思路。當時提出了一個目標，滴滴的業務肯定是配置的，最合適的十幾分鍾就能配置出來。
經過幾年的發展，慢慢進化到今天這個樣子。從0到1的過程中，最主要就是務實，基於解決問題，從業務出發，再基於當前的最大業務線做孵化，逐步迭代、逐步抽象，小步跑快，最終達到一個比較理想的狀態。
2015年的時候，中臺的概念還不是那麼火，業界都處於摸着石頭過河的狀態。同一件事情，會出現不同的解決方案。小步快跑、快速試錯的方式比較容易成功，另一種可能最開始的規劃比較多，受外界影響的變化也比較多，最終可能導致做出來的東西跟實際情況不匹配，或者需要經常改影響了實際效果。滴滴也有類似的嘗試，結果並不是很成功，所以就換了另一條思路，最終在2016年開始取得了一些成果。
業務中臺要緊貼業務
滴滴出行業務會有高峯期的概念，工作日的早晚高峯、節假日的高峯期，中臺對於業務的支撐也會加大支持力度。業務中臺是整個業務中非常重要的一環，針對高峯期，中臺部門需要在處理方案上做功夫，至於這個模塊中臺不好處理能否放在業務部門，或者業務部門不好處理能否放在中臺，都是可以商量的。對於最核心的業務，比如滴滴的出行業務，在技術上的投入、資源上的傾斜力度都會更大。
業務中臺是爲業務服務的，跟業務線要走得很近，滴滴今年在內部提出“向前一步”，每個技術團隊都會向前一步，瞭解你前面所支撐的業務到底是什麼樣的，這樣整個前後信息是打通的，從一個統一的認知上去理解問題、溝通問題，最終就更加容易達成一致。
業界一些中臺部門存在的業務接入遇到阻礙的問題，在滴滴這很少遇到，因爲滴滴的業務中臺直接是從最大的業務中孵化出來的。訂單中心、計價中心、支付中心、passport、用戶中心、觸達平臺等都是配置孵化而來，對於目前不需要中臺的業務線，中臺部門也不會去強制接入，內部更多是通過溝通機制劃定邊界。
中臺團隊需要下到各個業務線去溝通，考慮對方的需求如何通過我們的抽樣能力、複用能力，以最終達到提高人效的結果。背後會有一些資源上的傾斜，需要溝通、對齊，對於滴滴而言整體最優是最合理的。達成整體最優就需要共同協商、解決，可能有些需求暫時排不上期，就會讓業務線自己先做，中臺部門永遠不可能比業務線人多，同樣也不可能像業務線那樣對於業務的變化那麼敏感，在這個過程裏，需要中臺部門與業務線之間拉通信息以解決問題。
業務中臺跟技術人員的區別
滴滴業務中臺部門的成員大部分是內部轉化，最開始的出行中臺孵化出來了一些工具和基礎能力，帶來了一些業務中臺部門的早期成員。中臺部門其實是有些延續性的，也會招聘一些新的人，但只要有老人這些文化、種子存在，新人進來以後就會快速融入，融入之後帶來新的思想、新的碰撞，可能會產生新的思路、新的文化。
業務中臺部門成員跟純粹的底層開發之間肯定存在一些差異，相對而言前者的技術工作可能更加容易，跟真正的業務開發人員相比，對業務的瞭解也會存在一些差距。所以，滴滴提出“向前一步”的做法，也是希望中臺人員能跟業務開發人員拉齊，久而久之就會有業務上的感覺，也可能對未來業務發展產生自己的想法，同時基於對內部技術、後臺的理解，做出一些技術上的創新，從而支撐整個的業務層未來的創新。
理論上來說，業務部門的開發人員可以做任意開發需求，但這背後存在一個性價比的問題。比如說登錄功能，任何一家小公司、小團隊都可以做，但是不是能做到體驗一致？比如說滴滴一家公司有好幾個App，如果每個App的體驗做得都不一樣，用戶會怎麼想？
所以對業務中臺部門而言，以一個統一的接口去做系統的優化，沉澱下那些通用的能力，這是性價比最高的方案。此外，中臺部門在技術上也會做得更深入一點，考慮更加全局化一點，不會隨意造輪子。
中臺是微服務的集散地嗎？
中臺是微服務的集散地這個觀點我不認同。所謂集散地，代表的是一種雜亂無序的狀態，是一大堆東西硬塞進去的混亂的地方，但中臺背後一定是有一套機制、一羣人來保障、有序的狀態。
中臺部門首先是有序的、有規劃的，其次是解決一些業務上的問題，並且在這些業務問題之間，中臺團隊試圖去把它打通，找出共性。再者，中臺是有自己的門檻的，不是隨便寫個微服務或者其他的組件就可以放到中臺裏。中臺部門希望技術團隊去貢獻一些基礎能力，但貢獻出來的基礎能力最終是否能融入到中臺裏，最終仍舊需要通過一定的機制去做相應的評估。因爲一旦進入中臺，就有責任對它去做擴展、推廣、運營，保證其生命週期，讓其長久地活下去。
雜亂無序的集散地，彙集的肯定不止各種各樣的微服務模塊，還有其他雜七雜八的組件，缺乏強有力的管理，它的生命力是不會長久的。
但微服務對於構建中臺而言是一個很好的技術手段。現階段，構建一個大型的互聯網系統，普遍爲業界接受的基本上就是微服務加上DDD（領域驅動設計）的架構設計模式。互聯網迭代速度快，傳統的單體架構模式無法適應，而微服務因爲比較簡單靈活、獨立擴展、發揮，對技術棧沒有特別要求，底層存儲也不要求跑在同一個數據庫上，是現階段互聯網架構設計的一種比較好的解決方案。中臺團隊服務的是大型互聯網企業的業務，也需要靈活的變化，跟微服務的理念是相吻合的。
當然微服務也存在一些問題，比如網絡上的不可靠性等等。任何一種技術，如果缺乏規範化的管理，最終都會陷入雜亂無序的狀態，因此也催生了微服務的治理平臺。滴滴是一個比較新的公司，技術上有後發優勢，技術債比較小一點，目前在中臺層面使用的微服務治理做得比較令人滿意。
滴滴中臺未來發展方向
滴滴業務中臺的發展方向仍在探索中，在此之前我們已經構建了訂單中心、計價中心、支付中心、passport、用戶中心、觸達平臺六大能力。現在首先是要滿足對各個業務線的支撐，做到又穩定又快又高效。
第二階段，我們希望業務之間能夠打通，聯結起來，做到賦能。比如A業務做了一個新功能，B業務可以直接拿過來，通過業務中臺賦能，產生更多新的玩法。
第三階段，做到業務之間的協同與創新。通過業務中臺作爲一個統一的出口，對一些新業務做管控，讓它保持在正確的軌道上發展
受訪嘉賓
何修峯，就職於滴滴業務中臺，任高級技術專家一職，致力於微服務治理、提高系統工程效率、構建底層基礎組件或服務，在大型分佈式系統構建、微服務治理、複雜系統重構方面有豐富的經驗，現負責滴滴支付中臺基礎工作，構建支付的底層基礎設施，以打造穩定、高效、可擴展的支付底層能力爲己任，提高工程效率，助力集團各業務線快速發展。
更多國內外一線技術大咖分享請持續關注QCon全球軟件開發大會，訪問官網與技術大咖面對面交流實踐心得。
