[[279476]]

很多技術人總是抱怨 新技術/新框架/新概念 太多了，總是學不完，抱怨實在是學不動了。哈哈，這不，最近「 中臺 」這么火熱，要不要停止抱怨，再咬咬牙學一波?

“很多人都擔心被技術新潮流所拋棄，所以當遇見不斷涌現的新技術時，總是慌忙的去學習。可是其中到底有多少是真正有用的?又有多少是曇花一現的技術呢?當你無法分辨的時候，其實不必慌張，當一項新技術/概念剛出現的時候，你不必匆忙的去學習，更不必擔心自己會錯過它，如果它是一個真正有價值的東西，是一個真正經受得住考驗得技術，它遲早會再次出現在你面前”

這是我很喜歡的一段話，對技術浪潮的見識太到位了。不過很慚愧，我不記得是哪位大神說的了。

回到「 中臺 」這個話題，其實中臺已經不算新潮流了，并且它還是被很多企業成功驗證過的模式了。那么，既然這么靠譜，咱們是否應該趕個時髦，搞一個?

在回答這個問題之前，咱們先捋一捋啥是中臺吧。

中臺 這個理念在國內最早是由阿里巴巴帶起來的，后來國內一些互聯網大廠(滴滴、京東等)也開始在內部推行，加上今年騰訊在“全球數字生態大會”上再度提起中臺架構，引起了大家一波又一波的追捧。不過這個架構理念也不是由阿里巴巴提出的，而是馬云帶著阿里團隊拜訪 Supercell 公司學習來的。Supercell 是芬蘭一家著名的移動游戲公司 ，我說幾個他們開發的游戲大家就能明白了這家不到兩百人的公司有多牛逼了，比如著名的《部落沖突》《卡通農場》《皇室戰爭》。

Supercell公司公司人員人少，采用的就是“小前臺”+“部落”的模式。就是有多個“前臺”小組，這些小組就是專門用來快速研發游戲的，每個小組雖然人員不多但它包含了開發一款游戲所需的各種角色人員。這些“前臺”小組只關注在業務側，也就是游戲業務研發和創新上。而對于游戲的底層基礎設施：游戲引擎、開發工具、服務器后臺等這些都東西，前臺小組不用去關心，這些基礎功能交由一個稱為“部落”的組織獨立去負責。這種模式就像是戰斗小組專門去負責打仗，后勤彈藥又由另外的小組去搞定，分工明確，業務也能快速試錯、快速創新。

根據這次拜訪學習，阿里巴巴隨后宣布組織架構全面升級，啟動中臺戰略，構建“大中臺、小前臺”的組織機制和業務機制。

在2017、2018、2019年很多互聯網大廠都對外分享了自己的中臺實踐成果，包括阿里、騰訊、京東等都為中臺戰略做出組織架構的調整。

在互聯網大廠的領頭、產業互聯網的風口，傳統企業的轉型契機下，「 中臺 」不火都不行啊。

對于中臺的了解，網上資料簡直多的不要不要的，但體系化的學習，我推薦看看云徙科技的幾位大佬新出的**《中臺戰略》這本書，以及極客時間的《說透中臺》**專欄，這兩個資料算是對中臺介紹的比較全面的。本文的部分觀點也是吸取了這些內容后的收獲，建議找來一讀。

一、「 中臺 」到底是什么?

想了很久，想用一句簡潔清晰的語句給 中臺 下個定義，還是有點難度(嗯，沒錯，還是我的認知太淺了，哈哈)。

中臺 就是一個架構理念，它是介于前臺與后臺之間的(這句好像是廢話)，它是希望將一些可復用的“能力”統一起來，采用共享的方式去建設，用來解決各個業務團隊重復開發、數據分散、試錯成本高等問題，中臺的核心就是**“對能力的共享”、“對能力的復用”**，它應該是公司內部的統一協同平臺。

另外再給個參考，在《說透中臺》專欄中王健老師將中臺定義為：

企業級的能力復用平臺

我覺得這個定義相當準確且簡潔。受不了我上面一大段啰嗦定義的同學，可以按照這個簡潔的定義去理解中臺。

上面講完了中臺的定義，我們再來看看 前臺、中臺、后臺 的區別吧。

「前臺」是直接服務客戶、觸達用戶的平臺，能夠洞察用戶需求，進行產品創新、提升用戶價值，保持精簡和足夠敏捷度的平臺。比如阿里的 淘寶、天貓、聚劃算等。

「中臺」前面已經定義過了。它通過組件化的形式輸出通用能力，為所有「前臺」的業務運營和創新，提供專業能力的共享平臺。中臺部門提煉各業務線的共性需求，將各種資源轉化為方便「前臺」使用的能力，最大程度避免重復“造輪子”。

「后臺」的職能是提供基礎設施建設、服務支持，為「前臺」和「中臺」提供基礎保障。后臺會比中臺更底層、更通用。「中臺」有的時候會更關注在某一行業/領域內的，而「后臺」應該是行業/領域通用的。

要注意的是，中臺并不是專指技術，相反主流的中臺更側重于業務。

上面提到的 前臺、中臺、后臺 全部都是從用戶和職能角度出發的，很多開發同學一聽前后臺就理解成了技術架構了，技術架構中的前端展示層、技術中間層、后端數據層，與這里的前中后臺完全不是一個概念。

