透析SOA、RPC、SOAP、REST、ICE、ESB模型發展史

最初的程序全是單機程序，沒有網絡，沒有RPC，更沒有RESTful。程序猿寫的東西孤獨運行在單機上。

那時的程序猿們語言相通，參與開發同一套系統的團隊能夠面對面溝通。

網絡出現了。網絡，也帶來變亂。網絡是不一樣系統之間的通訊，不管是早期網絡，仍是web，如何實行系統間的互聯互通是個頭痛的問題。

而SOA就是一種思想，就是把項目拆成組件，每一個組件暴露出服務，「你調我，我調你」，你們一塊兒把活幹完。強調的是服務的相互調用。

SOA

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

SOA做爲一種架構依賴於服務的方向，它的基本設計原理是：服務提供了一個簡單的接口，抽象了底層的複雜性，而後用戶能夠訪問獨立的服務，而不須要去了解服務底層平臺實現。

基於SOA的解決方案，努力使經營目標而創建企業的質量體系。SOA架構是五層水平：

    1. 用戶界面層–這些GUI的最終用戶或應用程序訪問的應用程序/服務接口。

    2. 業務流程層–這些精心設計的表明在應用方面的業務用例服務。

    3. 服務層–服務合併在一塊兒，爲整個企業提供實時服務。

    4. 服務組件層–用來建造服務的組件，如功能庫和技術庫，技術接口等。

    5. 操做系統–這層包含數據模型，企業數據倉庫，技術平臺等。

正由於SOA架構實現不依賴於技術，所以可以被各類不一樣的技術實現。

例如：

