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將已經註冊的接口通知給需要的服務；
修改自：https://blog.csdn.net/SilenceCarrot/article/details/52468521
作者：SilenceCarrot
閱讀更多 cpp軟件架構獅 的文章
