SOA、RMI、RPC、Rest、RestFul、Soap、WebService詳解
目錄
一、SOA是什麼？
SOA的應用場景：
SOA主要的使用場景：
資料總線是什麼？
SOA最顯著的優勢：
SOA與微服務架構的差別：
二、WebService是什麼？
（1） SOAP：
（2）WSDL
（3）UDDI
三、什麼是RPC？
RPC工作原理：
JAVA能夠使用的遠端調用技術：
四、什麼是RMI?
五、什麼是Rest?
一、SOA是什麼？
SOA本質是一種元件模型。下面看一下百度的定義：
面向服務的架構（SOA）是一個元件模型，它将應用程式的不同功能單元（稱為服務）通過這些服務之間定義良好的接口和契約聯系起來。接口是采用中立的方式進行定義的，它應該獨立于實作服務的硬體平台、作業系統和程式設計語言（與平台無關，與語言無關，與作業系統無關）。這使得建構在各種各樣的系統中的服務可以以一種統一和通用的方式進行互動。
SOA的應用場景：
（1）一開始我們的系統可能是這樣的：
當我們的項目比較小時，我們隻有一個系統，并且把他們寫到一起，放在一個伺服器上，但是随着平台越來越大，資料量越來越大，我們不得不通過分庫，把多個子產品的資料庫分别放在對應得伺服器上，每個子產品調用自己的子系統即可。
随着我們系統的進一步複雜度的提示，我們不得不進一步對系統的性能進行提升，我們将多個子產品分成多個子系統，多個子系統直接互相調用（因為SOA一般用于大型項目，比較複雜，是以一般總系統不會再內建，會拆分多個，分别做成服務，互相調用）。當我們的電商UI進行一個下訂單的任務時，多個服務直接互相調用，系統通過資料總線，分别調用對于的子系統即可。
企業資料總線：企業資料總線不是對多個子子產品的內建，他在這裡充當資料通道的作用，資料總線不關心業務，資料總線根據給的位址和協定去調服務，上端不關心服務在哪裡是什麼，隻找資料總線。
上面幾個圖應該算是比較清楚了，随着業務的深入，我們不得不對系統進行調整，分别是對資料和業務的拆分，最後每個子系統對面提供服務。
SOA主要的使用場景： SOA、微服務結構、RMI、RPC、Rest、RestFul、Soap、WebService詳解一、SOA是什麼？二、WebService是什麼？三、什麼是RPC？四、什麼是RMI?五、什麼是Rest?
通過上面的圖我們可以看出，多個子系統直接互相互動，互相調用非常淩亂，這樣我們就很不爽，是以我們就用到了我們的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.調用本地系統核心發送網絡消息
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和微服務架構的元件或服務之間通信方式的不同實作。
參考資料：
https://blog.csdn.net/silencecarrot/article/details/52468521