1、SOA

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

SOA有兩個層面的定義：

    從應用的角度定義：SOA是一種應用框架，它著眼於日常的業務應用，並將他們劃分為單獨的業務功能和流程，及所謂的服務。     從軟體的基本原理定義：SOA是一個元件模型，它將應用程式的不同功能單元(服務)通過這些服務之間定義良好的介面和契約聯絡起來。

SOA對於實現企業資源共享，打破 “資訊孤島” 的步驟如下：

    把引用和資源轉換為物件；     把這些服務程式設計標準的服務，形成資源的共享；

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

    使用者介面層 ---- 這些GUI的終端使用者或應用程式訪問的應用程式/服務介面；     業務流程層 ---- 在應用方面的業務用例服務；     服務層 ---- 服務合併在一起，提供統一的實時服務；     服務元件層 ---- 用來建造服務的元件，如功能庫、技術庫、技術介面等；     作業系統 ---- 這層包含資料模型，企業資料倉庫，技術平臺等；

因為SOA不依賴於任何技術，因此SOAP、RPC、REST是對SOA的不同實現。

2、SOAP

簡單物件訪問協議是交換資料的一種協議規範，是一種輕量的、簡單的、基於XML（標準通用標記語言下的一個子集）的協議，它被設計成在WEB上交換結構化的和固化的資訊。

擴充套件：

webService三要素：SOAP、WSDL(WebServicesDescriptionLanguage)、UDDI(UniversalDescriptionDiscovery andIntegration)之一， soap用來描述傳遞資訊的格式， WSDL 用來描述如何訪問具體的介面， uddi用來管理，分發，查詢webService 。 3、REST

表徵狀態轉移（Representional State Transfer）。其宗旨是從資源的角度來觀察整個網路，分佈在各處的資源由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，你需要設計一些程式嵌入到某種結構中。這種結構需要儲存引數、錯誤的程式碼、返回值等。 4、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.客戶接收控制代碼返回的資料

注意：

dobbo就是一種RPC框架。它是由alibaba得工程師為java開發的一個RPC，有很高的效能以及簡單的使用方法：

1、被遠端呼叫的介面，需要在zookeeper中進行註冊；

2、需要遠端呼叫的服務在zookeeper中宣告自己需要的介面；

3、zookeeper將已經註冊的介面通知給需要的服務； --------------------- 作者：SilenceCarrot 來源：CSDN 原文：https://blog.csdn.net/SilenceCarrot/article/details/52468521 版權宣告：本文為博主原創文章，轉載請附上博文連結！