酒瓶和水
中臺的概念在今年突然很火，持續地火。產品不蹭一下中臺的熱點，自己都覺得不好意思。於是乎，看到了高矮肥瘦的各式各樣的瓶子，都說是中臺的酒瓶，裏面有新瓶裝舊酒的，更多的是裝些果汁，礦泉水，不少的直接裝自來水，甚至只裝空氣。只要不打開看，放在架子上，裝扮得五光十色，十分喜慶。
需求是第一導向
中臺是個概念，是個名詞，尚無權威定義，本文也不打算討論何爲中颱。下定義的人多了，但被認可要靠權威，我們頂多能發表下看法。公司裏面已經聚合的能力集，無論有沒有中臺的概念，它就擺在那，叫能力雲也罷，叫中臺也好，它都老老實實地杵在那裏。
碰到更多的是蹭熱點，言必稱中臺，恍惚貼上中臺的標籤，身價上漲。紅紅火火的程度，以至於這個功能好像挺不錯，可不可以抽出來做中臺，那個能力也很好，要不要也弄過來做中臺。這些話聽多了，我其實很想說，同學，你想多了。
任何產品的第一導向都是需求，成爲中颱不是說這個功能好不好，是否可以獨立出來，這寫只是成爲中颱的充分條件。我們需要意識到下面幾點：
一、有沒有成爲中颱的需求。
中臺的最重要目的是避免重複造輪子。我們首先要看有多少人需要這樣輪子，而不是說能不能做出個輪子。也就是說首要考慮是要不要的問題，而不是能不能的問題。即是有多少項目有這個需求，以及如果真成爲中颱，有多少項目會去用。
如果我們在公司內部做一個需求調研，問將某某做成中臺好不好，多半好；問你們會用嗎，不少答會。但實際做出來後，可沒那麼多人捧場。將接入中臺作爲一種可選方案納入考慮，和最終決定是否採用中臺，兩者的差距不言而喻，但在調研問卷分析，經常會被忽略。如果兩者數據基本一致，那針對的就是痛點問題，又或者簡單粗暴的領導要求。
反過來思考，如果我們要決策是否使用某中臺，我們需要考慮，這個功能是否與我們核心業務緊耦合，其流程是否視爲黑盒。一般來講，數據中臺、運維中臺都不會觸及我們的上層的業務；而能力中臺，其內部實現的流程和我們業務解耦，是我們業務調度或者業務編排的一個單位，也就是說在開發的過程中，我們不需要調整該功能的內部流程，增加新的參數或者特性，中臺應能覆蓋我們的需求，無需個性化定製，並在性能上提供足夠的支持。
二、有沒有成爲中颱的共享基礎設施。
和大廠有自己的數據中心不同，小公司的基礎設施通常不是自建的，可以是在某某公有云，某某IDC機房，客戶自有機房，即使在在同一個某某雲上，可能是公司自己租的，也可能是客戶指定的，可能是在深圳節點，也可能是在上海節點。如果多個項目的生產環境無法在同一個基礎設施上，就存在兩個問題：一是網絡聯通問題；二是網絡性能問題。
我們要考慮在生產環境的實際部署中，業務節點和中臺節點的網絡是否能滿足需求。
三、建設中臺能不能節省成本。
中臺的一個重要目的是節省成本，集中力量辦大事。將共性的抽離出來，作爲平臺實現，不用每個項目組開發，另外將分散到各個項目組從事相似工作的開發人員集中起來，可以構建一個功能更爲完善，性能更爲強大的平臺。
但請不要忘記，中臺本身是有成本的，而且成本還不小，需要有專門的中臺團隊來進行開發和維護，存在跨團隊合作（如，想中臺團隊提需求）的溝通和時效成本。最終能否節省成本，在於邊際效益，接入的項目越多，中臺成本攤分越薄。所以，中臺適合大廠，對於小公司，先算一算帳，到底是增加成本還是節省成本。
選擇和演進
前面講到中臺是有成本的，需要單獨的運維。就開發而言，項目內部一個邊界清晰的模塊，要獨立出來成爲一個平臺，成爲一個多個項目共同使用的內部產品，也不是那麼容易。最大的就是模塊和產品的差異：
- 作爲一個模塊用於某個項目，相當於單租戶；作爲產品用於多個項目，就是多租戶了，就要有租戶的配置、管理、授權，不同的統計視圖，獨立的運維繫統，這些在單項目內都無需考慮。
- 原來的一些控制功能，如限流，是由項目統一實現，例如在第三方接入網關中實現，模塊本身可以不考慮，但是作爲平臺產品，這類的控制功能就必須要有。
- 作爲平臺，服務的量級不同，量變引發質變，很可能會引發實現的架構的不同，需要進行重構。
中臺並不是解決重複造輪子的唯一方法。
最簡單的就是代碼複用。以java爲例，就是封裝爲jar包，提供其他項目組使用。我們在自己的項目中也會複用到很多開源項目的代碼，例如json的解析，如此細小的功能，有時會讓我們忽略掉，其實這也是個開源項目。
人員複用也是一種變相的代碼複用。對於某方面資深程序員，專職從事某特定領域的開發，被不同的項目組共享。他可以根據各項目不同的需求，快速地定製地開發出各項目的所需。
進一步，可以採用第三方接入的方式。對於一個服務提供方來說，除了推廣自己的應用外，還可以把服務以 API 方式開放出來，讓更多的應用接入自己的服務。也就是某個項目開發出來的業務或功能，如果其他項目組所需，是可以採用第三方接入的方式，通過Restful API接口來接入該服務，相關授權方式比較流行的是OAuth2.0。
如果項目的某業務或功能集有越來越多的內部第三方接入，並慢慢地以此爲主要的請求來源，就可以開始考慮中臺化。這是逐步演變，水到渠成的過程。對內服務，我們稱之爲中颱，對外服務，我們稱之爲雲能力。很多時候，內和外的界限是模糊，有內有外，反正就一稱呼，不要太糾結。
天花亂墜：數據聚合
在各類的中臺中，數據中臺比較特殊，我總有種以中臺之名實施數據霸權的感覺。
“中”就是在“前”和“後”之間。一般來講，輸入是項目A，輸出也是項目A；輸入是項目B，則輸出爲項目B，項目A和項目B的數據是隔離的。然而，數據中臺實現的是數據匯聚，從不同的項目中獲取數據來源，將這些數據綜合起來，一起進行數據分析，在更宏大的視角中得到更精確的圖譜。
數據爲王，數據中臺在大型互聯網公司中具有很高的價值。很多時候，已經不是“前”和“後”的中間，僅僅將項目作爲一個數據源。
一旦將各方的數據匯聚，想象的空間就大了，至於多大，看心有多大，可以天女散花，可以天花亂墜。