到了去年底，阿里巴巴董事長兼CEO張勇在湖畔大學分享時也說：如果一個企業奔著中臺做中臺，就是死。
其實中臺到底 解決了什麼問題，怎麼落地，都是落地全靠臨時發揮了。
大體量的系統，談中臺才有意義！
軟件架構，都是逐步演進的，跨度太大，一方面公司沒有這方面的財力、人力等你來搞，另一方面技術方面也會存在短板障礙，很容易存在“將就先搞後續完善優化”的思想。
架構演進，靜下心來，看看中臺真的適合你麼？看完下文，你或許心裡會更有數。
1、中臺源
- 2009 年阿里共享業務事業部誕生，它在多年後承接了阿里的中臺的重任
- 2010 年 6 名資深遊戲開發者創立了 Supercell 公司，旗下擁有《部落衝突》，《皇室戰爭》，《海島奇兵》，《卡通農場》這四款超現象級產品。
- 2015 年中，據說馬雲帶領高管拜訪了芬蘭赫爾辛基的 Supercell。Supercell 公司員工不多，Supercell 每個團隊員工不超 7 人，團隊自己決定做什麼產品，實現產品快速開發。這次訪問據說給阿里高管帶來了極大的震撼，於是大家開始思考快速發展的信息時代中公司的架構到底應該是怎麼樣的。
- 2015/12 阿里 CEO 逍遙子的一封內部郵件打響了阿里內部進行“大中臺，小前臺”組織架構升級的指示
- 2015 年末，滴滴啟動中臺戰略，構建業務中臺主要出於四方面：專業深度，人力資源，用戶體驗，全局打通
- 2017/12 滴滴分享瞭如何構建自己的中臺
- 2018/1 京東進行組織架構調整
- 2018 下半年，愛奇藝開始規劃做中臺
- 2018/7 百度總裁陸奇離職
- 2018/12 京東宣佈採用前臺，中臺，後臺的組織架構
- 2018/12 百度內部宣佈進行架構調整
- 2019/3 字節跳動對外透露正在搭建“直播大中臺”
- 2019/5/6 上半年，知乎創始人於第二屆數字中國建設峰會接受專訪時提到知乎的中臺
- 2019/5/21 騰訊召開了全球數字生態大會，會上騰訊高級副總裁提出了“開放中臺能力，助力產業升級”和“開源協同”和“自研上雲”，然後“中臺”立馬就被帶火了。從百度搜索指數可以明顯發現，從 5/21 起中臺搜索量指數往上漲
- 2019/8/9 小米在 ITex 供需博覽會上提出小米中臺進行業務 + 數據 + 技術建設
- 2019/10 愛奇藝在 QCon 全球軟件開發大會上對愛奇藝中臺進行介紹
一、大廠的中臺
1、騰訊
All in產業互聯網。騰訊的技術委員會，對標的是阿里巴巴的中臺事業部，而不是外界所解讀的對標阿里“達摩院”。整合帶來的最大好處就是技術的標準化，而這一切顯然是為其中臺戰略做鋪墊——標準化意味著騰訊可以更高效地把自己的能力交付給客戶
建立可複用的中臺能力。百度中臺的技術思路：提供完備的通用能力、定製能力，持續完善領域技術沉澱能力。業務視角， 中臺提供了靈活的可定製業務框架， 使得業務可以聚焦業務特有邏輯的開發
3、小米
業務+數據+技術。小米業務中臺建設三年戰略，包含了持續優化、構建中以及待新建的系統，縱向分為企業戰略、業務執行、業務支撐、數據治理四部分。
4、滴滴
構建最合適的業務中臺。在對業務和產品進行更好建模的基礎上，進行了“五化”：服務化、異步化、配置化、插件化、數據化
5、京東
打造共建、共享、標準化的數據中臺。目前京東集團已形成零售、數科、物流、保險、健康等多元化的業務格局，各業務都進入到精細化運營階段，對於數據精細化運營提出了更高的需求。京東過往十多年業務發展沉澱下來的海量數據，需要通過數據中臺的建設形成寶貴的數據資產，以打造強有力的數據智能能力。
6、網易
胖中臺、標準中臺、平臺組織。標準中臺組織由各個能力組和工具、規範/流程/方法論組成；當標準中臺組織對業務的介入程度不足以支撐中臺的實現，就需要更加接近業務的定向組來參與，這就形成了胖中臺組織；而能力臻於成熟，工具、流程都實現標準化，標準中臺組織也可以退化成平臺組織。
7、用友
3+2+1。近兩年隨著對中臺理念、架構及配套研發運營體系的深入理解和落地，用友的iuap平臺逐步演變為基於統一中臺內核的3+2+1架構，即3大中臺，2大服務，1個面向用友所有客戶和生態的統一開發平臺。
8、知乎
大中臺小前臺。前臺有三個業務團隊，分別是社區事業部、商業化事業部以及會員事業部，其中社區事業部被認為是知乎一切事業的根源和基礎；商業化團隊主要負責知乎的品牌廣告、信息流廣告，以及相關的商業化活動；會員事業部，就是此前主打知識服務的知乎大學更名而來。技術實行中臺制，也就是說知乎所有業務團隊共用技術團隊。
二、端和臺
前後臺和前後端是在不同維度的思考。端是在代碼層面上的區別，臺是展現形式上的區別。
- 前端：通俗的講，對應項目裡頭寫的 html，js，css 等代碼，顯示前端頁面。
- 後端：通俗的講，對應項目裡頭寫的 bean，dao，controller，service 等業務邏輯代碼，邏輯功能。
- 前臺：前臺中有前端和後端，由各類前臺系統組成的前端平臺。每個前臺系統就是一個用戶觸點，即企業的最終用戶直接使用或交互的系統，是企業與最終用戶的交點。例如用戶直接使用的網站，手機App，微信公眾號等都屬於前臺範疇。
- 中臺：中臺是前臺和後臺的中間層，因為我們發現後臺系統掌管著核心數據，隨著企業業務擴大，後臺系統應該保證其修改率降低穩定性提高，那我們業務拓展了，用戶需求增加了該怎麼辦呢？
- 如果大量的業務邏輯直接在前臺實現，不僅效率很低而且前臺也變得臃腫不易修改，這就形成了煙囪式單體應用，IT 界有句話說：軟件開發中遇到的所有問題都可以通過增加一層抽象來解決。中臺是基於這樣的思想，把前臺臃腫的業務邏輯沉澱到中臺，為前臺減負，把後臺眾多的服務抽象到中臺，為後臺擴展。
- 後臺：後臺中也有前端和後端，由後臺系統組成的後端平臺。每個後臺系統一般管理了企業的一類核心資源（數據+計算），例如財務系統，產品系統，客戶管理系統，倉庫物流管理系統等，這類系統構成了企業的後臺。基礎設施和計算平臺作為企業的核心計算資源，也屬於後臺的一部分。
四、各個中臺分類
- 數據中臺：通過數據技術，對海量數據進行採集計算存儲加工等工作，還要統一標準。數據中臺把後臺的數據統一好之後形成標準數據，再進行存儲，進而為前臺提供資源。
- 技術中臺：在技術平臺的基礎上增加了業務屬性。
- 業務中臺：一般指在線業務為典型特徵的中臺。在OLDI（Online Data-Intensive）時代，越來越多的企業的核心業務都是在線業務，因此把在線業務中臺簡稱為業務中臺。但對那些不是以在線業務為主的企業，它需要的業務中臺可能就不是在線業務中臺了，而是數據中臺或別的什麼中臺
五、中臺之坑
1、團隊組織的錯誤
許多團隊管理者會認為增加人力是最好的，因為他們認為人員增多會帶來效能的提高，但按照敏捷的思想，小團隊工作效能更高。
2、業務拆分的問題
業務架構者對業務拆分不夠清晰，會導致開發中造成到兩混亂信息，是團隊的管理和維護成本大大增加。
3、微服務的濫用
中臺的建設是從下而上的，中臺的需要是從上而下的。微服務不是靠量來取勝，是靠與實際業務的匹配來取勝，設置一個獨立的業務單元，單獨提供一個系統的微服務。舉例來說：某個項目中臺設計之初，拆出了 80 個微服務，20 個共同組件，應用服務器 90 臺，人員維護的成本極高。優化以後，微服務縮減到 30個，應用服務器只需要 40臺。
4、系統的過度設計
大部分微服務架構人們只能看到其結果卻看不到其架構過程，但其實不是這樣的，它既不是一步到位架構出來的也沒有必要這麼做，因為架構最基本規律就是解決當前的需求即可，它無需對沒有出現的問題負責。
5、前臺試錯的迷失
小前臺快速迭代，快速試錯，但是成功必經是少數，試錯單位越小，試錯的次數越多，越容易被人們忽略，這樣的前臺可能就被架空了，怎麼做呢？完善的管理制度加上前臺團隊人員得是高精尖人才，類似 supercell 試錯後舉辦聚會（管理制度）和 cell 中成員都是頂級人才（人員選擇）解決這一問題，supercell 還有個很大的優勢就是公司本身人數就不多，這對管理起到了一定的幫助作用。
6、利益的劃分
假使某個中臺組件支持了幾個不同的前臺，結果到最後只有一個前臺活了過來，其他都死了，那麼每個團隊最後的利益該如何分配呢，要知道這幾個死了的前臺死因可能不僅僅是產品的不合格，更多的可能是具有某種機遇成分。
7、組織架構的調整問題
此處包含組織架構調整太艱難該如何做，還有中臺團隊前期生存艱難的問題，都在在下面中臺插曲中會講到。
8、不同公司中臺架構照搬
這是不可以的！這是因為架構這種東西必須得在公司原有的基礎上調整，再一個就是每個公司業務邏輯，部門等都不相同，架構照搬是不實際的。
9、中臺團隊領導選擇問題
該選擇什麼樣的領導來帶中臺呢？給出一個最佳模板人選：技術出身，並且要十分熟悉公司的業務場景，超強溝通能力和溝通意願，公司核心員工，在公司內部工作時間長，公司內部人緣廣泛。照著這個模板尋找即可。
六、中臺建設過程中常見景象
1、中臺部門往往前期生存困難
這個問題可以說是組織架構演進過來的，各個公司前期對中臺採用試點的方式，往往效果可能是中臺部門起初總是在夾縫中求生存，這是因為中颱部門既要滿足所在公司多個不同前臺的需求，指給中臺提出了巨大的挑戰，可能每次都難以達到前臺的要求，再一個就是前臺作為戰場上直接殺敵的士兵具有更多的話語權，而中臺則是後方強有力的補給支援，即使前臺和中臺權利級別一樣，前臺可能具備更多的話語權，這對中臺的生存更加不利，中臺極有可能在初期就流產。
因此初期必須得給中臺的發展打一劑強心針，而不是任由中臺發展。怎樣才能讓中臺話語權更大？只有讓它實實在在成為產品的必經階段就行了，那如何做呢？公司可以強制規定，前臺產品產出必須得經過中臺這一階段，並且放寬初期中臺的產出結果，這相當於給中臺進行權利的補充。
2、人員變動（包括調崗和辭退）
人員進行部門調整可以理解，但是人員辭退，這是因為比如偏底層的技術人員在垂直業務領域可能不再需要。這幾年是互聯網的寒冬，今年被大廠“辭退”的員工數量也蠻多，所以我懷疑是有一部分原因是大廠在建設中臺，進行組織架構調整的結果，互聯網的寒冬可能不是那麼“寒”。
3、很多企業會進行數據中臺和技術中臺的建設
很多企業可能會先進行數據中臺和技術中臺的建設，然後業務中臺可能是留有空缺。這是因為大部分公司對技術層面和數據層面劃分較為清晰，做技術平臺或者數據平臺的團隊可以立馬拉過來繼續做一個技術中臺或者數據中臺，對組織架構的調整較少，公司做起這兩個中臺較為容易。而如果要做業務中臺就必定是要動組織架構的，動組織架構就意味著動利益分配，這其實就已經卡死很多公司了。再加上有的公司業務複雜的話，這又是一道屏障。
4、中臺部門的消亡
中臺邁過初期夾縫生存的難關後可能還面臨一個凋零消亡的問題，這與各個公司的組織管理有關，如果一箇中臺部門不與前臺部門建立良好關係，又沒與後臺部門建立良好聯繫，那麼這個中臺就危險了，不知那一天就會猝死在突發的利益衝突中。所以項目上可以安排中臺和前臺和後臺專門對接，專門建立聯繫，這個得看管理者自己的管理策略。
5、中臺團隊的選人
企業一般開始會從前臺調人，其中一定包含了能力極強的業務架構師角色，一部分技術通過招聘方式，還有一部分通過內部培養的形式。
6、先做再調組織還是先條組織再做
組織架構如何調整這一問題為何各大廠沒有詳細講明？首先如果要做中臺，那麼組織架構是必調的，調整組織架構就意味著權利和利益分配的調整，一旦涉及到利益和權利的切分，這個話題就變的有意思了（怎麼感覺和美國想禁槍一樣），所以企業要是想改組織架構，那得在做每一步選擇前都要慎之又慎，這不得不依託管理者能力，以及公司內部全員瞭解中臺的重要性
閱讀更多 程序猿技術大咖 的文章
