對于SOA，感覺這個概念性的東西沒那么容易理解，看了各位大神的解釋感覺很多都說的很抽象，所以想嘗試用自己的語言解釋下，僅做參考。

 

SOA粗暴理解：把系統(tǒng)按照實際業(yè)務，拆分成剛剛好大小的、合適的、獨立部署的模塊，每個模塊之間相互獨立。

 

比如現(xiàn)我有一個數(shù)據(jù)庫，一個JavaWeb（或者PHP等）的網(wǎng)站客戶端，一個安卓app客戶端，一個IOS客戶端。

 

現(xiàn)在我要從這個數(shù)據(jù)庫中獲取注冊用戶列表，如果不用SOA的設計思想，那么就會這樣：JavaWeb里面寫一個查詢方法從數(shù)據(jù)庫里面查數(shù)據(jù)然后在網(wǎng)頁顯示，安卓app里面寫一個查詢方法查詢后在app上顯示，IOS同樣如此。這里就會出現(xiàn)查詢方法重疊了，這樣的壞處很明顯了，三個地方都有相同的業(yè)務代碼，要改三個地方都要改，而且要改的一模一樣。當然問題不止這一個。

 

于是乎出現(xiàn)了這樣的設計思想，比如用Java（或者是其他語言皆可）單獨創(chuàng)建一個工程部署在一臺服務器上，并且寫一個方法（或稱函數(shù)）執(zhí)行上述查詢操作，然后使其他人可以通過某種途徑（可以是http鏈接，或者是基于socket的RPC調(diào)用）訪問這個方法得到返回數(shù)據(jù)，返回的數(shù)據(jù)類型是通用的json或者xml數(shù)據(jù)，就是說把這個操作封裝到一個工程中去，然后暴露訪問的方式，形成“服務”。比如這里就是注冊用戶服務，而關于注冊用戶的所有相關增刪改查操作這個服務都會提供方法。

 

這樣一來，JavaWeb這邊可以訪問這個服務然后得到數(shù)據(jù)使用，安卓和IOS這里也可以通過這個服務得到數(shù)據(jù)。而且最重要的是，要修改關于注冊用戶的業(yè)務方法只要改這個服務就好了，很好的解耦。同理，其他業(yè)務比如商品、廣告等業(yè)務都可以單獨形成服務部署在單獨服務器上。

 

還有就是一旦哪天突然有一堆人要注冊，假設這堆人僅僅只是注冊而不做其他事情，其他業(yè)務比如商品、廣告服務等都不忙，唯獨注冊這個功能壓力很大，而原有的一臺部署了注冊服務的服務器已經(jīng)承受不了這么高的并發(fā)，這時候就可以單獨集群部署這個注冊服務，提供多幾臺服務器提供注冊服務，而其他服務還不忙，那就維持原樣。

 

當然，還有很多其他好處。

 

以上我所描述的都還不能完全稱為SOA，還不夠完整，因為它少了服務治理這一環(huán)節(jié)。

 

什么是服務治理，就是當服務越來越多，調(diào)用方也越來越多的時候，它們之間的關系就變得非?；靵y，需要對這些關系進行管理。舉例，還是上面的例子，假如我有一個用戶服務，一開始有調(diào)用方1和調(diào)用方2來使用這個服務，后來越來越多，將近上百個調(diào)用方，這個時候作為服務方，它只知道提供服務，卻不知道具體為誰提供了服務。而對于開發(fā)者來說，知道這N多調(diào)用方和N多服務方之間的關系是非常重要的。

 

所以這個時候就需要能進行服務治理的框架，比如dubbo+zookeeper，比如SpringCloud，有了服務治理功能，我們就能清晰地看到服務被誰誰誰調(diào)用，誰誰誰調(diào)用了哪些服務，哪些服務是熱點服務需要配置服務器集群，而對這個服務集群的負載均衡也是服務治理可以完成的重要功能之一。

 

這個時候就是更加完善一點的SOA了。

 

當然，還可以更進一步，加上服務監(jiān)控跟蹤等等等等之類的。

實際上SOA只是一種架構(gòu)設計模式，而SOAP、REST、RPC就是根據(jù)這種設計模式構(gòu)建出來的規(guī)范，其中SOAP通俗理解就是http+xml的形式，REST就是http+json的形式，RPC是基于socket的形式。上文提到的CXF就是典型的SOAP/REST框架，dubbo就是典型的RPC框架，而SpringCloud就是遵守REST規(guī)范的生態(tài)系統(tǒng)。

以上就是“什么是SOA架構(gòu)？”的詳細內(nèi)容，更多請關注木子天禾科技其它相關文章！