很多技術人總是抱怨 新技術/新框架/新概念 太多了，總是學不完，抱怨實在是學不動了。哈哈，這不，最近「 中臺 」這麼火熱，要不要停止抱怨，再咬咬牙學一波？
“很多人都擔心被技術新潮流所拋棄，所以當遇見不斷湧現的新技術時，總是慌忙的去學習。可是其中到底有多少是真正有用的？又有多少是曇花一現的技術呢？當你無法分辨的時候，其實不必慌張，當一項新技術/概念剛出現的時候，你不必匆忙的去學習，更不必擔心自己會錯過它，如果它是一個真正有價值的東西，是一個真正經受得住考驗得技術，它遲早會再次出現在你面前”
這是我很喜歡的一段話，對技術浪潮的見識太到位了。不過很慚愧，我不記得是哪位大神說的了。
回到「 中臺 」這個話題，其實中臺已經不算新潮流了，並且它還是被很多企業成功驗證過的模式了。那麼，既然這麼靠譜，咱們是否應該趕個時髦，搞一個？
在回答這個問題之前，咱們先縷一縷啥是中臺吧。
中臺 這個理念在國內最早是由阿里巴巴帶起來的，後來國內一些互聯網大廠（滴滴、京東等）也開始在內部推行，加上今年騰訊在“全球數字生態大會”上再度提起中臺架構，引起了大家一波又一波的追捧。不過這個架構理念也不是由阿里巴巴提出的，而是馬雲帶著阿里團隊拜訪 Supercell 公司學習來的。Supercell 是芬蘭一家著名的移動遊戲公司 ，我說幾個他們開發的遊戲大家就能明白了這家不到兩百人的公司有多牛逼了，比如著名的《部落衝突》《卡通農場》《皇室戰爭》。
Supercell公司公司人員人少，採用的就是“小前臺”+“部落”的模式。就是有多個“前臺”小組，這些小組就是專門用來快速研發遊戲的，每個小組雖然人員不多但它包含了開發一款遊戲所需的各種角色人員。這些“前臺”小組只關注在業務側，也就是遊戲業務研發和創新上。而對於遊戲的底層基礎設施：遊戲引擎、開發工具、服務器後臺等這些都東西，前臺小組不用去關心，這些基礎功能交由一個稱為“部落”的組織獨立去負責。這種模式就像是戰鬥小組專門去負責打仗，後勤彈藥又由另外的小組去搞定，分工明確，業務也能快速試錯、快速創新。
根據這次拜訪學習，阿里巴巴隨後宣佈組織架構全面升級，啟動中臺戰略，構建“大中臺、小前臺”的組織機制和業務機制。
在2017、2018、2019年很多互聯網大廠都對外分享了自己的中臺實踐成果，包括阿里、騰訊、京東等都為中颱戰略做出組織架構的調整。
在互聯網大廠的領頭、產業互聯網的風口，傳統企業的轉型契機下，「 中臺 」不火都不行啊。
對於中臺 的瞭解，網上資料簡直多的不要不要的，但體系化的學習，我推薦看看雲徙科技的幾位大佬新出的**《中臺戰略》這本書，以及極客時間的《說透中臺》**專欄，這兩個資料算是對中臺介紹的比較全面的。本文的部分觀點也是吸取了這些內容後的收穫，建議找來一讀。
一、「 中臺 」到底是什麼？
想了很久，想用一句簡潔清晰的語句給 中臺 下個定義，還是有點難度（嗯，沒錯，還是我的認知太淺了，哈哈）。
中臺 就是一個架構理念，它是介於前臺與後臺之間的（這句好像是廢話），它是希望將一些可複用的“能力”統一起來，採用共享的方式去建設，用來解決各個業務團隊重複開發、數據分散、試錯成本高等問題，中臺的核心就是**“對能力的共享”、“對能力的複用”**，它應該是公司內部的統一協同平臺。
另外再給個參考，在《說透中臺》專欄中王健老師將中臺定義為：
企業級的能力複用平臺
我覺得這個定義相當準確且簡潔。受不了我上面一大段囉嗦定義的同學，可以按照這個簡潔的定義去理解中臺。
上面講完了中臺的定義，我們再來看看 前臺、中臺、後臺 的區別吧。
「前臺」是直接服務客戶、觸達用戶的平臺，能夠洞察用戶需求，進行產品創新、提升用戶價值，保持精簡和足夠敏捷度的平臺。比如阿里的 淘寶、天貓、聚划算等。
「中臺」前面已經定義過了。它通過組件化的形式輸出通用能力，為所有「前臺」的業務運營和創新，提供專業能力的共享平臺。中臺部門提煉各業務線的共性需求，將各種資源轉化為方便「前臺」使用的能力，最大程度避免重複“造輪子”。
「後臺」的職能是提供基礎設施建設、服務支持，為「前臺」和「中臺」提供基礎保障。後臺會比中臺更底層、更通用。「中臺」有的時候會更關注在某一行業/領域內的，而「後臺」應該是行業/領域通用的。
要注意的是，中臺並不是專指技術，相反主流的中臺更側重於業務。
上面提到的 前臺、中臺、後臺 全部都是從用戶和職能角度出發的，很多開發同學一聽前後臺就理解成了技術架構了，技術架構中的前端展示層、技術中間層、後端數據層，與這裡的前中後臺完全不是一個概念。
阿里的中臺戰略是以業務中臺和數據中臺相結合，這也是目前市面上主流的中臺架構。
業務中臺是提供可複用的業務服務，包括如用戶中心、會員中心、訂單中心、支付中心等，既可拆箱即用，又可複用的業務能力。說白了，各個不同的業務線/業務部門其實有很多類似、共通的業務組件，大家就不要各自搞各自的了（傳說中的煙囪式、單體式項目架構），既浪費資源，也不利於協同。乾脆大家把這些共性的可複用的業務組件從前臺裡提煉出來，下沉到中臺，一起建設一起用，你好我好大家好。
數據中臺是基於技術和大數據能力為業務提供可複用的數據服務，將業務中產生出來的數據進行二次加工，將加工的結果再服務於業務，為業務賦能。但要注意的是，大家在理解上不能將數據中臺與傳統的數倉、大數據平臺劃等號。數據中臺與它們的區別是，數據中臺更貼近業務，數據中臺不只關心技術層面，不只提供分析功能，更多關心數據資產化、關心數據對業務的運用，為業務提供服務。
業務中臺與數據中臺相輔相成、互相支撐。所以現在大家也很流行的說法就是：數據業務化、業務數據化嘛。
（圖片來源雲棲社區）
除此之外，在實際應用中，也衍生出了很多其它的中臺概念，如：移動中臺、算法中臺、技術中臺、研發中臺、運營中臺、組織中臺 等等。下面挑選幾個簡單解釋一下：
技術中臺：提供通用的技術設施能力、技術中間件能力，過濾掉技術細節，像各個前臺應用提供統一的易用的技術服務，避免重複造輪子（也有人認為技術中臺不具備業務屬性，屬於技術中間件平臺，不能歸屬中臺）。
研發中臺：研發中臺是關注開發效率的平臺，將公司的開發流程、最佳實踐沉澱為可重用的能力，為應用的開發提供了流程、質量管控和持續交付的能力。
移動中臺：將移動APP開發中的通用技術、框架、業務組件等進行封裝，沉澱到移動中臺，提高移動開發組件的可複用性，方便快速構建新的APP開發（有些人對移動中臺的爭議與技術中臺類似）。
為什麼會出現這麼多的讓人眼花繚亂的中臺呢？根本原因是每個人自己的職業不同，所以看待的角度不同，出發點不同，並且每個公司的業務性質、形態也不相同。比如 電商團隊、AI團隊、運營團隊、研發團隊，他們眼中的中臺肯定都是不一樣的，但初衷是一樣的：資源的複用。
另外，這裡還得再囉嗦一句：“平臺不是中臺”。什麼意思呢？
有的互聯網企業在對公司內的模塊進行定義和表述中，並不常用“後臺”的概念，反而用“平臺”比較多。比如 大數據平臺、運維自動化平臺、財務平臺等等。這些“平臺”與我們今天描述的“中臺”並不是一回事。平臺比中臺更底層一些，更基礎一些。平臺一般是不帶業務屬性的，而中臺，確必須是具備業務屬性的，因為中颱是直接為前臺業務所服務的，是一個提煉業務能力共性的組織，在這一點上就與平臺區別的很明顯了。
二、我們要不要去建設「 中臺 」？
「中臺」這麼火，大小企業都蠢蠢欲動，各種靠譜不靠譜的平臺都往中臺的概念上靠，要乾的勁頭擋不住啊。行吧，既然要幹，咱們至少得先看看問題吧，把明顯不適合搞中臺的基本條件弄清楚嘛。
- 公司得核心業務不成熟 或 公司業務線很少
- 如果企業屬於創業公司，主業務模式都不明朗，這種情況就真的不建議搞什麼中臺的。中臺是講究多業務服務用的，咱就一個業務，這個業務還在探索，搞啥子中臺嘛，把技術平臺搞好點就可以了。
- 公司裡沒有相類似的業務
- 即使不是創業公司，是一箇中型甚至是大型公司了，但如果公司裡雖然業務多，但是每個業務線做的領域都區別很大，比如業務線1做面向C端的電商，業務線2做遊戲，業務線3做面向B端企業級產品。這種情況，很難沉澱共性的業務服務，也做不了中臺，還是拉一個團隊繼續做基礎平臺給各個業務服務吧。
- 公司沒有足夠的人力
- 人力是硬指標，即使上面說的問題都沒有，完全符合做中臺，那也得考慮考慮人員安排。畢竟中臺的建設是需要由獨立的團隊去完成，並且還應該是一個高效率的團隊（不然前臺業務會抱怨中臺響應不及時），公司是否有這部分的人力預算去建設中臺，人員從哪兒來，這個硬性條件必須提前考慮。
這篇文章闡述了 啥是中臺、要不要建中臺，但貌似缺一個“怎麼建中臺”了，這個以後聊。
另外，還有很多人擔心「 中臺 」會不會是曇花一現的新概念，我覺得糾結這個完全沒必要。當咱們充分理解了中臺，學到了其中的理念之後，它是不是曇花一現並不是很重要嘛。因為我們已經獲得了成長，獲得了視野和思維的提升，足以。您覺得呢？
閱讀更多 BigDataKer 的文章
