這個圖見過好多次,但是依舊還是不是太懂 如果看介紹的話還可以大體明白
看到這里,我明白了,哦,原來dubbo是可以和spring無縫集成的
那么SOA和RPC又是什么呢?
let's REPEAT it.
SOA是從架構方面,整體支持面向服務泛型的基本概念性架構模型
哦,那我明白,面向對象是怎么回事,而面向服務泛型,大概就是說去吃飯時,面對打菜的服務大媽,好幾個大媽,她們可以統稱為<"打菜服務生.class">這樣的泛型?
SOA是一種業務-IT結合的方法,其中,應用依賴於現有的服務來實現業務過程.
我們可以看上圖,服務消費者(consumer), 服務提供者(provider) 這又是什么關系呢?
是吃飯的人比如小明和打菜的食堂大媽的關系,吃飯的人是服務消費者,而食堂大媽則是服務提供者.
消費者有什么呢?大家都知道在服務提供者和服務消費者之間隔着一個放托盤的地方.
我們且稱之為(小明)前台和后台(大媽)吧.
那么小明這個站在打菜吧台外圍的人說,我要吃烤魚,花甲粉,和大米飯.這就是說小明這個消費者提了一些需求給后台(大媽)
也就是說消費者層,業務過程層,傳遞給服務層(吧台).
大媽知道了,大媽給小明往碟子中打上這些菜飯,大媽這工作時提供了服務,即包含了操作型系統層(大勺),服務組件層(幾個菜),服務層(吧台)
讓我們回顧 知乎是怎么說的:
作者：光太狼 鏈接：https://www.zhihu.com/question/42061683/answer/251131634 來源：知乎 著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。 對於SOA，感覺這個概念性的東西沒那么容易理解，看了各位大神的解釋感覺很多都說的很抽象，所以想嘗試用自己的語言解釋下，僅做參考。
SOA粗暴理解：把系統按照實際業務，拆分成剛剛好大小的、合適的、獨立部署的模塊，每個模塊之間相互獨立。比如現我有一個數據庫，一個JavaWeb（或者PHP等）的網站客戶端，一個安卓app客戶端，
一個IOS客戶端。現在我要從這個數據庫中獲取注冊用戶列表，如果不用SOA的設計思想，那么就會這樣：JavaWeb里面寫一個查詢方法從數據庫里面查數據然后在網頁顯示，安卓app里面寫一個查詢方法查
詢后在app上顯示，IOS同樣如此。這里就會出現查詢方法重疊了，這樣的壞處很明顯了，三個地方都有相同的業務代碼，要改三個地方都要改，而且要改的一模一樣。當然問題不止這一個。於是乎出現了這
樣的設計思想，比如用Java（或者是其他語言皆可）單獨創建一個工程部署在一台服務器上，並且寫一個方法（或稱函數）執行上述查詢操作，然后使其他人可以通過某種途徑（可以是http鏈接，或者是基
於socket的RPC調用）訪問這個方法得到返回數據，返回的數據類型是通用的json或者xml數據，就是說把這個操作封裝到一個工程中去，然后暴露訪問的方式，形成“服務”。比如這里就是注冊用戶服務，
而關於注冊用戶的所有相關增刪改查操作這個服務都會提供方法。這樣一來，JavaWeb這邊可以訪問這個服務然后得到數據使用，安卓和IOS這里也可以通過這個服務得到數據。而且最重要的是，要修改關於
注冊用戶的業務方法只要改這個服務就好了，很好的解耦。同理，其他業務比如商品、廣告等業務都可以單獨形成服務部署在單獨服務器上。還有就是一旦哪天突然有一堆人要注冊，假設這堆人僅僅只是注冊
而不做其他事情，其他業務比如商品、廣告服務等都不忙，唯獨注冊這個功能壓力很大，而原有的一台部署了注冊服務的服務器已經承受不了這么高的並發，這時候就可以單獨集群部署這個注冊服務，提供多
幾台服務器提供注冊服務，而其他服務還不忙，那就維持原樣。當然，還有很多其他好處。以上我所描述的都還不能完全稱為SOA，還不夠完整，因為它少了服務治理這一環節。什么是服務治理，就是當服務
越來越多，調用方也越來越多的時候，它們之間的關系就變得非常混亂，需要對這些關系進行管理。舉例，還是上面的例子，假如我有一個用戶服務，一開始有調用方1和調用方2來使用這個服務，后來越來越
多，將近上百個調用方，這個時候作為服務方，它只知道提供服務，卻不知道具體為誰提供了服務。而對於開發者來說，知道這N多調用方和N多服務方之間的關系是非常重要的。所以這個時候就需要能進行服
務治理的框架，比如dubbo+zookeeper，比如SpringCloud，有了服務治理功能，我們就能清晰地看到服務被誰誰誰調用，誰誰誰調用了哪些服務，哪些服務是熱點服務需要配置服務器集群，而對這個服務
集群的負載均衡也是服務治理可以完成的重要功能之一。這個時候就是更加完善一點的SOA了。當然，還可以更進一步，加上服務監控跟蹤等等等等之類的。實際上SOA只是一種架構設計模式，而SOAP、REST、
RPC就是根據這種設計模式構建出來的規范，其中SOAP通俗理解就是http+xml的形式，REST就是http+json的形式，RPC是基於socket的形式。上文提到的CXF就是典型的SOAP/REST框架，dubbo就是典
型的RPC框架，而SpringCloud就是遵守REST規范的生態系統。
以上就是我的個人理解，有錯漏請指正、編輯於 2019-10-14
那么讓我這個選擇困難症比較犯難的地方就是,到底是使用SOAP還是REST還是RPC的形式呢?這點其實各有各的選擇,也有的時候得聽技術領導經理的,並不能做決定.
可以看到SOA的好處也不少
SOA的好處
從IT角度觸發:
松耦合,消除假依賴 -- 復用
- 語言,平台和廠商中立
- 消除時間依賴
- 消除訪問地址依賴
- 消除訪問協議依賴
服務間接尋址 -- 靈活
從業務角度出發:
保護企業投資,提升現有IT資源的作用,促進IT資源的復用
提高企業靈敏度
支持企業外包管理模式
SOA在不同粒度上提供了本質性的指導: 業務層,過程層,中間件層和編程層.
在每個層次中
SOA按照"自頂向下"的方式,將一個較大的單元分解為較小的,以服務為中心的單元/
SOA按照"自底向上"的方式,將可供使用的較小單元組織成為較大的單元,用以提供全新的服務.