SOA、RMI、RPC、Rest、RestFul、Soap、WebService詳解

目錄

一、SOA是什麼？

        SOA本質是一種元件模型。下面看一下百度的定義：

面向服務的架構（SOA）是一個元件模型，它將應用程式的不同功能單元（稱為服務）通過這些服務之間定義良好的介面和契約聯絡起來。介面是採用中立的方式進行定義的，它應該獨立於實現服務的硬體平臺、作業系統和程式語言（與平臺無關，與語言無關，與作業系統無關）。這使得構建在各種各樣的系統中的服務可以以一種統一和通用的方式進行互動。

SOA的應用場景：

（1）一開始我們的系統可能是這樣的：

        當我們的專案比較小時，我們只有一個系統，並且把他們寫到一起，放在一個伺服器上，但是隨著平臺越來越大，資料量越來越大，我們不得不通過分庫，把多個模組的資料庫分別放在對應得伺服器上，每個模組呼叫自己的子系統即可。

       隨著我們系統的進一步複雜度的提示，我們不得不進一步對系統的效能進行提升，我們將多個模組分成多個子系統，多個子系統直接互相呼叫（因為SOA一般用於大型專案，比較複雜，所以一般總系統不會再整合，會拆分多個，分別做成服務，相互呼叫）。當我們的電商UI進行一個下訂單的任務時，多個服務直接互相呼叫，系統通過資料匯流排，分別呼叫對於的子系統即可。

     企業資料匯流排：企業資料匯流排不是對多個子模組的整合，他在這裡充當資料通道的作用，資料匯流排不關心業務，資料匯流排根據給的地址和協議去調服務，上端不關心服務在哪裡是什麼，只找資料匯流排。

     上面幾個圖應該算是比較清楚了，隨著業務的深入，我們不得不對系統進行調整，分別是對資料和業務的拆分，最後每個子系統對面提供服務。

SOA主要的使用場景：   

通過上面的圖我們可以看出，多個子系統直接相互互動，相互呼叫非常凌亂，這樣我們就很不爽，所以我們就用到了我們的SOA架構，SOA又叫服務治理，SOA就是幫助我們把服務之間呼叫的亂七八糟的關係給治理起來，然後提供一個統一的標準，把我們的服務治理成下圖所示，以前我們的服務是互相互動，現在是隻對資料匯流排進行互動，這樣系統就變得統一起來。

統一標準：各系統的協議、地址、互動方式。

新的互動方式：各個系統分別根據統一標準向資料匯流排進行註冊，各子系統呼叫其他子系統時，我們並不關心如果找到其他子系統，我們只招資料匯流排，資料匯流排再根據統一標準找其他子系統，所以資料匯流排在這裡充當一個只路人的作用。

資料匯流排是什麼？

       其實我在上面寫了，資料匯流排是起到排程服務的作用，資料匯流排不是整合服務，資料匯流排更新一個排程框架，每個服務需要根據約定向資料匯流排註冊服務，那麼如何註冊那？其實資料匯流排就像一個字典結構，

      資料匯流排裡面一個key對於一個value，key指的是服務名，value則是服務的排程方式，還有一點需要說明的是，資料匯流排只是指路人，服務是不經過資料匯流排的，如上圖的黃色線的路徑。

     資料匯流排通過域名解析實現:一個域名繫結多臺伺服器，ajax也可以，dns也可以，解析域名嘛。

     其實資料匯流排還有一些高階應用，比如心跳檢測，實現負載均衡等等，就不細說了，目前應用資料匯流排的有阿里的dubbo，還有zookeeper，以及Spring Cloud的Eureka

SOA最顯著的優勢：

（1）SOA具有低耦合性特點，業務夥伴對整個業務系統的影響較低

（2）SOA與平臺無關，減少了業務應用實現的限制

SOA與微服務架構的區別：

        從下面一張圖基本可以看出微服務架構的區別：

我覺得SOA與微服務的區別在於如下幾個方面：

1. 微服務相比於SOA更加精細，微服務更多的以獨立的程序的方式存在，互相之間並無影響；
2. 微服務提供的介面方式更加通用化，例如HTTP RESTful方式，各種終端都可以呼叫，無關語言、平臺限制；
3. 微服務更傾向於分散式去中心化的部署方式，在網際網路業務場景下更適合；

二、WebService是什麼？

我們看看百度百科對WebService的定義：

Web service是一個平臺獨立的，低耦合的，自包含的、基於可程式設計的web的應用程式，可使用開放的XML（標準通用標記語言下的一個子集）標準來描述、釋出、發現、協調和配置這些應用程式，用於開發分散式的互操作的應用程式。 [1]

Web Service技術， 能使得執行在不同機器上的不同應用無須藉助附加的、專門的第三方軟體或硬體， 就可相互交換資料或整合。依據Web Service規範實施的應用之間， 無論它們所使用的語言、 平臺或內部協議是什麼， 都可以相互交換資料。Web Service是自描述、 自包含的可用網路模組， 可以執行具體的業務功能。Web Service也很容易部署， 因為它們基於一些常規的產業標準以及已有的一些技術，諸如標準通用標記語言下的子集XML、HTTP。Web Service減少了應用介面的花費。Web Service為整個企業甚至多個組織之間的業務流程的整合提供了一個通用機制。

所以WebService是一種技術，比如可以讓使用.NET開發的應用程式呼叫使用Java開發的應用程式的介面，互相交換資料或整合，或者反過來。

所以只要是能夠平臺獨立，無關語言，無關作業系統，基於XML作為資料交換格式的應用程式都可以叫做Web Service。

