雲時代的數據中台（一）

• 2019 年 10 月 7 日
• 筆記

近段時間，我們在拜訪客戶領導層的過程中，明顯感覺到客戶對於雲時代有了新的要求：從省錢提效到希望直接支撐業務。有來自外部的壓力、也有來自技術的革新，因此雲時代的需求變了，IT架構該如何隨之變化？

一、架構IT向中台轉型

比較經典的案例，芬蘭的SuperCell遊戲公司，員工僅200餘人，但年均稅前利稅15億美元，甚至超過了中國的運營商年利潤，非常驚人的數字。該公司的架構為典型的大中台、小前台，3-7個員工組成一個小組，不斷開發新的遊戲，成功就繼續養大，失敗則馬上轉換。高效的運營模式來自於長期的演算法、圖形庫的沉澱，使用前台開發人員可以在幾周時間內開發出遊戲，並上市試運行。

二、企業的中台IT架構轉型之路

一般企業的IT系統從OA綜合辦公開始起步，逐步開始有CRM客戶資源管理系統，多個系統擁有獨立的資料庫，形成了煙囪系統。為便於數據的統一分析、便於數據的統一管理，希望將用戶的數據能統一，避免重複登陸不同的系統，開始出現了數據中台的需求。

採用系統打通的方式實現數據交互，治標不治標。為了打通這些孤立的系統，開始出現了單點登陸、SOA的數據交互方式，像IBM等廠商均推出了自己的ESB業務匯流排產品，橫行江湖。但時間不久，ESB產品也無法滿足業務交互的需要：當封裝好的服務一旦被固定來了，出現新的業務需求時需要改變原有的服務，為避免影響原有的架構，升級原服務模組的代價很大，造成有新業務需求的系統只能自己開發，又形成了新的煙囪。一方面原因還是因為這些不同的業務系統擁有不同的資料庫，數據仍是分散的。曾親眼目睹某數據共享交換系統的數據是5個月之間的老數據。另一方面原因是缺乏自主疊代功能開發能力，增加功能需走複雜的採購流程。最後是系統之間是平等地位，沒有共同服務者的存在，新的業務需求沒有責任主體去落實。實際除了一些擁有自主開發能力的公司，一般的政務、國企的業務系統直到今天依然採用此模式。

以共享平台式的數據中台架構支撐服務的重用。一些共享的功能，如用戶名密碼的鑒權，各個業務系統均需要，需要形成共用的能力，由一個共享的部門支撐其運營。這樣後，前台的業務系統只需要與共享部門提供的IT數據中台互通，而不需要在前台業務系統之間進行數據互通，業務的復用性得到了很好的提升。由於不需要複雜的業務互通，在此階段，ESB一般不會再繼續存在。目前數據中台一般採用Http Restful輕量化的方式進行數據互通，中間只有輕量化的註冊中心、數據路由模組。

三、架構IT是否是數據中台型最好？

架構是伴隨企業的成長而成長，在小型企業也許煙囪式的系統就挺好，簡單、成本低。

而隨著企業的成長，it也隨之變化，ESB、數據中台式的演化也是正常的路徑。