為什么建中臺

一、前言

離數學越遠代碼，價值越低！

代碼編程是對數學邏輯的具體實現，就相當于用磚頭蓋個廁所、碼個豬圈、砌出個磚墻等是一樣，磚還是那批5毛錢的磚，但蓋在哪里蓋出了啥價值就不一樣了！

程序員也一樣，你碼的磚是公司里的；核心組件、通用模塊、高并發業務還是一些ERP查詢、接口包殼、屎山尋寶呢？通常那些復雜的業務邏輯或者具備一定技術深入的核心組件，才是最讓人程序員快速成長的地方。

當然有些時候沒有辦法，不是不想做而是沒得機會，或是因為初入職場、或是由于部門較差、也可能更多的是當前自身能力不足等等。但終究成長是自己事情，有了方向快是最大的障礙，腳踏實地把自己武裝起來，才有談判的機會！ 

二、為什么建中臺？ 

1. 什么時候熱的

通過百度指數搜索中臺關鍵詞，發現它是從19年5月21日突然熱起來的，如下圖；

    

2. 怎么就熱了呢

說來奇怪怎么中臺就熱了呢，發生了啥？

 

• ??！怪不得，是流量大佬騰訊于     19年5月21日召開了全球數字生態大會，會議上騰訊高級副總裁     湯道生提出“開放中臺能力，助力產業升級”。
• 原文：騰訊湯道生：騰訊開放中臺能力 助力產業升級

3. 中臺從哪來的

你玩過《海盜奇兵》嗎？那《部落沖突》、《皇室戰爭》呢？咋滴，玩游戲還和中臺有關系？

• supercell（超級細胞），芬蘭移動游戲巨頭。擁有《部落沖突》、《卡通農場》、《海島奇兵》、《皇室戰爭》和《荒野亂斗》 [1]  等全球熱門游戲。
• 芬蘭移動游戲巨頭supercell在2016年3月宣布，公司旗下游戲每日活躍用戶（DAU）人數已經突破1億。這家公司的CEO?？āづ思{寧（Ilkka Paananen）在推特上分享了這個消息，并向全球玩家表示感謝。
• 在Supercell，每個獨立游戲開發團隊，稱為“細胞”團隊，核心人員通常只有5人，最多也不會超過7人。員工雖然少，但都是行業頂尖人才，還有充分的自由度。
• 團隊自己決定做什么樣的產品，然后最快時間推出產品公測版，看看游戲是否受用戶歡迎。如果用戶不歡迎，迅速放棄這個產品，再進行新的嘗試，期間幾乎沒有管理角色的介入。
• 團隊研發的產品失敗后，不但不會受到懲罰，甚至還會舉辦慶祝儀式，以慶祝他們從失敗中學到了東西。
• 2015年年中，馬云帶領阿里巴巴集團高管，拜訪了位于芬蘭赫爾辛基的移動游戲公司Supercell。
• 騰訊控股與其他參與財團已于2016年6月21日下午6點左右（北京時間）發布最新消息，確認已同意透過買方（財團的全資附屬公司）收購Supercell的大部分股權。

綜上，一個馬老板收購了大部分股權，另一個馬老板從 Supercell 團隊開發模式，聞到中臺的味道，細胞和部落 對應 小前臺和大中臺，至此半年后每一個程序員都被中臺洗禮了。

三、建了哪些中臺？

1. 技術中臺

 

• 難度：????
• 描述：技術中臺提供了建設系統所需的基礎設施、開發環境、數據服務、分布式能力等各類底層技術問題，同時技術中臺有時也涵蓋了研發中臺的概念，主要是為了幫助工程的快速搭建、測試、集成、交付、運維、監控等。
• 備注：技術中臺基本是每個公司必備的，但可能每個公司會有多套測試環境、預發環境、上線環境，以及各類技術組件存在多套。建設中臺的時候需要把這些能力進行整合，統一建設，統一維護。

2. 數據中臺

 

• 難度：????
• 描述：數據中臺提供數據采集、運算、分析、算法等數據動作，并提供相應的數據服務；量化指標、人群標簽、知識圖譜、業務報表等。

3. 業務中臺

 

• 難度：?????
• 描述：業務中臺提供可復用的服務能力，例如：交易、支付、活動、用戶、訂單等，這些服務可以標準化、簡單化、統一化。
• 備注：中臺最想也最難的就是對業務中臺的處理，支持淺了滿足不了業務訴求、支持深了又太個性化滿足不了所有需求。同時每一塊業務拆分時可不只是系統，還有相應的業務、產品、運營，他們該如何提需求又提給誰。提的太復雜中臺做不了，給后臺做，做多了又想著平臺化了。所以這也是最難的一塊！

四、剛建好又要拆？

原來是建中臺火，現在突然變成拆中臺了。如果不是阿里自己說要拆中臺，可能其他人也不敢說！

拆中臺的起因是阿里內網說中臺太厚了，影響到業務發展和敏捷響應能力。為啥這么說呢？

 

說白了，中臺、低代碼這些概念的指導結果，都是為了通用性服務的組裝和編排。對于創新型顛覆式的需要快速試錯的業務場景，就不太容易使用中臺搭建。

但中臺很適合類似盒馬這樣的場景誕生，有用戶、有訂單、有支付、有營銷一整套的服務在中臺都可以支撐，對于快速建設同類服務就變得非常容易。

可一些創新性，中臺不具備或者不完全具備的服務，在通過前臺、中臺、后臺，就變得非常困難，所有的需求沒得把中臺擊穿就已經錯過了市場。所以說中臺太厚了，要拆中臺。

1. 新需求響應難度增加

當中臺為了通用性、共用性、平臺性的原則建設新需求的時候，實際對業務響應的敏捷度就是下降的。

這包括一個新需求，不需要你的流程太長、也不需要你的通用性、甚至可能不需要你做完整的分庫分表、數據采集、接口通用等等，如果你都按照中臺的方式建設，那么這一個小需求的整體時間成本都將翻倍。

所以當這樣的需求越來越多以后，你會發現建設的中臺并沒有沉淀下可復用的服務，這些服務最終后被前臺系統沉淀下來。本來希望是中臺做的厚一些，現在看是前臺變得更厚了，前臺對中臺的依賴也越來越小了。這主要是因為前臺離需求變化最近，敏銳度最高

2. 服務集成復雜度增加

中臺提供了大量可復用的接口，但一個需求的實現會需要很多中臺的接口集成，最終因為這些接口串聯、組合、調試都過于冗長，使得效率不增反降。

原本一個需求由一個組可以實現，現在依賴中臺需要很多組開會、協同、排期，嚴重拖慢了交付的進度，同時也不一定能提高交付質量。

3. 可復用實現難度增加

如果為了可復用則需要把一個需求放大，考慮它會發展成什么樣，將來要擴展出哪些功能，留出什么樣的口子，打哪種地基建設?；诟黜椀目紤]把各類支撐需求的服務抽象化、去業務化，提取共性支撐業務組裝。

這就像中間件的建設是為了屏蔽底層差異化一樣，而你屏蔽的時候各類業務的差異化，而一個業務需求的變更都可能會影響到實際抽離出的業務組件該如何支撐。如果因為中臺的通用性不能支持差異化需求，那么這類需求就會被建設在前臺。

所以一個公司原本就沒有很深、很廣、很足的業務場景覆蓋度，那么中臺的建設會成為需求的絆腳石，投入的人力也將增大，每一次需要構建和完善時也會成為中臺建設的災難。