天天看點

滴滴業務中台建構實踐

滴滴業務中台建構實踐

作者丨小智

嘉賓丨何修峰

滴滴是一家以出行為核心、輻射單車、代駕、車服、金融、國際化等領域的科技公司,在各條業務線飛速發展的過程中會存在着很多相同或者類似的業務需求,如何通過技術的手段抽象、沉澱這些業務為通用、穩定基礎能力,讓各業務線專注于其個性化的部分,快速的推出适合市場的新産品,是業務中台核心價值的展現。在近期召開的 QCon 上海 2019 大會現場,InfoQ 記者采訪了滴滴出行進階技術專家何修峰,他向記者分享了滴滴的業務中台建構實踐。 1 滴滴業務中台發展曆程

滴滴做中台已經有好幾年的曆史。早在 2015 年,滴滴就開始組建中台,2016 年的時候方向調整做了出行中台,目前滴滴很多出行業務都是基于這個中台。滴滴的很多業務場景,都是配置出來的,在出行中台裡面進行孵化,孵化了之後,通用能力像支付、定單、計價、passport 等,不但能支援出行,也能支援别的業務,于是出行中台在今年年初演進成了公司級的業務中台,把原有中台中更加通用的部分帶過來了。

目前整個滴滴業務中台團隊研發有一百多人,算上産品經理團隊規模更大。目前滴滴的大部分業務場景都在使用業務中台,已經建構了訂單中心、計價中心、支付中心、passport、使用者中心、觸達平台六大能力。

搭建業務中台,不應完全從技術的層面來看,因為業務中台最終要看到的是仍舊如何快速支撐業務。技術隻是實作業務的手段,滴滴本身也有技術中台,用來提供一些基礎的設施,像雲基礎設施、MQ、NOSQL 存儲、監控平台等,業務中台背後有提供大量技術支撐的技術中台。

除了技術中台以外,滴滴還有規模龐大的大資料團隊在做資料中台,業務中台是依托于技術、資料中台,更貼近于業務,主要是對業務負責。最終業務中台能做到對整個業務進行抽象,把通用的部分沉澱下來。從整體來講,我們支援業務的發展,讓業務能跑得更快。

舉個例子,各個業務子產品過去沒有支付系統,從頭開發一套支付是很麻煩的,現在有了業務中台可以一鍵接入支付,至于下單後,微信支付寶怎麼調用,怎麼支付,失敗後怎麼處理,就不需要業務方再去操心了,依賴業務中台的統一接口就可以搞定,在整個業務的支援上來講,肯定是讓它更快了。

滴滴在 2015 年的時候就開始嘗試搭建中台,有了一些成果,到了 2016 年,公司調整思路,從比較務實的角度出發,提出基于最大的業務線——出行業務線去孵化滴滴出行中台的思路。當時提出了一個目标,滴滴的業務肯定是配置的,最合适的十幾分鐘就能配置出來。

經過幾年的發展,慢慢進化到今天這個樣子。從 0 到 1 的過程中,最主要就是務實,基于解決問題,從業務出發,再基于目前的最大業務線做孵化,逐漸疊代、逐漸抽象,小步跑快,最終達到一個比較理想的狀态。

2015 年的時候,中台的概念還不是那麼火,業界都處于摸着石頭過河的狀态。同一件事情,會出現不同的解決方案。小步快跑、快速試錯的方式比較容易成功,另一種可能最開始的規劃比較多,受外界影響的變化也比較多,最終可能導緻做出來的東西跟實際情況不比對,或者需要經常改影響了實際效果。滴滴也有類似的嘗試,結果并不是很成功,是以就換了另一條思路,最終在 2016 年開始取得了一些成果。

2 業務中台要緊貼業務

滴滴出行業務會有高峰期的概念,工作日的早晚高峰、節假日的高峰期,中台對于業務的支撐也會加大支援力度。業務中台是整個業務中非常重要的一環,針對高峰期,中台部門需要在處理方案上做功夫,至于這個子產品中台不好處理能否放在業務部門,或者業務部門不好處理能否放在中台,都是可以商量的。對于最核心的業務,比如滴滴的出行業務,在技術上的投入、資源上的傾斜力度都會更大。

業務中台是為業務服務的,跟業務線要走得很近,滴滴今年在内部提出“向前一步”,每個技術團隊都會向前一步,了解你前面所支撐的業務到底是什麼樣的,這樣整個前後資訊是打通的,從一個統一的認知上去了解問題、溝通問題,最終就更加容易達成一緻。

業界一些中台部門存在的業務接入遇到阻礙的問題,在滴滴這很少遇到,因為滴滴的業務中台直接是從最大的業務中孵化出來的。訂單中心、計價中心、支付中心、passport、使用者中心、觸達平台等都是配置孵化而來,對于目前不需要中台的業務線,中台部門也不會去強制接入,内部更多是通過溝通機制劃定邊界。

