- web service顧名思義這是一種提供service的形式，而且只能通過http（web）來提供service(web service三要素：SOAP、WSDL(WebServicesDescriptionLanguage)、UDDI(UniversalDescriptionDiscovery andIntegration))
SOA也就是面向服務的架構，那么這個架構如何提供服務，他不是web service,但Web Service是目前最適合實現SOA的技術,Web Service.目前有三種主流的Web服務實現方式：
REST：Representational State transfer 表征狀態轉變 (基於HTTP協議）面向資源的；
SOAP：簡單對象訪問協議(基於任何傳輸協議，TCP,HTTP,SMTP,MSMQ)
XML-RPC：遠程過程調用協議 （已經慢慢被SOAP取代）RPC(跨越了傳輸層和應用層，基於HTTP和TCP)
效率和易用性上：REST更勝一籌（REST效率更高的原因在於，僅僅是建議的Http協議之上的一種協議。而SOAP則需要對數據、xml封裝信息頭，解封裝等）
安全性上：SOAP安全性高於REST，因為REST更關注的是效率和性能問題
分布式能力：REST更適合在分布式環境中使用、因為REST是基於原生Http協議的，而http協議是無狀態的。大型分布式環境都能夠對無狀態支持良好，無狀態增強了整個系統的擴展性。這也是為什么越來越多的雲計算，分布式項目選擇REST。
總體上，因為REST模式的Web服務與復雜的SOAP和XML-RPC對比來講明顯的更加簡潔，越來越多的web服務開始采用REST風格設計和實現。例如，Amazon.com提供接近REST風格的Web服務進行圖書查找；雅虎提供的Web服務也是REST風格的。REST對於資源型服務接口來說很合適，同時特別適合對於效率要求很高，但是對於安全要求不高的場景。而SOAP的成熟性可以給需要提供給多開發語言的，對於安全性要求較高的接口設計帶來便利。所以我覺得純粹說什么設計模式將會占據主導地位沒有什么意義，關鍵還是看應用場景，正是那句老話：適合的才是最好的
1、SOA
SOA（面向服務的軟件架構、Service Oriented Architecture），是一種軟件設計模式，主要應用於不同應用組件之間通過某種協議來互操作。例如典型的 通信網絡協議。因此SOA是獨立於任何廠商、產品、技術的。
SOA有兩個層面的定義：
- 從應用的角度定義：SOA是一種應用框架，它着眼於日常的業務應用，並將他們划分為單獨的業務功能和流程，及所謂的服務。
- 從軟件的基本原理定義：SOA是一個組件模型，它將應用程序的不同功能單元(服務)通過這些服務之間定義良好的接口和契約聯系起來。
- 把引用和資源轉換為對象；
- 把這些服務編程標准的服務，形成資源的共享；
- 用戶界面層 ---- 這些GUI的最終用戶或應用程序訪問的應用程序/服務接口；
- 業務流程層 ---- 在應用方面的業務用例服務；
- 服務層 ---- 服務合並在一起，提供統一的實時服務；
- 服務組件層 ---- 用來建造服務的組件，如功能庫、技術庫、技術接口等；
- 操作系統 ---- 這層包含數據模型，企業數據倉庫，技術平台等；
2、SOAP
簡單對象訪問協議是交換數據的一種協議規范，
- SOAP,簡單對象訪問協議，是一種輕量的、簡單的、基於XML（標准通用標記語言下的一個子集）的協議，它被設計成在WEB上交換結構化的和固化的信息。可在任何傳輸協議（諸如 TCP、HTTP、SMTP，甚至是 MSMQ）上使用
擴展：SOAP廣泛使用的是基於HTTP和xml協議的實現（SOAP=RPC+HTTP+XML），也就是大家常提的Web Service使用的通信協議。一個SOAP方法可以簡單地看作遵循SOAP編碼規則的HTTP請求和響應。
比較：XML－RPC是啟動web服務最容易的方法，在很多方面比SOAP更簡單易用，但不同於SOAP的是，XML－RPC沒有相應的服務描述語法，這妨礙了XML－RPC服務的自動調用。
是一種標准化的通訊規范，主要用於Web服務（web service）中。用一個簡單的例子來說明 SOAP 使用過程，一個 SOAP 消息可以發送到一個具有 Web Service 功能的 Web 站點，例如，一個含有房價信息的數據庫，消息的參數中標明這是一個查詢消息，此站點將返回一個 XML 格式的信息，其中包含了查詢結果（價格，位置，特點，或者其他信息）。由於數據是用一種標准化的可分析的結構來傳遞的，所以可以直接被第三方站點所利用。
XML-RPC：一個遠程過程調用（remote procedure call，RPC)的分布式計算協議，通過XML將調用函數封裝，並使用HTTP協議作為傳送機制。
在某種傳輸協議（TCP\HTTP等)上攜帶信息數據，通過網絡從遠程計算機程序上請求服務
后來在新的功能不斷被引入下，這個標准慢慢演變成為今日的SOAP協定。XML-RPC協定是已登記的專利項目。XML-RPC透過向裝置了這個協定的服務器發出HTTP請求。發出請求的用戶端一般都是需要向遠端系統要求呼叫的軟件。
3、REST
表征狀態轉移（Representional State Transfer）。采用Web 服務使用標准的 HTTP 方法 (GET/PUT/POST/DELETE) 將所有 Web 系統的服務抽象為資源，REST 不是一種協議,它是一種架構, 一種 Web Service 能夠如果滿足 REST 的幾個條件, 通常就稱這個系統是 Restful 的.，REST從資源的角度來觀察整個網絡，分布在各處的資源由URI確定，而客戶端的應用通過URI來獲取資源的表征。Http協議所抽象的get,post,put,delete就好比數據庫中最基本的增刪改查，而互聯網上的各種資源就好比數據庫中的記錄（可能這么比喻不是很好），對於各種資源的操作最后總是能抽象成為這四種基本操作，在定義了定位資源的規則以后，對於資源的操作通過標准的Http協議就可以實現，開發者也會受益於這種輕量級的協議。REST是一種軟件架構風格而非協議也非規范，是一種針對網絡應用的開發方式，可以降低開發的復雜性，提高系統的可伸縮性。
這里提到的條件包括:
C/S結構 (這是Internet服務的一個基本特征)
無狀態 (很熟悉吧,呵呵)
可以cache (想起了瀏覽器?)
分層系統 (想起了無數的架構?)
統一的接口 (如果這是可能的,程序員有福了, :D)
code on demand(可選, 其實是一種擴展性的要求)
HTTP是WWW的最核心的協議, 它將簡單的分布於世界各個角落的資源都統一起來, 統一的地址, 簡單的方法, 和一定數量的表達方式.(你可能對這三點描述很模糊,請go ahead).
REST 的三個要素是 唯一的資源標識, 簡單的方法 (此處的方法是個抽象的概念), 一定的表達方式.
REST 是以 資源 為中心, 名詞即資源的地址, 動詞即施加於名詞上的一些有限操作, 表達是對各種資源形態的抽象.
以HTTP為例, 名詞即為URI(統一資源標識), 動詞包括POST, GET, PUT, DELETE等(還有其它不常用的2個,所以 整個動詞集合是有限的), 資源的形態(如text, html, image, pdf等)
其宗旨是從資源的角度來觀察整個網絡，分布在各處的資源由URI確定，而客戶端的應用通過URI來獲取資源的表征。獲得這些表征致使這些應用程序轉變了其狀態。隨着不斷獲取資源的表征，客戶端應用不斷地在轉變着其狀態。
舉個栗子：
Marcus是一個農民，他有4頭豬，12只雞和3頭奶牛。他現在模擬一個REST API，而我是客戶端。如果我想用REST來請求當前的農場狀態，我僅會問：“State？”Marcus會回答：“4頭豬、12只雞、3頭奶牛”。
這是REST最簡單的一個例子。Marcus使用表征來傳輸農場狀態。表征的句子很簡單：“4頭豬、12只雞、3頭奶牛”。
再往下看，看我如何讓Marcus用REST方式添加2頭奶牛？
按照常理，可以會這樣說：Marcus，請在農場你再添加2頭奶牛。難道這就是REST方式嗎？難道就是通過這樣的表征來傳輸狀態的嗎？不是的！這是一個遠程過程調用，過程是給農場添加2頭奶牛。
Marcus很憤怒地響應到：“400，Bad Request”，你到底是什么意思？
所以，讓我們重新來一次。我們怎樣做到REST方式呢？該怎樣重新表征呢？它應該是4頭豬、12只雞、3頭奶牛。好，讓我們再次重新表征……
我：“Marcus，……4頭豬、12只雞、5頭奶牛！”
Marcus：“好的”。
我：“Marcus，現在是什么狀態？”
Marcus：“4頭豬、12只雞、5頭奶牛”。
我：“好！”
看到了嗎？就這樣簡單。
為什么RPC也不夠好？
從邏輯角度來看，為什么會更加青睞REST而不是RPC（Remote Procedure Call，遠程過程調用 ），因為它極大的降低了我們溝通的復雜度，通過把表征作為唯一的溝通的方式。無需去討論過程（添加一頭牛？增加一種動物類型？給雞的數量翻倍還是賣掉所有豬？）我們只需討論表征，並且使用這個表征來達到我們想要的目標，很簡單，不是嗎？我不希望和Marcus的溝通失敗，因為我們彼此的理解過程會不一樣，所以只需要知道最后的狀態就行。但這僅僅是創建RPC會產生許多問題之一。如果你使用RPC，你需要設計一些程序嵌入到某種結構中。這種結構需要存儲參數、錯誤的代碼、返回值等。
4、RPC
RPC（Remote Procedure Call Protocol）——遠程過程調用協議，它是一種通過網絡從遠程計算機程序上請求服務，而不需要了解底層網絡技術的協議。RPC協議假定某些傳輸協議的存在，如TCP或UDP，為通信程序之間攜帶信息數據。在OSI網絡通信模型中，RPC跨越了傳輸層和應用層。RPC使得開發包括網絡分布式多程序在內的應用程序更加容易。
RPC采用客戶機/服務器模式。請求程序就是一個客戶機，而服務提供程序就是一個服務器。首先，客戶機調用進程發送一個有進程參數的調用信息到服務進程，然后等待應答信息。在服務器端，進程保持睡眠狀態直到調用信息到達為止。當一個調用信息到達，服務器獲得進程參數，計算結果，發送答復信息，然后等待下一個調用信息，最后，客戶端調用進程接收答復信息，獲得進程結果，然后調用執行繼續進行。
RPC工作原理：
注意：
dubbo就是一種RPC框架。他的通訊協議是RPC協議，
它是由alibaba得工程師為java開發的一個RPC，有很高的性能以及簡單的使用方法：
1、被遠程調用的接口，需要在zookeeper中進行注冊；
2、需要遠程調用的服務在zookeeper中聲明自己需要的接口；
3、zookeeper將已經注冊的接口通知給需要的服務；
Spring Cloud也是一種RPC框架，他的通訊協議是http restful 協議；REST協議，它基於HTTP的協議，是一種明確構建在客戶端/服務端體系結構上的一種風格
HTTP Restful本身輕量，易用，適用性強，可以很容易的跨語言，跨平台，或者與已有系統交互，畢竟HTTP現在沒有不支持的。
Spring可以整合其他的RPC方案，比如各種MQ，Hessian，Thrift，都可以。
看看Spring Cloud和Dubbo都提供了哪些支持。
| Dubbo | Spring Cloud | |
|---|---|---|
| 服務注冊中心 | Zookeeper | Spring Cloud Netflix Eureka |
| 服務調用方式 | RPC | REST API |
| 服務網關 | 無 | Spring Cloud Netflix Zuul |
| 斷路器 | 不完善 | Spring Cloud Netflix Hystrix |
| 分布式配置 | 無 | Spring Cloud Config |
| 服務跟蹤 | 無 | Spring Cloud Sleuth |
| 消息總線 | 無 | Spring Cloud Bus |
| 數據流 | 無 | Spring Cloud Stream |
| 批量任務 | 無 | Spring Cloud Task |
| …… | …… | …… |
5、RPC 與 REST 的區別
Rest基於http作為應用協議，不同語言之間調用比較方便。典型代表就是spring cloud框架
而RPC是基於TCP和HTTP協議的，是把http作為一種傳輸協議，本身還會封裝一層RPC框架的應用層協議，不同語言之間調用需要依賴RPC協議，典型代表就是Dubbo;
RPC是以動詞為中心的, REST是以名詞為中心的, 此處的 動詞指的是一些方法, 名詞是指資源.
你會發現,以動詞為中心,意味着,當你要需要加入新功能時,你必須要添加更多的動詞, 這時候服務器端需要實現 相應的動詞(方法), 客戶端需要知道這個新的動詞並進行調用.
而以名詞為中心, 假使我請求的是 hostname/friends/, 無論這個URI對應的服務怎么變化,客戶端是無需 關注和更新的,而這種變化對客戶端也是透明的.
至於其它的區別,如對實現語言的依賴, 耦合性等,這些都是上面提到的這個根本區別所衍生的.
當你每天使用HTTP沖浪時,你都在使用 REST 與遠程的服務器進行親密接觸. 當你使用Gtalk和同事朋友溝通時,你則是在享受着 RPC 的便利.
另外，由於Dubbo是基礎框架，其實現的內容對於我們實施微服務架構是否合理，也需要我們根據自身需求去考慮是否要修改，比如Dubbo的服務調用是通過RPC實現的，但是如果仔細拜讀過Martin Fowler的microservices一文，其定義的服務間通信是HTTP協議的REST API。那么這兩種有何區別呢？
先來說說，使用Dubbo的RPC來實現服務間調用的一些痛點：
服務提供方與調用方接口依賴方式太強：我們為每個微服務定義了各自的service抽象接口，並通過持續集成發布到私有倉庫中，調用方應用對微服務提供的抽象接口存在強依賴關系，因此不論開發、測試、集成環境都需要嚴格的管理版本依賴，才不會出現服務方與調用方的不一致導致應用無法編譯成功等一系列問題，以及這也會直接影響本地開發的環境要求，往往一個依賴很多服務的上層應用，每天都要更新很多代碼並install之后才能進行后續的開發。若沒有嚴格的版本管理制度或開發一些自動化工具，這樣的依賴關系會成為開發團隊的一大噩夢。而REST接口相比RPC更為輕量化，服務提供方和調用方的依賴只是依靠一紙契約，不存在代碼級別的強依賴，當然REST接口也有痛點，因為接口定義過輕，很容易導致定義文檔與實際實現不一致導致服務集成時的問題，但是該問題很好解決，只需要通過每個服務整合swagger，讓每個服務的代碼與文檔一體化，就能解決。所以在分布式環境下，REST方式的服務依賴要比RPC方式的依賴更為靈活。
服務對平台敏感，難以簡單復用：通常我們在提供對外服務時，都會以REST的方式提供出去，這樣可以實現跨平台的特點，任何一個語言的調用方都可以根據接口定義來實現。那么在Dubbo中我們要提供REST接口時，不得不實現一層代理，用來將RPC接口轉換成REST接口進行對外發布。若我們每個服務本身就以REST接口方式存在，當要對外提供服務時，主要在API網關中配置映射關系和權限控制就可實現服務的復用了。
6、REST 和SOAP協議的區別：
REST被人們的重視，其實很大一方面也是因為其高效以及簡潔易用的特性。這種高效一方面源於其面向資源接口設計以及操作抽象簡化了開發者的不良設計，同時也最大限度的利用了Http最初的應用協議設計理念。同時，在我看來REST還有一個很吸引開發者的就是能夠很好的融合當前Web2.0的很多前端技術來提高開發效率。例如很多大型網站開放的REST風格的API都會有多種返回形式，除了傳統的xml作為數據承載，還有（JSON,RSS,ATOM）等形式，這對很多網站前端開發人員來說就能夠很好的mashup各種資源信息。
因此在效率和易用性上來說，REST更勝一籌。
7、RPC與SOA的區別
總的來講：RPC是一種進程遠程調用的方式，更強調的是異構平台之間進程通信的機制。SOA是一種產品架構的理念，以服務為中心，松耦合，通過定義嚴謹明確的接口進行通信。有比較完善的服務管理機制。兩者並不是一個層面上的概念，可以說RPC是SOA架構的一種實現。
場景及選擇：
比如公司要做一個社交游戲的項目, 讓你去負責整個系統的后端架構和通信等, 我們就有必要去仔細地學習和研究下facebook/人人網/新浪等社交網站（游戲）開放的API, 我們知道facebook使用的是REST 的架構, 所以即使facebook本身是PHP開發的,這也不妨礙我們使用python來開發, 還有更多的PHP, Java, .net, Perl等客戶端API封裝.這樣就能靈活的適配多端的服務了。
於是在想,倘若facebook的架構使用的不是 REST ,會有這樣的靈活性嗎? 如果使用的是 RPC 可能不會有這么便利。
另外,因為我們的前端使用的是flash, 與后端的python通信采用的是 Django+Flex+AMF , 如果你了解 flash,你會知道AMF是一種二進制的flash數據交互協議, 而 它是基於RPC !
所以，我們需要根據當前需求的情況來選擇REST或則RPC
參考：SOA、SOAP、RPC、REST、DUBBO的區別與聯系
參考：談談自己對REST、SOA、SOAP、RPC、ICE、ESB、BPM知識匯總及理解