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，請看這篇文章：https://www.cnblogs.com/renzhitian/p/6853289.html
SOA與微服務架構的區別：
從下面一張圖基本可以看出微服務架構的區別：
我覺得SOA與微服務的區別在於如下幾個方面：
- 微服務相比於SOA更加精細，微服務更多的以獨立的進程的方式存在，互相之間並無影響；
- 微服務提供的接口方式更加通用化，例如HTTP RESTful方式，各種終端都可以調用，無關語言、平臺限制；
- 微服務更傾向於分佈式去中心化的部署方式，在互聯網業務場景下更適合；
二、WebService是什麼？
關於WebSerivce和Soap的發展歷史，可以看一下這篇文章：https://blog.csdn.net/cxboyee/article/details/77802849
我們看看百度百科對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.調用本地系統內核發送網絡消息
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和微服務架構的組件或服務之間通信方式的不同實現。
參考資料：
https://blog.csdn.net/silencecarrot/article/details/52468521