中台團隊需要下到各個業務線去溝通,考慮對方的需求如何通過我們的抽樣能力、複用能力,以最終達到提高人效的結果。背後會有一些資源上的傾斜,需要溝通、對齊,對于滴滴而言整體最優是最合理的。達成整體最優就需要共同協商、解決,可能有些需求暫時排不上期,就會讓業務線自己先做,中台部門永遠不可能比業務線人多,同樣也不可能像業務線那樣對于業務的變化那麼敏感,在這個過程裡,需要中台部門與業務線之間拉通資訊以解決問題。

3 業務中台跟技術人員的差別

滴滴業務中台部門的成員大部分是内部轉化,最開始的出行中台孵化出來了一些工具和基礎能力,帶來了一些業務中台部門的早期成員。中台部門其實是有些延續性的,也會招聘一些新的人,但隻要有老人這些文化、種子存在,新人進來以後就會快速融入,融入之後帶來新的思想、新的碰撞,可能會産生新的思路、新的文化。

業務中台部門成員跟純粹的底層開發之間肯定存在一些差異,相對而言前者的技術工作可能更加容易,跟真正的業務開發人員相比,對業務的了解也會存在一些差距。是以,滴滴提出“向前一步”的做法,也是希望中台人員能跟業務開發人員拉齊,久而久之就會有業務上的感覺,也可能對未來業務發展産生自己的想法,同時基于對内部技術、背景的了解,做出一些技術上的創新,進而支撐整個的業務層未來的創新。

理論上來說,業務部門的開發人員可以做任意開發需求,但這背後存在一個成本效益的問題。比如說登入功能,任何一家小公司、小團隊都可以做,但是不是能做到體驗一緻?比如說滴滴一家公司有好幾個 App,如果每個 App 的體驗做得都不一樣,使用者會怎麼想?

是以對業務中台部門而言,以一個統一的接口去做系統的優化,沉澱下那些通用的能力,這是成本效益最高的方案。此外,中台部門在技術上也會做得更深入一點,考慮更加全局化一點,不會随意造輪子。

4 中台是微服務的集散地嗎?

中台是微服務的集散地這個觀點我不認同。所謂集散地,代表的是一種雜亂無序的狀态,是一大堆東西硬塞進去的混亂的地方,但中台背後一定是有一套機制、一群人來保障、有序的狀态。

中台部門首先是有序的、有規劃的,其次是解決一些業務上的問題,并且在這些業務問題之間,中台團隊試圖去把它打通,找出共性。再者,中台是有自己的門檻的,不是随便寫個微服務或者其他的元件就可以放到中台裡。中台部門希望技術團隊去貢獻一些基礎能力,但貢獻出來的基礎能力最終是否能融入到中台裡,最終仍舊需要通過一定的機制去做相應的評估。因為一旦進入中台,就有責任對它去做擴充、推廣、營運,保證其生命周期,讓其長久地活下去。

雜亂無序的集散地,彙集的肯定不止各種各樣的微服務子產品,還有其他雜七雜八的元件,缺乏強有力的管理,它的生命力是不會長久的。

但微服務對于建構中台而言是一個很好的技術手段。現階段,建構一個大型的網際網路系統,普遍為業界接受的基本上就是微服務加上 DDD(領域驅動設計)的架構設計模式。網際網路疊代速度快,傳統的單體架構模式無法适應,而微服務因為比較簡單靈活、獨立擴充、發揮,對技術棧沒有特别要求,底層存儲也不要求跑在同一個資料庫上,是現階段網際網路架構設計的一種比較好的解決方案。中台團隊服務的是大型網際網路企業的業務,也需要靈活的變化,跟微服務的理念是相吻合的。

當然微服務也存在一些問題,比如網絡上的不可靠性等等。任何一種技術,如果缺乏規範化的管理,最終都會陷入雜亂無序的狀态,是以也催生了微服務的治理平台。滴滴是一個比較新的公司,技術上有後發優勢,技術債比較小一點,目前在中台層面使用的微服務治理做得比較令人滿意。

5 滴滴中台未來發展方向

滴滴業務中台的發展方向仍在探索中,在此之前我們已經建構了訂單中心、計價中心、支付中心、passport、使用者中心、觸達平台六大能力。現在首先是要滿足對各個業務線的支撐,做到又穩定又快又高效。

第二階段,我們希望業務之間能夠打通,聯結起來,做到賦能。比如 A 業務做了一個新功能,B 業務可以直接拿過來,通過業務中台賦能,産生更多新的玩法。

第三階段,做到業務之間的協同與創新。通過業務中台作為一個統一的出口,對一些新業務做管控,讓它保持在正确的軌道上發展。

受訪嘉賓

何修峰,就職于滴滴業務中台,任進階技術專家一職,緻力于微服務治理、提高系統工程效率、建構底層基礎元件或服務,在大型分布式系統建構、微服務治理、複雜系統重構方面有豐富的經驗,現負責滴滴支付中台基礎工作,建構支付的底層基礎設施,以打造穩定、高效、可擴充的支付底層能力為己任,提高工程效率,助力集團各業務線快速發展。 

更多國内外一線技術大咖幹貨分享請持續關注 QCon 全球軟體開發大會,QCon 北京 2020 早鳥購票中,點選「閱讀原文」或識别二維碼與技術大咖面對面交流實踐心得。有任何問題歡迎聯系票務小姐姐 Ring。

點個在看少個 bug ????