微服務Springcloud超詳細教程+實戰（二）

遠程調用方式
不管是微服務仍是分佈式服務（都是SOA，都是面向服務編程），都面臨着服務間的遠程調用。那麼服務間的遠程調用方式有哪些呢？

常見的遠程調用方式有如下幾種：

• RPC：Remote Produce Call遠程過程調用，相似的還有RMI（Remote Methods Invoke 遠程方法調用，是JAVA中的概念，是JAVA十三大技術之一）。自定義數據格式，基於原生TCP通訊，速度快，效率高。早期的webservice，如今熱門的dubbo，都是RPC的典型

  RPC的框架：webservie(cxf)、dubbo

  RMI的框架：hessian

• Http：http實際上是一種網絡傳輸協議，基於TCP，規定了數據傳輸的格式。如今客戶端瀏覽器與服務端通訊基本都是採用Http協議。也能夠用來進行遠程服務調用。缺點是消息封裝臃腫。

如今熱門的Rest風格，就能夠經過http協議來實現。

• http的實現技術：HttpClient

• 相同點：底層通信都是基於socket，均可以實現遠程調用，均可以實現服務調用服務

• 不一樣點：

RPC：框架有：dubbo、cxf、（RMI遠程方法調用）Hessian
當使用RPC框架實現服務間調用的時候，要求服務提供方和服務消費方 都必須使用統一的RPC框架，要麼都dubbo，要麼都cxf

跨操做系統在同一編程語言內使用
優點：調用快、處理快


http：框架有：httpClient
當使用http進行服務間調用的時候，無需關注服務提供方使用的編程語言，也無需關注服務消費方使用的編程語言，服務提供方只須要提供restful風格的接口，服務消費方，按照restful的原則，請求服務，便可

跨系統跨編程語言的遠程調用框架
優點：通用性強


總結：對比RPC和http的區別
1 RPC要求服務提供方和服務調用方都須要使用相同的技術，要麼都hessian，要麼都dubbo
  而http無需關注語言的實現，只須要遵循rest規範
2 RPC的開發要求較多，像Hessian框架還須要服務器提供完整的接口代碼(包名.類名.方法名必須徹底一致)，不然客戶端沒法運行
  
3 Hessian只支持POST請求

4 Hessian只支持JAVA語言

認識RPC

RPC，即 Remote Procedure Call（遠程過程調用），是一個計算機通訊協議。 該協議容許運行於一臺計算機的程序調用另外一臺計算機的子程序，而程序員無需額外地爲這個交互做用編程。說得通俗一點就是：A計算機提供一個服務，B計算機能夠像調用本地服務那樣調用A計算機的服務。

經過上面的概念，咱們能夠知道，實現RPC主要是作到兩點：

• 實現遠程調用其餘計算機的服務
• 要實現遠程調用，確定是經過網絡傳輸數據。A程序提供服務，B程序經過網絡將請求參數傳遞給A，A本地執行後獲得結果，再將結果返回給B程序。這裏須要關注的有兩點：
• 1）採用何種網絡通信協議？
• 如今比較流行的RPC框架，都會採用TCP做爲底層傳輸協議
• 2）數據傳輸的格式怎樣？
• 兩個程序進行通信，必須約定好數據傳輸格式。就比如兩我的聊天，要用同一種語言，不然沒法溝通。因此，咱們必須定義好請求和響應的格式。另外，數據在網路中傳輸須要進行序列化，因此還須要約定統一的序列化的方式。
• 像調用本地服務同樣調用遠程服務
• 若是僅僅是遠程調用，還不算是RPC，由於RPC強調的是過程調用，調用的過程對用戶而言是應該是透明的，用戶不該該關心調用的細節，能夠像調用本地服務同樣調用遠程服務。因此RPC必定要對調用的過程進行封裝

RPC調用流程圖：

想要了解詳細的RPC實現，給你們推薦一篇文章：本身動手實現RPC

認識Http

Http協議：超文本傳輸協議，是一種應用層協議。規定了網絡傳輸的請求格式、響應格式、資源定位和操做的方式等。可是底層採用什麼網絡傳輸協議，並無規定，不過如今都是採用TCP協議做爲底層傳輸協議。說到這裏，你們可能以爲，Http與RPC的遠程調用很是像，都是按照某種規定好的數據格式進行網絡通訊，有請求，有響應。沒錯，在這點來看，二者很是類似，可是仍是有一些細微差異。

• RPC並無規定數據傳輸格式，這個格式能夠任意指定，不一樣的RPC協議，數據格式不必定相同。
• Http中還定義了資源定位的路徑，RPC中並不須要
• 最重要的一點：RPC須要知足像調用本地服務同樣調用遠程服務，也就是對調用過程在API層面進行封裝。Http協議沒有這樣的要求，所以請求、響應等細節須要咱們本身去實現。
• 優勢：RPC方式更加透明，對用戶更方便。Http方式更靈活，沒有規定API和語言，跨語言、跨平臺
• 缺點：RPC方式須要在API層面進行封裝，限制了開發的語言環境。

例如咱們經過瀏覽器訪問網站，就是經過Http協議。只不過瀏覽器把請求封裝，發起請求以及接收響應，解析響應的事情都幫咱們作了。若是是不經過瀏覽器，那麼這些事情都須要本身去完成。

如何選擇？

既然兩種方式均可以實現遠程調用，咱們該如何選擇呢？

• 速度來看，RPC要比http更快，雖然底層都是TCP，可是http協議的信息每每比較臃腫

• 難度來看，RPC實現較爲複雜，http相對比較簡單

• 靈活性來看，http更勝一籌，由於它不關心實現細節，跨平臺、跨語言。
  所以，二者都有不一樣的使用場景：

• 若是對效率要求更高，而且開發過程使用統一的技術棧，那麼用RPC仍是不錯的。

• 若是須要更加靈活，跨語言、跨平臺，顯然http更合適

那麼咱們該怎麼選擇呢？

微服務，更增強調的是獨立、自治、靈活。而RPC方式的限制較多，所以微服務框架中，通常都會採用基於Http的Rest風格服務。