雲時代的數據中台（三）

一、從技術角度，為什麼採用ESB的數據中台不適合互聯網場景？

1、ESB的數據交換匯流排成了整個系統的核心瓶頸。

2、去中心化的服務架構提供直連方式。

綜上，像電商系統，一個「結算」、「下單」按鈕，後台將調用超200次服務，如果用ESB的方式，收到資訊的回應將超過幾秒鐘，客戶體驗不好，而且ESB中間件的壓力也非常大。另外，如果ESB出現故障，將直接造成所有的業務系統down機。

二、如果對ESB進行擴展，能否滿足互聯網應用需要？

如果我們估計業務量需要5台ESB伺服器同時以集群方式提供服務，並考慮了20%的冗餘。如果此時故障了一台伺服器，另外4台伺服器處於100%的負載狀態，業務量只需增加1%將直接導致雪崩效應，所有的伺服器全部中斷。

而當業務故障恢復時，也不能僅恢復1、2台就開始承載業務，必須將所有的5台ESB伺服器全部恢復後（此時業務處於完全中斷狀態），才能放開業務。否則雪崩效應將再次發生。

而去中心化的架構，業務的高峰擁堵只會發生在某些高負載的模組，不會影響其它業務模組，我們也可以針對高負載的模組進行針對性的擴容。

越來越多的企業、互聯網公司已拋棄ESB型的中心化架構。

三、採用去中心化的結構，如何保障高可用？

各位一定會聯想到，採用雲中心化的結構，服務調用者、服務提供者採用直連方式，而當某服務節點中斷時，備用的服務節點如何接替服務？

在正常工作狀態，服務調用者通過註冊中心服務提供者的地址，當服務者提供者故障時，註冊中心將備用的服務節點地址發送給服務調用者，以保障高可用。

同時註冊中心還可以根據服務提供者的工作負載，提供服務路由權重等功能。