SOA架構是第一次被廣泛使用過、通過分布式服務來構建信息系統的工程實踐。它有完善的理論和工具，可以說，它解決了分布式系統中，幾乎所有主要的技術問題

所以本節就系統的討論一下SOA的設計思想與原則，找找他為什么沒有成功的原因？

三種服務拆分架構模式

1.煙囪式架構

? 前提：假設完全不會跟其他相關的信息系統之間進行協作

? 互不交互的系統，各自使用獨立的數據庫、服務器，即可以完成拆分。

? 問題就在于：不交互的系統（組織）真的存在嗎？

2.微內核架構

? 把一些公共的主數據：人員、組織 、權限等公用的服務、數據、資源，都集中到一塊兒，成為被所有業務系統共同依賴的核心系統。

? 這種模式很適合桌面應用程序的開發，如果想實現一個能夠支持二次開發的軟件系統，微內核架構也是一種良好的架構模式。

? 問題在于：各業務系統不直接交互，（比如：支付系統和用戶系統是獨立的，但彼此會有業務的調用），這時需要找到一個辦法，即能拆分出獨立的系統，也能讓拆分后的子系統之間可以順暢的互相調用

3.事件驅動架構

為了能讓子系統之間相互通訊，事件驅動架構就產生了

它是這樣的一張種模式：在子系統之間建立一套事件隊列管道，來自系統外部的消息將以事件的形式發送管道中，各子系統可以從管道中獲取自己感興趣、可以處理的事件消息，也可以為事件新增或修改其中的附加信息，甚至還可以自己發布一些新的事件到管道隊列中去。

同時SOAP協議的誕生，事件驅動架構+SOAP協議==催生出=>面向服務架構

SOA架構時代的探索

探索1：更具體

SOA本身還是屬于一種抽象概念，而不是特指某一種具體的技術，但它比單體架構和煙囪式架構、微內核架構、事件驅動架構，都要更具可操作性，細節也充實了很多。所以，我們已經不能簡單地把SOA看作是一種架構風格了，而是可以稱之為一套軟件架構的基礎平臺。

探索2：更系統

SOA最根本的目標，就是希望能夠總結出一套自上而下的軟件研發方法論，讓企業只需要跟著它的思路，就能夠一攬子解決掉軟件開發過程中的全套問題。比如，如何挖掘需求、如何將需求分解為業務能力、如何編排已有服務、如何開發測試部署新的功能，等等

過于嚴格的規范定義，給架構帶來了過度的復雜性，這也是Web Service衰落最本質的原因。

思考題：

你是否使用過SOA的方法論來開發軟件系統呢？無論有還是沒有，作為一個軟件開發者，你是否愿意軟件開發向著工業化方向發展，讓軟件類似工業產品制造那樣，可以在規范、理論、工具、技術的支持下，以流水線的方式生產出來？

思考：還真的是使用過某國產的ESB開發一個項目，但是受限于項目的規模只是做了課題性質的研究。雖然配套設施都很齊全，但是用起卻不并不那么的流暢，再加上當時思路受制于服務編排的困擾。好不容易把思路給理順了，同時又被微服務給沖擊了。如果軟件開發朝著工業化的方向發展，聽起來像是很美妙的事情，那樣的話，軟件的質量應該會有很大的提高。但是自己會不會被淘汰，軟件的定制化（靈活性）怎么體現，軟件開發的工作會不會朝著工具化的思路去發展，到處去寫補丁。還有一個問題，工業化產出的東西都是一樣的，就算再擴展一點可以滿足可以提供各種參數來配置。那這個基礎工具該有多復雜呀。

總結

以上是生活随笔為你收集整理的周志明架构课--03.SOA时代：成功理论与失败实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。