SOA,SOAP,RPC,以及 RPC協議與 REST 協議之間的關係(搜狗)

1. 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的成熟性能夠給須要提供給多開發語言的，對於安全性要求較高的接口設計帶來便利。因此我以爲純粹說什麼設計模式將會佔據主導地位沒有什麼意義，關鍵仍是看應用場景，正是那句老話：適合的纔是最好的 

一、SOA

SOA（面向服務的軟件架構、Service Oriented Architecture），是一種軟件設計模式，主要應用於不一樣應用組件之間經過某種協議來互操做。例如典型的  通訊網絡協議。所以SOA是獨立於任何廠商、產品、技術的。 

SOA有兩個層面的定義： 

• 從應用的角度定義：SOA是一種應用框架，它着眼於平常的業務應用，並將他們劃分爲單獨的業務功能和流程，及所謂的服務。
• 從軟件的基本原理定義：SOA是一個組件模型，它將應用程序的不一樣功能單元(服務)經過這些服務之間定義良好的接口和契約聯繫起來。 

SOA對於實現企業資源共享，打破 「信息孤島」 的步驟以下：

1. 把引用和資源轉換爲對象；
2. 把這些服務編程標準的服務，造成資源的共享； 

基於SOA的解決方案，SOA架構可分爲五層水平：

• 用戶界面層 ---- 這些GUI的最終用戶或應用程序訪問的應用程序/服務接口；
• 業務流程層 ---- 在應用方面的業務用例服務；
  
• 服務層 ---- 服務合併在一塊兒，提供統一的實時服務；
• 服務組件層 ---- 用來建造服務的組件，如功能庫、技術庫、技術接口等；
• 操做系統 ---- 這層包含數據模型，企業數據倉庫，技術平臺等；

由於SOA不依賴於任何技術，所以SOAP、RPC、REST是對SOA的不一樣實現。

二、SOAP 

簡單對象訪問協議是交換數據的一種協議規範，

1. 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請求。發出請求的用戶端通常都是須要向遠端系統要求呼叫的軟件。 

三、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，你須要設計一些程序嵌入到某種結構中。這種結構須要存儲參數、錯誤的代碼、返回值等。

四、RPC 

RPC（Remote Procedure Call Protocol）——遠程過程調用協議，它是一種經過網絡從遠程計算機程序上請求服務，而不須要了解底層網絡技術的協議。RPC協議假定某些傳輸協議的存在，如TCP或UDP，爲通訊程序之間攜帶信息數據。在OSI網絡通訊模型中，RPC跨越了傳輸層和應用層。RPC使得開發包括網絡分佈式多程序在內的應用程序更加容易。
RPC採用客戶機/服務器模式。請求程序就是一個客戶機，而服務提供程序就是一個服務器。首先，客戶機調用進程發送一個有進程參數的調用信息到服務進程，而後等待應答信息。在服務器端，進程保持睡眠狀態直到調用信息到達爲止。當一個調用信息到達，服務器得到進程參數，計算結果，發送答覆信息，而後等待下一個調用信息，最後，客戶端調用進程接收答覆信息，得到進程結果，而後調用執行繼續進行。

RPC工做原理：

運行時,一次客戶機對服務器的RPC調用,其內部操做大體有以下十步：

1.調用客戶端句柄；執行傳送參數

2.調用本地系統 內核發送網絡消息

3. 消息傳送到遠程 主機

4.服務器句柄獲得消息並取得參數

5.執行遠程過程

6.執行的過程將結果返回服務器句柄

7.服務器句柄返回結果，調用遠程系統 內核

8.消息傳回 本地主機

9.客戶句柄由內核接收消息

10.客戶接收句柄返回的數據

注意：

dubbo就是一種RPC框架。他的通信協議是RPC協議，

它是由alibaba得工程師爲java開發的一個RPC，有很高的性能以及簡單的使用方法：

一、被遠程調用的接口，須要在zookeeper中進行註冊；

二、須要遠程調用的服務在zookeeper中聲明本身須要的接口；

三、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
……	……	……

 

五、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網關中配置映射關係和權限控制就可實現服務的複用了。 

六、REST 和SOAP協議的區別：

REST基於HTTP協議，

SOAP基於任何傳輸協議:諸如 TCP、HTTP、SMTP，甚至是 MSMQ等

國外不少大網站都發布了本身的開發API，不少都提供了SOAP和REST兩種Web Service，根據調查部分網站的REST風格的使用狀況要高於SOAP。可是因爲REST只是一種基於Http協議實現資源操做的思想，所以各個網站的REST實現都自有一套，在後面會講訴各個大網站的REST API的風格。也正是由於這種各自實現的狀況，在性能和可用性上會大大高於SOAP發佈的web service，但統一通用方面遠遠不及SOAP。因爲這些大網站的SP每每專一於此網站的API開發，所以通用性要求不高。 

 

SOAP協議對於消息體和消息頭都有定義，同時消息頭的可擴展性爲各類互聯網的標準提供了擴展的基礎，WS-*系列就是較爲成功的規範。可是也因爲SOAP因爲各類需求不斷擴充其自己協議的內容，致使在SOAP處理方面的性能有所降低。同時在易用性方面以及學習成本上也有所增長。 
       REST被人們的重視，其實很大一方面也是由於其高效以及簡潔易用的特性。這種高效一方面源於其面向資源接口設計以及操做抽象簡化了開發者的不良設計，同時也最大限度的利用了Http最初的應用協議設計理念。同時，在我看來REST還有一個很吸引開發者的就是可以很好的融合當前Web2.0的不少前端技術來提升開發效率。例如不少大型網站開放的REST風格的API都會有多種返回形式，除了傳統的xml做爲數據承載，還有（JSON,RSS,ATOM）等形式，這對不少網站前端開發人員來講就可以很好的mashup各類資源信息。 
       所以在效率和易用性上來講，REST更勝一籌。 

　　REST對於資源型服務接口來講很合適，同時特別適合對於效率要求很高，可是對於安全要求不高的場景。而SOAP的成熟性能夠給須要提供給多開發語言的，對於安全性要求較高的接口設計帶來便利。因此我以爲純粹說什麼設計模式將會佔據主導地位沒有什麼意義，關鍵仍是看應用場景。  

七、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的區別與聯繫

參考：RPC協議學習（三）與其餘區別

參考：談談本身對REST、SOA、SOAP、RPC、ICE、ESB、BPM知識彙總及理解

參考：你想要的都在這之RPC/web service/REST/SOA區別聯繫與對比

參考：Webservice RPC風格 SOAP,REST風格 各之間的對比