當SOA理念在業界風行之時，ESB便成為一種主流方案，由於傳統原因，一時間人們認為ESB是SOA理念的最佳實踐，甚至是唯一的實現，這就是人們所說的“中心化”服務架構。
隨著互聯網架構和技術的普及，互聯網公司流行一種“去中心化”的服務架構，阿里的HSF服務架構為代表。
我們就以“中心化”（ESB）與“去中心化”（HSF）兩種服務架構展開對比說明，由於篇幅原因，本次博客先著重介紹ESB。
說到SOA理念後，我們先看看SOA的主要特性：
1）面向服務的分佈式計算
2）服務間鬆散耦合
3）支持服務的組裝
4）服務註冊和自動發現
5）以服務契約方式定義服務交互方式
接下來了解一下ESB服務架構方案的誕生所解決的問題以及背景。
回顧2004年左右業界提出SOA理念的背景，正是大型軟件公司已經發現，越來越多的企業在多年的IT建設過程中，逐漸構建了越來越多的IT系統，這些IT系統無不例外都是採用“煙筒式”系統建設模式而建立的，使得企業內的各種系統紛繁林立，這些系統各種各樣，最終的結果就是各個系統所採用技術平臺、框架、開發語言各異。
隨著企業業務的發展，需要實現這些系統間交互時，SOA理念的架構相比通過系統單方面“點對點”直接互通的模式，很好地避免了因為服務提供者服務接口的變化，需要調用此服務的調用者都進行修改的現象，而只需在ESB上進行一次調整，便實現了對服務接口變化帶來影響的隔離。ESB架構降低了系統間的耦合，更方便、高效地實現了對新系統的集成，同時也在服務負載均衡、服務管控等方面提供了相比“點對點”模式跟專業的能力。
所以當SOA的理念一提出，得到了企業客戶的一致青睞，希望通過SOA項目實現各系統間更有效的互聯互通。至此，各大軟件廠商紛紛推出了自己的SOA產品，ESB方案橫空出世。在ESB這樣一箇中心服務總線上，提供了諸如對各種技術接口（HTTP、Socket、JMS、JDBC等）的適配接入、數據格式轉換、數據裁剪、服務請求路由等功能。主要目的就是讓企業客戶的IT系統能基於SOA的產品（ESB）實現互聯互通，同時提高開發集成效率，更快地實現SOA項目的落地。
在軟件廠商的推動下，一時期ESB方案成為SOA理念實現的主流。
既然ESB那麼好，它就沒有什麼缺點嗎？當然有了，不過問題的產生並不是當下就立即顯示出來的，所以並不是凡是用到ESB方案的就一定會遇到接下來說的問題，因為這完全看你公司的發展。
ESB方案會產生以下兩點問題：
1）服務調用方式的不同帶來業務的響應和擴展成本問題
2）“雪崩”效應嚴重束縛了“中心化”服務框架（ESB）的擴展能力
服務調用方式的不同帶來業務的響應和擴展成本問題
傳統ESB的服務調用方式是，每一次服務的調用者要向服務提供者進行服務交互請求時都必須通過中心的ESB來進行路由，如下圖：
每一次服務交互如下
服務調用者→ESB→服務提供者→ESB→服務調用者
我們發現經過服務總線路由過的服務交互，共出現4次網絡會話創建和數據傳輸。
如果“點對點”的服務交互，一次服務的調用只有兩次網絡會話創建和數據傳輸，比ESB方案的開銷整整減少了一半。
當整個平臺或企業內的應用都是基於服務化架構建設的時候，一次網頁上的點擊請求就不會像之前那樣，所有的代碼邏輯都在一個應用實例中就能完全處理，而需要通過調用多個遠程的服務來完成整個業務請求的處理。例如：在淘寶上點擊“立即下單”或“結算”按鈕進行下訂單的請求時，後端調用了200多個服務，也就是一次頁面的請求產生了後端上百臺不同服務器間的服務交互。試想一下，如果是採用服務總線的方式，每次服務請求都比直接交互的方式有一倍的網絡開銷，那我們可能很難體驗到平均在200~300毫秒就能看到訂單創建成功的頁面，如果用幾秒，甚至更長時間創建訂單，那麼就不會有今天的淘寶。
從邏輯上看，所有服務調用都通過服務總線，服務總線的訪問和計算壓力都會非常大。所有的企業服務總線產品也都可採用集群部署的方式進行壓力的分擔，實現服務路由能力的線性擴展，但是性能能不能成線程的提高，這就很難說了。還有一般企業服務總線包含的功能非常多，比如服務發現、註冊、路由、協議轉換、接口監聽等功能，使得企業服務總線一般對服務器的要求都比較高，所以每一次企業服務總線的擴容升級都會帶來在軟件授權和硬件資源上面有巨大的投入。
“雪崩”效應嚴重束縛了“中心化”服務框架（ESB）的擴展能力
上面只是從用戶的體驗、平臺的擴展以及網絡成本來討論“中心化”的劣勢，但這還不是今天很多企業客戶或互聯網企業不選擇“中心化”服務框架的最重要原因，根本原因是“中心化”架構可能給平臺帶來災難性的“雪崩”效應。
基於企業服務總線構建的服務體系，會成為企業服務調度的核心樞紐，當前很多企業還只是將企業服務總線用於企業內部系統間的互聯，但隨著互聯網轉型浪潮的到來，會有越來越多的業務是面向互聯網公眾開放的，帶來更多的服務調用和交互。簡單說，不管是因為企業業務規模自身的發展還是外部環境的變化，一旦有更多的服務調用和交互的場景，傳統企業服務總線的架構就暴露出“硬傷”。
更多的服務調用給企業服務總線帶來了更多的服務路由壓力，這時必然會採取集群部署的方式，對這些服務請求提供負載均衡和高可用性的保障。但是在這個表面看來萬無一失的架構中，卻隱藏著巨大的風險。
假設按服務訪問的峰值100估算出了所需企業服務總線的集群數量是10臺。當達到峰值時，每個企業服務總線的負載水位會達到80%。按照理論，日常運行中不會有太大的問題。但在現實中，當訪問峰值來臨時，有可能因為某一個應用對某個服務產生了不規範的服務調用或有問題的服務提供造成服務所在的企業服務總線實例出現異常，也有可能是一臺服務器的操作系統或硬件出現了故障，會導致10臺企業服務總線的實例中有一臺實例出現了問題無法正常提供服務路由的能力。
此時，服務路由壓力就落在了剩下的9臺ESB服務器上，原本由出問題的那臺服務器提供的服務路由職能就分攤到了剩下的9臺上，每臺的負載水位就超過88%，個別服務器可能更高，在服務器處於高水位運行的時候，出現問題的概率會大大增加。
糟糕的事情還是發生了，9臺中的一臺也因為不堪重負而“罷工”後，你會看到後面的8臺服務器在訪問峰值下就不是像之前一樣一臺一臺出問題，而是在瞬間被訪問洪流給沖垮，整個企業服務總線集群全軍覆沒。這就是典型的“雪崩”效應，因為一個小問題會給整個平臺帶來災難性的後果。
而且企業服務總線架構一旦遇到上面所提到的“雪崩”事故後，故障恢復的時間和成本都非常高昂。因為傳統的一臺一臺重啟服務器已經不能進行故障的恢復，因為一旦服務啟動起來，前端的訪問洪流會立即再次壓垮啟動後的服務器，唯一正確的方式則是首先切斷前端應用對企業服務總線請求，讓這10臺服務器全部啟動後，再開放服務請求，這樣才能恢復系統的運行。但因為著急恢復系統，沒有來得及定位之前造成開始服務實例出問題的根本原因，這樣的系統恢復運行其實處於一個“脆弱”的狀態。
綜上所述，正因為“雪崩”效應的隱患存在，在某種程度上其實嚴重束縛了“中心化”服務架構的平臺擴展能力，也就是說，通過增加“中心”點企業服務總線實例的節點數量，並不能線性擴展平臺的服務能力。
也正是因為ESB方案出現以上的問題，“去中心化”服務架構應運而生，其中最典型的就是阿里的HSF分佈式服務框架，它的實現原理是什麼，優勢又是什麼，我會在以後的博客中提到，敬請關注。
閱讀更多 七音說 的文章
