雲時代的數據中台（二）

• 2019 年 10 月 6 日
• 筆記

當提到數據中台，系統的架構將發生巨大的變化，將單體的架構變化為鬆散式的架構，在業內目前的兩種鬆散實現方式有什麼優缺點？

一、單體架構的幾大缺點

在java web項目中，我們習慣於將一個web程式打為一個上百兆的war包，直接傳到tomcat等應用伺服器中進行執行。但架構的缺點很多：

1、團隊協同難度大。將整個web程式打成一個war包時，一定會有各種報錯。

2、應用複雜度高， 錯誤難以隔離。任何一個小bug都有可能造成整個war包執行中斷。

3、難以橫向擴展，資源浪費嚴重。資料庫連接程式非常耗費資源，如擴展war，將把其它不需要擴容的資源同步擴容。

二、通過服務化實現數據中台的好處

1、降低團隊的協同成本，降低系統的藕合度。各團隊成員基於自己的細分工作進行軟體包開發。

2、避免單個程式錯誤造成整個程式的崩潰。

3、便於擴容，節省資源。可以針對資料庫連接、web程式進行單獨的擴容，而其它資源佔用低的程式可不擴容。

三、數據中台的服務化改造兩個辦法

數據中台的理念需要將共同的服務提煉出來，為上層的應用提供服務，服務化的模組為數據中台。該模式有兩個要求：1、不允許跨級調度。2、只允許應用層向下調用數據中台服務，而數據中台不允許向上調度數據。

業務目前採用微服務的服務化改造、ESB中心化的兩種服務化改造方式，實際這兩種方式都是SOA服務化的具體體現。只是ESB經過廠商的大力宣傳，快成為了SOA的代名詞，而這是誤解。

1、普通企業流行ESB型的SOA服務化方式，中心化方式。ESB架構比通過系統間「點對點」直接連接的方式，有了服務協議轉換、負載均衡、服務路由、服務註冊、服務優先順序等優勢。主要實現了不同軟體架構的業務系統之間的互通。

2、互聯網公司流行容器化的SOA服務化方式，去中心化方式。面向互聯網業務的不可預測性，採用ESB方式，難以進行平滑擴容、且存在單點故障。互聯網企業很少採用ESB。相比中心化的服務架構，服務提供者與調用者之間僅在第一次有服務發現的機制，而在數據交互通，採用直通方式。採用直通方式，數據格式轉換的功能由程式自行完成。

我們可以發現以去中心化的方式，一般面向企業內部的系統，這樣便於規定統一的數據接入協議、數據標準。