在當下互聯網圈子裏要問什麼最火莫過於中臺這一概念了，各大公司都開始了一輪跑馬圈地似的中臺建設，那麼到底中臺是什麼呢？本文我們就來談談這個話題。
本專欄作者：三爺 / 《中臺產品經理寶典》作者/某獨角獸B端高級產品經理/多家網站專欄作家/MBA特邀講師 / 公衆號：三爺茶館（歡迎來找我玩！）
一、什麼是前臺，後臺
在以往的互聯網企業生產流程中，我們可以將研發團隊宏觀的劃分爲前臺與後臺兩部分。
所謂前臺就是用戶直接接觸到的產品部分，如可在應用商店下載的APP，像微信、抖音、淘寶，或者可以使用的網站等。
用戶對產品的認知與體驗也由此而生。比如大家對於微信的理解就是這個前臺APP展示的一切給大家描繪的：一個綠色圖標的應用，裏面有我的A、B、C好友。
而後臺包含兩個部分：
企業的內部管理服務的統稱，如：內部的CRM，ERP等；
爲前臺提供服務能力的，如：數據壓縮能力，併發等。
後臺最重要的特點就是其提供的服務都是不被普通用戶所感知的，就像用戶不會因爲應用的併發，傳輸速度而記住微信這個品牌。
在搞清楚了前臺與後臺的概念後，前後臺模式的產品服務模式我們就可以用一張圖來概括描述：
總的來說就是在應用中後臺提供能力與計算，前臺將後臺的能力進行封裝以圖形化的形式展示給用戶，讓用戶能更容易的使用公司提供的服務來解決個人需求。
二、中臺的白話解釋
在開始談論中臺之前，我們先要明白：當下的主流前後臺模式並不是在業務實現上出現了問題，不支持眼下出現的種種新業務場景；相反地，這種前後臺反而是公司最省事省力的一種提供服務的解決方案。因爲這種模式不需要提供額外的建設，前臺完成信息展示與交互，後臺做好對應需求的解決邏輯就組成了一個產品。
實際上，中臺的出現更多是因爲公司業務在發展到某一階段時，在擁有多個業務線時繼續發展遇到瓶頸與障礙後，爲了解決如何繼續朝下走的實際問題而提出的一個組織前臺業與後臺關係新解決方案的統稱，而不是某個新的系統。
在互聯網進入日益複雜的市場環境的今天，市場中由於存在衆多的競爭者，也逼迫着企業需要不斷去更新產品去搶奪市場。
而作爲實際用戶真正接觸的前臺業務，如：APP、小程序、網站等，必須要快速迭代新的功能才能讓用戶感知到。
而在這個大背景下帶來的矛盾就是——以往爲了支撐前臺越來越多的業務，後臺不斷地建設龐大起來的系統，由於一直在追求穩定性而生，反而在這個時候顯得越發笨重起來。這樣的後臺變得越來越沒法去快速響應前端變化所帶來的改變。原來的前後臺模式的這種直接關聯決定了兩者的衝突不可避免。
例如：傳統我們的一個電商網站，由於用戶前端需要組織各種新的銷售方式（拼團，一元購等），導致每次活動頁面開發的時候，不僅需要前端重新設計頁面，從後臺接口提供與數據表都要重新設計。
這無疑大大拉長了我們的需求響應時間，很有可能會導致在活動模塊還沒開發完成，我們的風口就已經過去了。因此我們需要一個能最少改動就能完成大部分需求的解決方案，這就是中臺。
中臺解決方案到底是什麼呢？讓我們舉個通俗的例子來說，如果將互聯網公司的研發中心比作一個廚房，將研發新產品的過程比做菜的話，我們就可以很容易理解這個概念了。
首先請大家想一個問題，在一家客流量非常大的餐廳中我們要如何縮短客人的等待時間呢？
相信很多人的第一想法就是增加多名廚師，但時大多數的餐廳單純的增加廚師這是不實際的，因爲每增加一個廚師是有很高成本的，而且每天忙的就是中午和晚上這兩個時間點，雖然在飯點解決了問題，但是在一天中其他的時間裏，廚師人員就顯得非常冗餘了。
而正確的做法是先將做菜這個任務拆分，讓做菜這一件事變爲多個環節來思考。也就是將做菜變爲：
通過這樣的拆分後我們可以發現無論是做什麼菜系，買菜與配菜都是共有的兩個步驟，我們完全可以只需要增加一位配菜的小哥來代替廚師去進行前兩步，這也就是現在大多數上規模餐廳的組織架構：
這樣我們每一位廚師新做一道菜時沒有必要一定要從買菜，洗菜，切肉這些最基礎的環節開始，而是完全可以直接使用他人切好的肉片，洗好的菜下鍋，唯一需要關心的就是如何在搭配調料上研究不同的創意。完全可以大大提高廚師的做菜速度，同時在成本上我們只增加了一個人就解決了所有問題。
回到研發流程來看，買菜其實就是我們研發的後臺，他們幫助我們解決最基礎原料問題。廚師是我們的一個個業務前臺團隊，他們要做的就是根據不同地區口味烹飪出對應的菜系，而在業務多元化後洗菜，切菜，配菜都可以交給中臺解決方案去完成，做菜的時候作爲大廚只需要喊一句要什麼材料既可，當然這裏的配菜小哥就是我們的中臺。
所以說有了中臺之後我們的前臺業務就可以快速嘗試迭代，不需要每件事都是從0到1開始了。
讓我們再站在架構的層面來看看中臺對整個系統業務所起到的作用。
假設我們是一個電商平臺在我們未使用中臺的時候，每一個前臺的用戶終端都需要與後臺進行一次對接，就像下圖：
而後臺的每一個模塊都需要維持與前臺業務的關聯，並根據不同業務前臺的特徵加入適配。這樣造成的結果：
後臺的每一個模塊都需要加入與前臺適配的部分，從而大大加大了開發量；
每個前端在啓動時需要分別對接不同的後臺模塊，也加大前臺啓動時的工作量；
當後臺進行升級或架構調整時還需要考慮與前臺的對接，並進行逐一的調整。
當我們引入中臺後，讓中臺作爲一個對接層，幫我們去統一對接前臺的不同終端，同時對後臺各個子系統進行統一的封裝，讓前臺能無感知的使用各項服務而不需要單獨設計通道，我們的系統也就簡化成了這個樣子：
通過對比我們能清楚的看到中臺對於公司的整個業務架構起到了非常大的簡化作用。
用一句話來概括就是：中臺的核心本質就是服務共享，目標是支持前臺的快速創新或試錯，而實現的手段是微服務架構、敏捷基礎設施和公共基礎服務。
三、中臺解決方案
那麼到這我們可以給中臺解決方案下一個定義：
中臺解決方案的組成 = 能力輸出 + 標準化中間件
讓我們來一個個解釋：
第一部分：能力輸出
所謂能力輸出就是要規劃出什麼是公司的核心競爭力，理清楚公司發展的戰略與目標與未來公司裏的主要業務會涉及到哪些方面。並在這些業務層面中去提煉哪些模塊是以共性存在的，並會在每個新開拓的業務中不斷使用，然後就把他歸類到中臺進行建設。這也就是中臺的一個重要的意義：爲不同的前臺業務提供可以重複使用的能力，形成一次建設多次使用。
例如我們規劃了公司的核心方向是視頻方向，未來可能會涉及的業務形態有：
在線視頻
視頻直播
短視頻
……
分析上面的業務方向我們不難判斷出最基礎要抽取的模塊可以劃分爲：
在線視頻編輯
視頻壓縮
多人點播
……
完成拆分後我們就可以通過中臺去實現這幾個通用模塊。
值得提一下的是雖然這裏在說中臺要考慮複用性、擴展性，但是要考慮多少，考慮多深這裏又是一個非常考驗產品功力的地方。
還是舉上面的例子來說我在設計一個視頻社區APP的積分商城系統時，需要將商城交易方式抽象爲能力時，這裏我們大體上可以抽象爲如下三種交易方式：
但是同樣的疑問來了，我們僅僅爲了支持一個積分商城需要將中臺的複用與擴展放大要考慮引入股票交易才使用到的撮合交易模式嗎？
當然這裏的案例比較極端我們能快速判斷，但是在具體的中臺規劃中我們會碰到很多這種類似的範圍決策，我們必須要按照公司的核心業務規劃來嚴格定義中臺的能力，避免在中臺出現過度建設的現象。
第二部分：標準化中間件（整合能力，並封裝頭尾）
在我們確定了公司的業務發展需要哪些能力之後，中臺解決方案的另一個組成部分就是需要做一個將每個能力進行封裝，形成一個統一的可供前臺業務端方便使用的中間件。
這裏的統一具體表現在如下的幾個方面：
不同終端中的叫法與含義；
定義統一化的輸入輸出；
爲什麼要統一呢？
以往的前後臺模式中同一家公司內的不同業務如：直播項目組、短視頻項目組各自爲戰的時候，經常會出現一個事物被不同項目因爲場景化的需求，而出現兩個稱呼的現象，但是實際上他們本質上是同一個事物。這也是原來不同項目組想要進行復用前人的模塊時一個天然的巨大障礙——無法快速對接。
例如：就那一個用戶暱稱這個字段來看，在不同項目組中的應用中可能會叫：用戶名稱、用戶暱稱、稱號、花名等等，而在數據庫中又可能會有不同的字段名稱：username、UN、name等等。
因此我們需要一箇中心化的產物幫助我們定義好這些個通用屬性，使在公司中不同的業務端都能統一。
面對這種現象，在有了中臺後，我們就可以通過定義標準化的中間件來解決。以後假設公司內部孵化的項目組再次要使用用戶暱稱這個字段的時候，無論具體是什麼業務前端都會是一個叫法、一種存儲，這樣不僅能直接使用之前項目的模塊，同時還可以和公司內部的管理系統如CRM/BI等快速完成對接。
四、最後
在競爭日趨激烈的互聯網行業中，如何低成本又快速地完成業務創新去佔領市場是每個企業所追求的方向，而中臺解決方案的出現給我們當下的互聯網企業帶來了一個全新的發展思路。
PS：我的新書《中臺產品經理寶典》已經在京東，噹噹等各大網站上市，本書涵蓋中臺設計與企業架構建設，系統闡述了中臺起源與設計方案，對中臺以及業務建模感興趣想進階的產品經理千萬不要錯過哦！