要實現Web Service，需要一套協議來支援（WebService三要素：SOAP、WSDL、UDDI）：

（1） SOAP：

          SOAP（Simple Object Access Protocol：簡單物件訪問協議）是微軟、IBM等大公司聯合制定的一個協議規範。SOAP是交換資料的一種協議規範，是一種輕量的、簡單的、基於XML（標準通用標記語言下的一個子集）的協議，它被設計成在WEB上交換結構化的和固化的資訊。

（2）WSDL

           Web Service描述語言WSDL，用於描述Web Service及其函式、引數和返回值（也就是描述如何訪問具體的介面）。因為是基於XML的，所以WSDL既是機器可閱讀的，又是人可閱讀的。

（3）UDDI

          UDDI 的目的是為電子商務建立標準；UDDI是一套基於Web的、分散式的、為Web Service提供的、資訊註冊中心的實現標準規範，同時也包含一組使企業能將自身提供的Web Service註冊，以使別的企業能夠發現的訪問協議的實現標準。（簡單一句話概括就是：用來管理，分發，查詢webService）

三、什麼是RPC？

             簡單來說：SOAP=HTTP+XML，HTTP是基於TCP的超文字傳送協議。

             RPC（remote procedure call：遠端過程呼叫）：簡單的說，RPC就是從一臺機器（客戶端）上通過引數傳遞的方式呼叫另一臺機器（伺服器）上的一個函式或方法（可以統稱為服務）並得到返回的結果。

• RPC 會隱藏底層的通訊細節（不需要直接處理Socket通訊或Http通訊）
• RPC 是一個請求響應模型。客戶端發起請求，伺服器返回響應（類似於Http的工作方式）
• 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.客戶接收控制代碼返回的資料

JAVA能夠使用的遠端呼叫技術：

• 遠端方法呼叫（Remote Method Invocation，RMI）

• Caucho的Hession和Burlap（Hession是二進位制協議，而Burlap是基於XML的）

• Spring基於HTTP的遠端服務HttpInvoker

• 使用JAX-RPC和JAX-WS的Web Service（基於SOAP的web服務）

注意：RPC都是同步返回技術，也就是說程式會一直等待，直到超時或者得到返回結果。JMS(具體實現有ActiveMQ等)，AMQP(具體實現有RabbitMQ等)才是非同步返回技術

不管我們使用哪種遠端呼叫技術，Spring為使用這幾種不同的技術訪問和建立遠端服務都提供了廣泛的支援。

四、什麼是RMI?

        RMI是Java最初的遠端方法呼叫技術。RMI最初在JDK1.1被引入到Java平臺中，它為Java開發者提供了一種強大的方法來實現Java程式間的互動。在RMI之前，對於Java開發者來說，遠端呼叫的唯一選擇就是CORBA（在當時，需要購買一種第三方產品，叫做Object Request Broker[ORB]），或者手工編寫Socker程式。

    但是開發和訪問RMI服務是非常乏味無聊的，它涉及到好幾個步驟，包括程式的和手工的。Spring簡化了RMI模型，簡化了RMI的使用。

如果你曾經建立過RMI服務，應該會知道這會涉及如下幾個步驟：

1．編寫一個服務實現類，類中的方法必須丟擲java.rmi.RemoteException異常；

2．建立一個繼承於java.rmi.Remote的服務介面；

3．執行RMI編譯器（rmic），建立客戶端stub類和服務端skeleton類；

4．啟動一個RMI登錄檔，以便持有這些服務；

5．在RMI登錄檔中註冊服務。

哇！釋出一個簡單的RMI服務需要做這麼多的工作。除了這些必需的步驟外，你可能注意到了，會丟擲相當多的RemoteException和MalformedURLException異常。雖然這些異常通常意味著一個無法從catch程式碼塊中恢復的致命錯誤，但是我們仍然需要編寫樣板式的程式碼來捕獲並處理這些異常——即使我們不能修復它們

這些步驟和原生的jdbc一樣難用。。。。不能重複造輪子，所以用Spring吧。

RMI是一種實現遠端服務互動的好辦法，但是RMI有一些缺點和不足：

• RMI很難穿越防火牆。因為RMI使用任意埠來互動——這是防火牆通常所不允許的。如果是內網，就不需要擔心這個問題。如果是在網際網路上執行，這就麻煩了。

• RMI是基於JAVA的，使用了JAVA的序列化機制，所以通過網路傳輸的物件型別必須要保證在呼叫兩端的Java執行時中是完全相同的版本。所以就意味著客戶端和服務端都必須使用JAVA來開發才行。這就是一個限制了。

五、什麼是Rest?

• REST全稱：Representational State Transfer。Rest不是協議也不是規範，而是一種介面、服務、系統之間通訊的風格。

• REST可以用來替代傳統的SOAP Web服務。SOAP一般會關注行為和處理（比如RMI，Hessian，Spring的HttpInvoker,jaw-xs，知名的XFile(新的如CXF)、Axis1、Axis2 等等），而REST關注的是要處理的資料。

• REST與RPC幾乎沒有任何關係。RPC是面向服務的，並關注於行為和動作；而REST是面向資源的，強調描述應用程式的事物和名詞。REST就是將資源的狀態以最適合客戶端或服務端的形式從伺服器端轉移到客戶端（或者反過來）。

• 在REST中，資源通過URL進行識別和定位。

舉個栗子：

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

總結：

       SOA和微服務架構都是一種元件模型，一種架構方式，不依賴於任何技術，因此SOAP、RPC、REST是對SOA和微服務架構的元件或服務之間通訊方式的不同實現。

參考資料：