中台的末路
從 15 年開始，到 19 年現(xiàn)在為止。各大公司都在吹捧中臺理念。仿佛中臺是業(yè)務復雜性的救世主。是某些架構師和 PM 的新出路。各種割韭菜的講中臺的課程層出不窮。
當然，吹牛逼的時候大家都是揀好的說，苦逼的東西就只有內部人士知道。中臺到底靠譜還是不靠譜，只憑各路英雄的演講內容，那看起來是靠譜的。
先來看看這些公開的觀點，再以我（碼農(nóng)桃花源注：滴滴資深研發(fā)）的視角還原“中臺”的真相。
按照碼農(nóng)桃花源文章的慣例，手動貼上文章的目錄：
公開的觀點
中臺是什么
阿里巴巴集團前端業(yè)務中公共、通用的業(yè)務沉淀到了這個事業(yè)部，包含了用戶中心、商品中心、交易中心、評價中心等十幾個中心，而共享業(yè)務事業(yè)部正是“厚平臺”的真實體現(xiàn)，為阿里巴巴各種前端業(yè)務提供著相應服務中心領域內最為專業(yè)、穩(wěn)定的業(yè)務服務。鐘華. 《企業(yè)IT架構轉型之道：阿里巴巴中臺戰(zhàn)略思想與架構實戰(zhàn)》
中臺實際上是通用業(yè)務的下沉，企業(yè)在一個行業(yè)耕耘多年之后，一般都會形成一些公用的業(yè)務，而這些業(yè)務是可以像中間件那樣進行下沉共享的。
再往前推一些，也就是比較早期人們常說的偏業(yè)務的基礎服務。在概念上并不是創(chuàng)新。
為什么要做中臺
中臺解決了什么問題？
其實和把程序內的公用邏輯封裝為 library 差不多，就是盡量避免重復造輪子。一個輪子造 100 遍，對部門是沒有任何好處的。一個系統(tǒng)造 100 遍，對企業(yè)自然是沒什么幫助的。
早期的企業(yè)經(jīng)常借鑒騰訊經(jīng)驗，鼓勵內部競爭。但內部競爭的度往往不好把握，經(jīng)常會出現(xiàn)“所有部門都在造差不多的系統(tǒng)”的現(xiàn)象。
中臺從公司戰(zhàn)略角度，將這些行為進行了規(guī)范化，公共的部分交給公共系統(tǒng)部門去做。
中臺給企業(yè)帶來的收益
工程方面
就像上面提到的，首先是有效減少了重復造輪子、重復建系統(tǒng)的現(xiàn)象。有相對統(tǒng)一的業(yè)務收斂位置，并在公共服務上快速高效迭代出新的業(yè)務。
數(shù)據(jù)方面
有了統(tǒng)一的用戶、訂單系統(tǒng)，就不會再有各種惡心的數(shù)據(jù)打通問題，不會有跨部門的數(shù)據(jù)墻。
有了統(tǒng)一的中臺，也就有了統(tǒng)一的數(shù)據(jù)規(guī)范。
對于大數(shù)據(jù)相關的需求，可以從相對唯一的數(shù)據(jù)出口進行業(yè)務迭代，不需要為每一個部門進行定制開發(fā)，浪費人力。
創(chuàng)新方面
這一項目也很好地詮釋了之前所說的“點、線、面”的理論，在“點”上根本感知不到的問題，在“線”和“面”的平臺上，更容易發(fā)現(xiàn)這些問題的本質，通過專業(yè)的技能解決這些問題，為企業(yè)帶來實實在在的業(yè)務價值，這就是很好的創(chuàng)新！鐘華. 《企業(yè)IT架構轉型之道：阿里巴巴中臺戰(zhàn)略思想與架構實戰(zhàn)》
有了公共的中臺，意味著有了相對全局的視角，更能發(fā)現(xiàn)單點觀察難以發(fā)現(xiàn)的問題。在更大的業(yè)務層面進行一定的創(chuàng)新。聽著很有道理。
真相
中臺能解決問題么？是能解決的。中臺能解決所有問題么？那顯然是不能的。
就像微服務架構一樣，架構師吹牛的時候天花亂墜，你做起來卻發(fā)現(xiàn)這條路上全都是坑。
技術方面
公用業(yè)務下沉，這個理念其實很樸素。所有程序員都知道我們公用的邏輯要進行封裝、抽象，變成 Library。中臺的本質其實就是把這種樸素的思想進行了一定程度的推廣。（碼農(nóng)桃花源注：新瓶裝舊酒）
難以應對 Cross cutting concern
根據(jù)中臺進行系統(tǒng)拆分和部門調整之后，還是會遇到 cross cutting concern，什么是 cross cutting concern：
The crosscutting concern is a concern which is applicable throughout the application and it affects the entire application. For example: logging, security and data transfer are the concerns which are needed in almost every module of an application, hence they are cross-cutting concerns.
有些需求難以避免地會影響整個流程中的所有系統(tǒng)。
比如從技術范疇進行的一些改造(如為了完成 tracing，所有系統(tǒng)增加 trace id，并在 log 中默認攜帶)。
比如從業(yè)務范疇進行的 i18n改造。（碼農(nóng)桃花源注：i18n 是國際化的意思，Internationalization 去掉頭尾的 i 和 n 剛好還剩下 18 個字符，程序員的智慧）
這些改造需求一般天生就是跨系統(tǒng)、跨組、跨部門的，事情一帶上“跨”的字眼，就不好搞了。（碼農(nóng)桃花源注：別人的地盤，你能做主？）
舉一個典型的例子，某巨型互聯(lián)網(wǎng)公司員工抱怨，在當前的微服務和中臺架構前提下，做一個需求經(jīng)常要改 20+ 個模塊，苦不堪言，連上線順序都不一定搞得清楚。
當這 20+ 個模塊又是跨部門的時候，就更難了。想要推動其它部門做一些短期看起來沒啥收益的事，太難了。
穩(wěn)定性和靈活性的矛盾
對于一個系統(tǒng)來說，追求穩(wěn)定性，那么必然會在修改和升級上較為消極；追求靈活性，那在功能迭代上一定會較為激進。這兩方面的矛盾本來就是難以調和的。追求其中之一，在一定程度上就得放棄另一方面。
就像網(wǎng)友經(jīng)常講的不作死就不會死，沒有代碼才是真正的穩(wěn)定之道。Google 程序員在 Github 上發(fā)起的行為藝術項目：nocode，沒有 code，就沒有 bug。可謂棄療的典范。
有很多中臺系統(tǒng)被剝離之后，因為用戶眾多，一旦出現(xiàn)技術上的問題，影響面巨大。從我的實際觀察來看，中臺部門的系統(tǒng)雖然初始立項的時候聲勢浩大，但基本也沒什么人關注這些公共系統(tǒng)的代碼質量或者測試質量。最終只不過是大家公用了一堆“垃圾”，“垃圾”在轉過幾手之后，后來的人基本就不太想對原來的代碼進行修改了。
可能有人會講你可以重構啊。嗯，重構的前提是系統(tǒng)有完善的測試用例和可以跑的測試。事實上一般都沒有！在沒有測試的情況下，我們可以根據(jù)過往的系統(tǒng)需求文檔和 PRD（碼農(nóng)桃花源注：產(chǎn)品需求文檔，Product Requirements Document）來還原當時的業(yè)務場景，并進行測試補充。
但你又發(fā)現(xiàn)，中臺的性質（大多偏技術項目，基本沒什么 PM 把關或者出文檔）使其基本沒有什么靠譜的、詳盡的文檔。寫的復雜的中臺，連業(yè)務流程都理不清楚，還想寫測試，別做夢了哦。
中臺與前臺的模糊業(yè)務邊界、距離
在實際實踐時，中臺與 FT 的邊界往往劃得不清不楚。比如用戶服務、用戶權益、用戶在各種子系統(tǒng)中的狀態(tài)，這些內容可能并不是用戶服務本身關心的內容。但往往需求也會提給用戶服務，這時候用戶服務就只是進行字段存儲，而狀態(tài)機變化則完全在外部。
如果對系統(tǒng)內的個別數(shù)據(jù)不進行管理，那么有其它接入方接入時，就無法解釋清楚字段的含義和使用場景。如果不接受這些不相干的數(shù)據(jù)接入，那么前臺流程系統(tǒng)可能會在自己內部重新建立自己的數(shù)據(jù)系統(tǒng)，這部分系統(tǒng)又極有可能和中臺有功能上的重疊。
如果想要把這些數(shù)據(jù)接管過來，那么中臺又需要梳理所有業(yè)務場景。或者說明需要把所有對數(shù)據(jù)進行修改的邏輯全部收攏到中臺內部，這往往又會產(chǎn)生與中臺與前臺業(yè)務邊界的沖突。
難以給出有效的邊界，就意味著無窮無盡的撕逼。這便是很多中臺的兩難：我接不是，不接也不是。
如果去問那些中臺業(yè)務部門的系統(tǒng)開發(fā)負責人：某些業(yè)務要不要你們來做，連這些人自己都說不清楚。
人方面
如果要做中臺，那往往需要將業(yè)務部門的一部分系統(tǒng)進行下沉。下沉并不僅僅是一個技術問題。如果要把系統(tǒng)從一個部門變到另一個部門，這一定會帶來人員的調動。從情感上來講，人們都是討厭這種部門變動的。因為“領導”會在部門調整中發(fā)生變化，同事也經(jīng)常會隨著部門調整而離職。只留自己在原地填坑給誰都不愿意。
也有些公司在調整中進行粗暴的系統(tǒng)交接，如果系統(tǒng)需要下沉，那我直接從原來的維護團隊手里奪過來，交給中臺部門來管理。這一樣會引起雙方的反感：
交接方：這是我們加班加點，辛辛苦苦開發(fā)出來的系統(tǒng)，憑什么交給別人？奮斗了半年難道就是為了給別人摘桃子？
被交接方：這個系統(tǒng)原來的維護團隊水平極低，代碼就是一堆“垃圾”，他們不想搞了就隨便扔給我們？憑什么啊？我們又不是接盤俠。
即使貴司運氣好，在系統(tǒng)交接過程中沒有出現(xiàn)問題，那交接后也不好說。被交接的系統(tǒng)在交接后往往陷入消極維護狀態(tài)，這時候前臺業(yè)務接入中臺會比以往更加困難，這種困難使前臺業(yè)務的不滿積累到一定程度之后，會再次催生前臺部門重新造一套新的自己的中臺，而部分或全部放棄原來的中臺。這樣，原來的中臺部門便會陷入尷尬的境地。
生存空間被擠壓，人也自然很難待得下去，各公司的中臺部門，人跑的比香港記者都快。
部門、公司、組織架構方面
跨部門溝通障礙、跨部門目標差異
進行部門劃分之后，每個業(yè)務部門會有自己的一套目標體系。部門與部門的目標（KPI）一般是不相同的，如果相同的話，那也就沒必要分多個部門了。
而部門與部門之間的目標在某種程度上甚至可能有沖突，例如 A 部門 Feature Team 較多，主要負責業(yè)務功能迭代，需要更強的靈活性。而 B 部門負責中臺數(shù)據(jù)，主要關心系統(tǒng)穩(wěn)定性，也就是前文提到的靈活性和穩(wěn)定性的矛盾。若此時出現(xiàn) cross cutting concern，兩個部門需要在矛盾上取得一定程度的平衡，這種平衡在個別情況下是不可得的。
例如在一段時間內，中臺部門的目標是提高某個商業(yè)指標，讓公司更賺錢/省錢。這時候前臺業(yè)務提來了新的需求，這種需求是能使流程開發(fā)更加靈活的，但與中臺部門的 KPI 不在一個航道上。
中臺部門顯然要把需求排排優(yōu)先級，把任務排排主次。前臺部門又會覺得中臺支持個需求怎么這么龜速又唧唧歪歪，不如自己實現(xiàn)了。
前臺業(yè)務也有自己的理由：“自閉環(huán)”嘛，這詞真是好用。
公司利益分配
毫無疑問，距離業(yè)務近的地方比距離業(yè)務遠的地方能分到更多公司增長的成果。中臺看起來是業(yè)務，但又是公共業(yè)務，既然是公共業(yè)務，那基本上沒辦法分享到任一單一業(yè)務成功的紅利。縱使其成功的原因中，中臺的強大、便捷是重要原因。
這會導致什么問題呢？沒有人愿意接手中臺項目，中臺項目變成燙手的山芋。大佬無法在中臺項目上獲得紅利，小弟們沒法在中臺項目上獲得利益。中臺功能確定以后，只有出事故的時候大家才想起你來。穩(wěn)定運行是應該的，出事就是你的鍋！
利潤中心？其實是成本中心
最重要的是讓信息中心部門從之前在企業(yè)中“業(yè)務支持”的組織職能，轉變?yōu)榛谄髽I(yè)核心業(yè)務和數(shù)據(jù)進行運營的團隊，這個團隊會更快、更好地支持業(yè)務發(fā)展的同時，逐漸掌握企業(yè)最核心的業(yè)務和數(shù)據(jù)，逐步培養(yǎng)出企業(yè)最稀缺的“既精通業(yè)務，又熟悉技術”的復合型人才。在接下來整個社會進入開放共享的時代，企業(yè)最大的價值將會是基于這些核心業(yè)務和數(shù)據(jù)進行對外開放的運營，到那個時候，這個部門將成為企業(yè)最為寶貴的資產(chǎn)。鐘華. 《企業(yè)IT架構轉型之道：阿里巴巴中臺戰(zhàn)略思想與架構實戰(zhàn)》
在大多數(shù)公司，中臺部門和基礎架構一樣，會被當成是包袱而不是財富。可能有些人讀到這里會不太爽。我們來看看，科技公司是怎么看待員工的呢？
在 DDD（碼農(nóng)桃花源注：領域驅動設計，Domain Driven Design）相關的書里提到兩個概念：成本中心、利潤中心。技術對業(yè)務參與不強的情況下，技術部門基本上都會被當作是成本中心。也就是老板要達成自己的目標，必須不情不愿地花錢去養(yǎng)你們這些技術團隊。
對應業(yè)務側開發(fā)來說，想要改變老板的這種看法，需要讓業(yè)務系統(tǒng)和業(yè)務人員之間進行強聯(lián)動，將一部分業(yè)務人員變成系統(tǒng)人員架構中的業(yè)務專家角色，或者是研發(fā)人員自己變成一個業(yè)務領域專家，就是有些人常說的你得跟老板穿一條褲子。
從這方面來講，大多公司的基礎架構角色就比較尷尬。業(yè)務驅動的公司，基礎架構并不是其致勝要素。所以不管你做的再好，只要公司沒有用技術賺錢，那么這部分的支出就只能被當作單純的成本。
當然了很多做基礎的大佬也根本不在乎，公司只是個練兵場，練成了帶小弟們跳槽就好。（碼農(nóng)桃花源注：求帶！）
中臺也是一樣的，從業(yè)務一線剝離到后方之后。中臺離業(yè)務的距離越來越遠。公司高層漸漸看不到繼續(xù)對中臺進行投入的價值，中臺便漸漸變成了他們眼中純粹的成本中心，是公司財務的包袱而不是財富。
行業(yè)方面
中臺建設一般要考慮公司的實際情況，這樣建設出來的系統(tǒng)可以應對一段時間內的公司業(yè)務變化。然而公司的壓力有時并不來自于自己的業(yè)務方向，可能來自于行業(yè)內其它公司的模式挑戰(zhàn)。
理論上來說，只要一個公司的業(yè)務系統(tǒng)架構建設完成了，便已經(jīng)完成了一種架構上的 固化。這時行業(yè)內如果有新的模式獲得了成功，公司肯定要進行跟進。但是新的模式一定意味著對原有系統(tǒng)、架構的挑戰(zhàn)。
試想，原來系統(tǒng)架構是針對線上交易設計的，突然有一天，O2O 模式被證明有利可圖，大多數(shù)公司都開始轉向線下。原有的流程、模式當然想要復用，但是這時候復用的成本很可能比重新開發(fā)還要高。眼睜睜看著競爭對手們甩掉包袱，輕裝上陣，以更低的成本更短的時間攻城略地，擠壓自己的生存空間。
這時候怎么辦呢？大多數(shù)公司給出的方案是成立新的業(yè)務部門，在新趨勢新陣地沖鋒陷陣。新部門肯定也要用到原來公司的老服務，又碰到了我們的老問題：跨部門合作。新部門的成功并不會讓老部門多得到多少好處，配合自然不會太積極。（碼農(nóng)桃花源注：公司內部做事都是利益驅動）
如果新部門的嘗試獲得了初步成功，得到了公司資源的傾斜，獲得了有效的人力資源補充。之后又會帶來新一輪重復造輪子，互相不合作，互相撕逼的腥風血雨。
簡直是一個輪回。
結語
經(jīng)常有小伙伴說，國內某公司中臺非常好，大家都在學。嗯，我倒是想問問了，如果真的做的好，某公司旗下的金融公司和電商公司還會需要兩套完全一樣的基礎架構，和好幾朵云？（碼農(nóng)桃花源注：曹大真敢懟！）
作為一個技術人員，在各種烏七八糟、花里胡哨的概念“轟炸”下，應該能夠保持理智，不要被各種人帶節(jié)奏。
總結
- 上一篇： docker——kafka-manage
- 下一篇： Redis 21问，你接得住不？