SOAP, RPC，REST，DCOM，CORBA，OPC-UA，Web services，DDS，Java RMI，WCF (Microsoft's implementation of web services now forms a part of WCF)，Apache Thrift，SORCER

web service是SOA很經常使用的一種實行方式。

Web Service

Web Service 也提出了很久了, 那麼究竟什麼是 Web Service ?

簡單地說, 也就是服務器如何向客戶端提供服務.

webService的經常使用的方法有:

1. RPC   （遠程過程調用協議 ）所謂的遠程過程調用 (面向方法)

2. SOAP   （簡單對象訪問協議） 所謂的面向服務的架構(面向消息)

3. REST （表象化狀態轉變）     所謂的 Representational state transfer (面向資源)

下面分別做簡單介紹：

RPC：即遠程過程調用(Remote rocedure call), 很簡單的概念, 像調用本地服務(方法)同樣調用服務器的服務(方法)。透過向裝置了這個協定的服務器發出HTTP請求。發出請求的用戶端通常都是須要向遠端系統要求呼叫的軟件。

一般的實現有 XML-RPC , JSON-RPC , 通訊方式基本相同, 所不一樣的只是傳輸數據的格式.

(若是你已經習慣於XML繁重的尖括號,你不妨能夠嘗試下更加輕型,高效,傳輸效率高的 JSON.)

一個簡單的通訊過程一般爲:

Request

  member.get_username_by_id              1

Response

              Zhu Tao

向服務器發送一個過程調用的方法及其參數, 獲得服務器返回的方法執行的結果.

在 XML-RPC 以後又有了更增強大的 SOAP , 用於一些比較複雜的系統之上。（在新的功能不斷被引入下，這個標準慢慢演變成爲今日的SOAP協定。XML-RPC協定是已登記的專利項目。）

SOAP：簡單對象訪問協議（Simple Object Access Protocol）是一種標準化的通信規範，主要用於Web服務（web service）中。

SOA 是前幾年炒的很火的一個詞, 不亞於當前的 Cloud Computing , 若是說 RPC 是基於方法調用(method),那麼 SOA 則是基於 消息，基於方法調用一般會與特定的程序語言 耦合起來,然後者則與具體的實現語言無關, 因此在必定程度上獲得大公司的支持。

用一個簡單的例子來講明 SOAP 使用過程，一個 SOAP 消息能夠發送到一個具備 Web Service 功能的 Web 站點，例如，一個含有房價信息的數據庫，消息的參數中標明這是一個查詢消息，此站點將返回一個 XML 格式的信息，其中包含了查詢結果（價格，位置，特色，或者其餘信息）。因爲數據是用一種標準化的可分析的結構來傳遞的，因此能夠直接被第三方站點所利用。

REST：表徵狀態轉移（Representational State Transfer），採用Web 服務使用標準的 HTTP 方法 (GET/PUT/POST/DELETE) 將全部 Web 系統的服務抽象爲資源，REST從資源的角度來觀察整個網絡，分佈在各處的資源由URI肯定，而客戶端的應用經過URI來獲取資源的表徵。

Http協議所抽象的get,post,put,delete就比如數據庫中最基本的增刪改查，而互聯網上的各類資源就比如數據庫中的記錄（可能這麼比喻不是很好），對於各類資源的操做最後老是能抽象成爲這四種基本操做，在定義了定位資源的規則之後，對於資源的操做經過標準的Http協議就能夠實現，開發者也會受益於這種輕量級的協議。

REST是一種軟件架構風格而非協議也非規範，是一種針對網絡應用的開發方式，能夠下降開發的複雜性，提升系統的可伸縮性。

一種 Web Service 可以若是知足 REST 的幾個條件, 一般就稱這個系統是 Restful 的.

這裏提到的條件包括:

1. C/S結構 (這是Internet服務的一個基本特徵)

2. 無狀態 (很熟悉吧,呵呵)

3. 能夠cache (想起了瀏覽器?)

4. 分層系統 (想起了無數的架構?)

5. 統一的接口 (若是這是可能的,程序員有福了, :D)

6. code on demand(可選, 實際上是一種擴展性的要求)

看了這幾個特徵後,你想起了什麼?

你可能會破口而出: HTTP.

我答: You got it!

HTTP是WWW的最核心的協議, 它將簡單的分佈於世界各個角落的資源都統一塊兒來, 統一的地址, 簡單的方法, 和必定數量的表達方式.(你可能對這三點描述很模糊,請go ahead).

REST 的三個要素是 惟一的資源標識, 簡單的方法 (此處的方法是個抽象的概念), 必定的表達方式.

看下圖:

圖一. REST的三角架構(摘自 Restful User Experience )

REST 是以 資源 爲中心, 名詞即資源的地址, 動詞即施加於名詞上的一些有限操做, 表達是對各類資源形態的抽象.

以HTTP爲例, 名詞即爲URI(統一資源標識), 動詞包括POST, GET, PUT, DELETE等(還有其它不經常使用的2個,因此 整個動詞集合是有限的), 資源的形態(如text, html, image, pdf等)

Web 應用程序最重要的 REST 原則是

客戶端和服務器之間的交互在請求之間是無狀態的。從客戶端到服務器的每一個請求都必須包含理解請求所必需的信息。若是服務器在請求之間的任什麼時候間點重啓，客戶端不會獲得通知。此外，無狀態請求能夠由任何可用服務器回答，這十分適合雲計算之類的環境。客戶端能夠緩存數據以改進性能。

在服務器端，應用程序狀態和功能能夠分爲各類資源。資源是一個有趣的概念實體，它向客戶端公開。資源的例子有：應用程序對象、數據庫記錄、算法等等。每一個資源都使用 URI (Universal Resource Identifier) 獲得一個唯一的地址。全部資源都共享統一的界面，以便在客戶端和服務器之間傳輸狀態。使用的是標準的 HTTP 方法，好比 GET、PUT、POST 和 DELETE。Hypermedia 是應用程序狀態的引擎，資源表示經過超連接互聯。

另外一個重要的 REST 原則是分層系統，這表示組件沒法瞭解它與之交互的中間層之外的組件。經過將系統知識限制在單個層，能夠限制整個系統的複雜性，促進了底層的獨立性。

當 REST 架構的約束條件做爲一個總體應用時，將生成一個能夠擴展到大量客戶端的應用程序。它還下降了客戶端和服務器之間的交互延遲。統一界面簡化了整個系統架構，改進了子系統之間交互的可見性。REST 簡化了客戶端和服務器的實現。

在 RPC 樣式的架構中，關注點在於方法，而在 REST 樣式的架構中，關注點在於資源 —— 將使用標準方法檢索並操做信息片斷（使用表示的形式）。資源表示形式在表示形式中使用超連接互聯。

RESTful API 設計指南

參考阮老師的博客吧：http://www.ruanyifeng.com/blog/2014/05/restful_api.html

以爲這個沒有什麼好說的！

RPC、SOAP、REST的區別

REST這種設計風格，它的不少思惟方式與RPC是徹底衝突的。

 RPC的思想是把本地函數映射到API，也就是說一個API對應的是一個function，我本地有一個getAllUsers，遠程也能經過某種約定的協議來調用這個getAllUsers。至於這個協議是Socket、是HTTP仍是別的什麼並不重要； RPC中的主體都是動做，是個動詞，表示我要作什麼。

 而REST則否則，它的URL主體是資源，是個名詞。並且也僅支持HTTP協議，規定了使用HTTP Method表達本次要作的動做，類型通常也不超過那四五種。這些動做表達了對資源僅有的幾種轉化方式。 這種設計思路是反程序員直覺的，由於在本地業務代碼中仍然是一個個的函數，是動做，但表如今接口形式上則徹底是資源的形式。 就像面向對象的「萬物皆對象」理論在習慣了純粹面向過程開發的程序員眼裏顯得十分別扭同樣：個人代碼原本就是按順序、循環、分支這麼運行的啊，爲啥非得在很明確的結構上封裝一層一層的基類子類接口，還要故意給兩個函數起同一個名字，調用時才選擇用哪個呢？ 使用「萬物皆資源」的思想編寫實際項目中的API接口時，最多見的問題就是「這玩意究竟是個什麼資源？………………算了，我就直接寫吧，無論什麼風格了」 好比，login和logout應該怎麼REST化？ 好比，多條件複合搜索在GET裏寫不下怎麼辦？ 好比，大量資源的刪除難道要寫幾千個DELETE？  其實在理解了REST後，這些都不是什麼無解的難題，只是思惟方式要轉換一下： login和logout其實只是對session資源的建立和刪除； search自己就是個資源，使用POST建立，若是不需持久化，能夠直接在Response中返回結果，若是須要（如翻頁、長期緩存等），直接保存搜索結果並303跳轉到資源地址就好了； id多到連url都寫不下的請求，應該建立task，用GET返回task狀態甚至執行進度； ……等等等。 

若是你想只記住一點,那麼就請記住 RPC是以動詞爲中心的, REST是以名詞爲中心的, 此處的 動詞指的是一些方法, 名詞是指資源.

你會發現,以動詞爲中心,意味着,當你要須要加入新功能時,你必需要添加更多的動詞, 這時候服務器端須要實現 相應的動詞(方法), 客戶端須要知道這個新的動詞並進行調用.

而以名詞爲中心, 假使我請求的是 hostname/friends/, 不管這個URI對應的服務怎麼變化,客戶端是無需 關注和更新的,而這種變化對客戶端也是透明的.

至於其它的區別,如對實現語言的依賴, 耦合性等,這些都是上面提到的這個根本區別所衍生的.

推薦閱讀 Restful User Experience (這個slide是我的認爲解釋的最好的) 還有 ReST vs SOA(P).

RPC與REST如何選擇?

一般若是咱們是客戶端,咱們基本上是沒有選擇的權利的, 服務提供商一般只有一種架構的服務.例如facebook, 人人 網開放的API(使用的是 REST ).

可是假若咱們有幸設計和實現本身的 Web Service 咱們該如何選擇呢?

成熟度上：SOAP在成熟度上優於REST

效率和易用性上：REST更勝一籌

安全性上：SOAP安全性高於REST，由於REST更關注的是效率和性能問題

整體上，由於REST模式的Web服務與複雜的SOAP和XML-RPC對比來說明顯的更加簡潔，愈來愈多的web服務開始採用REST風格設計和實現。例如，Amazon.com提供接近REST風格的Web服務進行圖書查找；雅虎提供的Web服務也是REST風格的。REST對於資源型服務接口來講很合適，同時特別適合對於效率要求很高，可是對於安全要求不高的場景。而SOAP的成熟性能夠給須要提供給多開發語言的，對於安全性要求較高的接口設計帶來便利。

根據筆者本身的經驗和心得, 建議 可以使用REST就儘可能使用REST, 主要基於下面幾個考慮:

1. 擴展性

2. 鬆耦合(意味着,不用強制要求客戶端去更新相應的代碼)

3. 客戶端實現語言無關

4. 性能

5. 安全性(例如HTTPS)

固然上述的幾點也並不是 RPC 都不知足,不過相對而言, REST 更加清晰和簡潔, 再輔以 JSON 相應的服務會在性能和穩定性(簡單一般意味着robust)方面有很大的提升。

固然，若是隻是規定了一種規範，卻不理解它表相下面的思惟方式，實施中又按照本身的理解隨意變更，那結果確定是混亂不堪的。 固然，API怎麼寫是開發者的自由。但若是一個API在url裏放一堆動詞、資源設計混亂、各類亂用HTTP Method和Status Code，還自稱RESTful API的話，那就像你養了一條狗，還管它叫貓同樣。 這種混搭產物，不如叫它REFU吧。 （Remove Extension From Url：從url裏去掉文件擴展名） 前面說了半天REST的理念和不懂REST形成的問題，可是，這並不表明REST比RPC更「高等」，更不是說不理解REST的人是落伍的。 所謂代碼風格、接口形式、各類林林總總的格式規定，其實都是爲了在團隊內部造成共識、防止我的習慣差別引發的混亂。JSON-RPC固然也是有規範的，但相比REST實在寬鬆太多了。 若是一個開發團隊規定必須在url裏寫action，全部請求都是POST，能夠嗎？固然也沒問題，只是不要拿出去標榜本身寫的是RESTful API就行。 規範最終仍是爲了開發者和軟件產品服務的，若是它能帶來便利、減小混亂，就值得用；反之，若是帶來的麻煩比解決的還多，那就犯不上純粹跟風追流行了。

因此我以爲純粹說什麼設計模式將會佔據主導地位沒有什麼意義，關鍵仍是看應用場景，正是那句老話：適合的纔是最好的

ICE

ICE是分佈式應用的一種比較好的解決方案，雖然如今也有一些比較流行的分佈式應用解決方案，如微軟的.NET（以及原來的DCOM）、CORBA及WEB SERVICE等，可是這些面向對象的中間件都存在一些不足：

 .NET是微軟產品，只面向WINDOWS系統，而實際的狀況是在當前的網絡環境下，不一樣的計算機會運行不一樣的系統，如LINUX上面就不可能使用.NET；

 CORBA雖然在統一標準方面作了不少的工做，可是不一樣的供應商實現之間仍是缺少互操做性，而且目前尚未一家供應商能夠針對全部的異種環境提供全部的實現支持，且CORBA的實現比較複雜，學習及實施的成本都會比較高；

 webService最要命的缺點就是他的性能問題，對於要求比較高的行業是不多會考慮 webService的。

 ICE的產生就是源於.NET、CORBA及WEB SERVICE這些中間件的不足，它能夠支持不一樣的系統，如WINDOWS、LINUX等，也能夠支持在多種開發語言上使用，如C++、C、JAVA、RUBY、PYTHON、VB等，服務端能夠是上面提到的任何一種語言實現的，客戶端也能夠根據本身的實際狀況選擇不一樣的語言實現，如服務端採用C語言實現，而客戶端採用JAVA語言實現，底層的通信邏輯經過ICE的封裝實現，咱們只須要關注業務邏輯。

ESB

企業服務總線（Enterprise Service Bus，ESB）的概念是從面向服務體系架構(Service Oriented Architecture， SOA)發展而來的。SOA描述了一種IT基礎設施的應用集成模型；其中的軟構件集是以一種定義清晰的層次化結構相互耦合。一個ESB是一個預先組裝的SOA實現，它包含了實現SOA分層目標所必需的基礎功能部件。

在企業計算領域，企業服務總線是指由中間件基礎設施產品技術實現的、 經過事件驅動和基於XML消息引擎，爲更復雜的面向服務的架構提供的軟件架構的構造物。企業服務總線一般在企業消息系統上提供一個抽象層，使得集成架構師可以不用編碼而是利用消息的價值完成集成工做。

企業服務總線提供可靠消息傳輸，服務接入，協議轉換，數據格式轉換，基於內容的路由等功能，屏蔽了服務的物理位置，協議和數據格式。

ESB與EAI區別：

ESB是將全部的系統的交互都放在SOA統一服務總線上面來控制處理。

EAI只是將不一樣的系統集成起來（能夠採用ESB總線形式，也能夠採用點對點的形式）。

ESB解決的問題

當你的應用像下面同樣時，這個時候就須要考慮使用ESB了，如圖：

各個應用系統之間的調用造成了一張網，沒有邏輯，隨着業務的增長，維護簡直就是一場惡夢。

各個應用的邏輯很清晰，每一個應用都只須要關心如何暴露本身的服務，而調用的應用只須要知道如何調用服務，至於怎麼作，去找誰，則徹底交給ESB來完成。

參考資料：

三種主流的Web服務實現方案（REST+SOAP+XML-RPC）簡述及比較

Web Service實踐之REST vs RPC

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

如何選擇ESB

Restful api詳解和rpc api 區別 （原文連接沒有搜到，谷歌找到的是轉