微服務的遠程調用方式

引言

1. 無論是 SOA 還是微服務，都是面向服務的思想，都面臨服務之間的遠程調用，而遠程調用不同的情景下又有不同的選擇
2. RPC：
   Remote Produce Call遠程過程調用，類似的還有RMI。自定義數據格式，基於原生TCP通信，速度快，效率高。早期的webservice，現在熱門的dubbo，都是RPC的典型
3. HTTP：
   http其實是一種網絡傳輸協議，基於TCP，規定了數據傳輸的格式。現在客戶端瀏覽器與服務端通信基本都是採用Http協議。也可以用來進行遠程服務調用。缺點是消息封裝臃腫
4. 現在熱門的Rest風格，就可以通過http協議來實現
5. Rest風格不是一種語言，而是一種編程思想，目的是爲了使得服務更容易被不同的對象調用，儘可能的增強服務的兼容性

RCP

1. RPC，即 Remote Procedure Call（遠程過程調用），是一個計算機通信協議。 該協議允許運行於一臺計算機的程序調用另一臺計算機的子程序，而程序員無需額外地爲這個交互作用編程。說得通俗一點就是：A計算機提供一個服務，B計算機可以像調用本地服務那樣調用A計算機的服務。而RPC的實現主要是做到了以下兩點：

   1. 實現遠程調用其他計算機的服務 ：
      1. 要實現遠程調用，肯定是通過網絡傳輸數據。A程序提供服務，B程序通過網絡將請求參數傳遞給A，A本地執行後得到結果，再將結果返回給B程序。這裏需要關注的有兩點
      2. 一是採用何種網絡通訊協議？ — 現在比較流行的RPC框架，都會採用TCP作爲底層傳輸協議
      3. 二是數據傳輸的格式怎樣？ — 兩個程序進行通訊，必須約定好數據傳輸格式。就好比兩個人聊天，要用同一種語言，否則無法溝通。所以，我們必須定義好請求和響應的格式。另外，數據在網路中傳輸需要進行序列化，所以還需要約定統一的序列化的方式
   2. 像調用本地服務一樣調用遠程服務 ：
      如果僅僅是遠程調用，還不算是RPC，因爲RPC強調的是過程調用，調用的過程對用戶而言是應該是透明的，用戶不應該關心調用的細節，可以像調用本地服務一樣調用遠程服務。所以RPC一定要對調用的過程進行封裝

2. RPC調用流程圖
   

HTTP

1. Http協議：超文本傳輸協議，是一種應用層協議。規定了網絡傳輸的請求格式、響應格式、資源定位和操作的方式等。但是底層採用什麼網絡傳輸協議，並沒有規定，不過現在都是採用TCP協議作爲底層傳輸協議。說到這裏，大家可能覺得，Http與RPC的遠程調用非常像，都是按照某種規定好的數據格式進行網絡通信，有請求，有響應。沒錯，在這點來看，兩者非常相似，但是還是有一些細微差別
   1. RPC並沒有規定數據傳輸格式，這個格式可以任意指定，不同的RPC協議，數據格式不一定相同
   2. Http中還定義了資源定位的路徑，RPC中並不需要
   3. 最重要的一點：RPC需要滿足像調用本地服務一樣調用遠程服務，也就是對調用過程在API層面進行封裝。Http協議沒有這樣的要求，因此請求、響應等細節需要我們自己去實
      1. 優點：RPC方式更加透明，對用戶更方便。Http方式更靈活，沒有規定API和語言，跨語言、跨平臺
      2. 缺點：RPC方式需要在API層面進行封裝，限制了開發的語言環境
2. HTTP調用流程圖
   

RCP 和 HTTP 的選擇

1. 速度來看，RPC要比http更快，雖然底層都是TCP，但是http協議的信息往往比較臃腫，不過可以採用gzip壓縮
2. 難度來看，RPC實現較爲複雜，http相對比較簡單
3. 活性來看，http更勝一籌，因爲它不關心實現細節，跨平臺、跨語言
4. 如果對效率要求更高，並且開發過程使用統一的技術棧，那麼多選用RCP
5. 如果需要更加靈活，跨語言、跨平臺，顯然http更合適
6. 微服務，更加強調的是獨立、自治、靈活。而RPC方式的限制較多，因此微服務框架中，一般都會採用基於Http的Rest風格服務