阿里的中臺戰略是以業務中臺和數據中臺相結合，這也是目前市面上主流的中臺架構。

業務中臺是提供可復用的業務服務，包括如用戶中心、會員中心、訂單中心、支付中心等，既可拆箱即用，又可復用的業務能力。說白了，各個不同的業務線/業務部門其實有很多類似、共通的業務組件，大家就不要各自搞各自的了(傳說中的煙囪式、單體式項目架構)，既浪費資源，也不利于協同。干脆大家把這些共性的可復用的業務組件從前臺里提煉出來，下沉到中臺，一起建設一起用，你好我好大家好。

數據中臺是基于技術和大數據能力為業務提供可復用的數據服務，將業務中產生出來的數據進行二次加工，將加工的結果再服務于業務，為業務賦能。但要注意的是，大家在理解上不能將數據中臺與傳統的數倉、大數據平臺劃等號。數據中臺與它們的區別是，數據中臺更貼近業務，數據中臺不只關心技術層面，不只提供分析功能，更多關心數據資產化、關心數據對業務的運用，為業務提供服務。

業務中臺與數據中臺相輔相成、互相支撐。所以現在大家也很流行的說法就是：數據業務化、業務數據化嘛。

(圖片來源云棲社區) 

除此之外，在實際應用中，也衍生出了很多其它的中臺概念，如：移動中臺、算法中臺、技術中臺、研發中臺、運營中臺、組織中臺 等等。下面挑選幾個簡單解釋一下：

技術中臺：提供通用的技術設施能力、技術中間件能力，過濾掉技術細節，像各個前臺應用提供統一的易用的技術服務，避免重復造輪子(也有人認為技術中臺不具備業務屬性，屬于技術中間件平臺，不能歸屬中臺)。

研發中臺：研發中臺是關注開發效率的平臺，將公司的開發流程、最佳實踐沉淀為可重用的能力，為應用的開發提供了流程、質量管控和持續交付的能力。

移動中臺：將移動APP開發中的通用技術、框架、業務組件等進行封裝，沉淀到移動中臺，提高移動開發組件的可復用性，方便快速構建新的APP開發(有些人對移動中臺的爭議與技術中臺類似)。

為什么會出現這么多的讓人眼花繚亂的中臺呢?根本原因是每個人自己的職業不同，所以看待的角度不同，出發點不同，并且每個公司的業務性質、形態也不相同。比如 電商團隊、AI團隊、運營團隊、研發團隊，他們眼中的中臺肯定都是不一樣的，但初衷是一樣的：資源的復用。

另外，這里還得再啰嗦一句：“平臺不是中臺”。什么意思呢?

有的互聯網企業在對公司內的模塊進行定義和表述中，并不常用“后臺”的概念，反而用“平臺”比較多。比如 大數據平臺、運維自動化平臺、財務平臺等等。這些“平臺”與我們今天描述的“中臺”并不是一回事。平臺比中臺更底層一些，更基礎一些。平臺一般是不帶業務屬性的，而中臺，確必須是具備業務屬性的，因為中臺是直接為前臺業務所服務的，是一個提煉業務能力共性的組織，在這一點上就與平臺區別的很明顯了。

二、我們要不要去建設「 中臺 」?

「中臺」這么火，大小企業都蠢蠢欲動，各種靠譜不靠譜的平臺都往中臺的概念上靠，要干的勁頭擋不住啊。行吧，既然要干，咱們至少得先看看問題吧，把明顯不適合搞中臺的基本條件弄清楚嘛。

公司得核心業務不成熟 或 公司業務線很少

如果企業屬于創業公司，主業務模式都不明朗，這種情況就真的不建議搞什么中臺的。中臺是講究多業務服務用的，咱就一個業務，這個業務還在探索，搞啥子中臺嘛，把技術平臺搞好點就可以了。

公司里沒有相類似的業務

即使不是創業公司，是一個中型甚至是大型公司了，但如果公司里雖然業務多，但是每個業務線做的領域都區別很大，比如業務線1做面向C端的電商，業務線2做游戲，業務線3做面向B端企業級產品。這種情況，很難沉淀共性的業務服務，也做不了中臺，還是拉一個團隊繼續做基礎平臺給各個業務服務吧。

公司沒有足夠的人力

人力是硬指標，即使上面說的問題都沒有，完全符合做中臺，那也得考慮考慮人員安排。畢竟中臺的建設是需要由獨立的團隊去完成，并且還應該是一個高效率的團隊(不然前臺業務會抱怨中臺響應不及時)，公司是否有這部分的人力預算去建設中臺，人員從哪兒來，這個硬性條件必須提前考慮。

這篇文章闡述了 啥是中臺、要不要建中臺，但貌似缺一個“怎么建中臺”了，這個以后聊。

另外，還有很多人擔心「 中臺 」會不會是曇花一現的新概念，我覺得糾結這個完全沒必要。當咱們充分理解了中臺，學到了其中的理念之后，它是不是曇花一現并不是很重要嘛。因為我們已經獲得了成長，獲得了視野和思維的提升，足以。您覺得呢?