<微服務設計>1.3節：SOA是一種設計方法，其中包含多個服務，而服務之間通過配合最終會提供一系列功能。一個服務通常以獨立的形式存在于操作系統進程中。服務之間通過網絡調用，而非采用進程內調用的方式。?

通俗易懂的講SOA?

對SOA的粗暴理解：把系統按照實際業務進行拆分，拆分成大小合適、獨立部署的模塊、每個模塊之間相互獨立。

比如現在有一個數據庫，一個JavaWeb網站客戶端，一個IOS客戶端，一個安卓客戶端。

現在我要從這個數據庫中獲取用戶注冊列表，如果不用SAO設計理念，那么就會這樣：JavaWeb端網站里面寫一個查詢方法從數據庫中獲取數據然后現在在網頁上，IOS客戶端里面也寫一個查詢方法獲取數據顯示，IOS也是這樣。弊端就是，三個地方都有相同的業務代碼，如果要改的話，就要改三個地方，而且改的一模一樣，當然，問題可能不止這一個。

于是乎，出現了這樣的設計思想，比如用Java(或者其他語言皆可)單獨創建一個工廠部署在一臺單獨的服務器上，并且寫一個方法執行查詢用戶注冊列表這個操作。然后其他人通過某種途徑(可以是http鏈接或者是基于socket的RPC)訪問這個方法返回數據，返回的數據類型可以是xml，也可以是json。簡單來說，就是把這個操作封裝到一個工程當中去，然后暴露訪問的方式，形成"服務"。所有增刪改查都通過這個服務進行。

這樣一來，JavaWeb可以訪問這個服務，IOS和安卓客戶端也可以訪問這個服務。更重要的是如果要修改注冊業務的方法，只要改這個服務就可以了。同理，其他業務，比如訂單，廣告都可以單獨形成服務部署在單獨的服務器上。

還有就是哪怕有一天一堆人要注冊，假設這堆人僅僅是注冊不做其他事情，其他業務，比如訂單、廣告什么的都不忙，唯獨這個注冊服務壓力很大，而原有的一臺服務器已經承受不住這么高的并發，這個時候就可以單獨集群部署注冊服務，提供多臺服務器提供注冊服務，如果其他服務不忙，就維持原樣。

當然，好處肯定不止這些。

以上的描述還不能完全稱為SOA，還不夠完成，因為還缺少了服務治理這一環節。

什么是服務治理，就是當服務越來越多，調用方也越來越多，他們之間的關系就變得非常混亂，需要對這些關系進行管理。還是上面的例子，一個用戶服務，后來有上百個調用方，這個時候作為服務方，它只提供服務，卻不知道為誰提供了服務。對于開發者來說，知道這N多服務方之間的關系非常重要。所以這個時候就需要服務治理的框架，比如dubbo+zookeeper，比如Spring Cloud，有了服務治理功能，我們就可以清晰的看到服務被誰調用了，誰調用了哪些服務，哪些服務是熱點服務，需要配置服務器集群，而對這個服務器集群的負載均衡也是服務治理的可以完成的重要功能之一。

這個時候就是更加完善一點的SOA了，當然，還可以更進一步，加上服務監控跟蹤等等。

?

?

?

總結

以上是生活随笔為你收集整理的通俗易懂的讲SOA的全部內容，希望文章能夠幫你解決所遇到的問題。

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