微服務架構 REST與RPC比較與應用場景

rest是一種架構風格，指的是一組架構約束條件和原則。滿足這些約束條件和原則的應用程式或設計就是 restful。rest規範把所有內容都視為資源，網路上一切皆資源。

rest並沒有創造新的技術，元件或服務，只是使用web的現有特徵和能力。可以完全通過http協議實現，使用 http 協議處理資料通訊。rest架構對資源的操作包括獲取、建立、修改和刪除資源的操作正好對應http協議提供的get、post、put和delete方法。

http動詞與rest風格crud對應關係：

遠端方法呼叫，就是像呼叫本地方法一樣呼叫遠端方法。常見rpc框架結構圖：

rpc框架要做到的最基本的三件事：

1、服務端如何確定客戶端要呼叫的函式；

在遠端呼叫中，客戶端和服務端分別維護乙個【id->函式】的對應表， id在所有程序中都是唯一確定的。客戶端在做遠端過程呼叫時，附上這個id，服務端通過查表，來確定客戶端需要呼叫的函式，然後執行相應函式的**。

2、如何進行序列化和反序列化；

客戶端和服務端互動時將引數或結果轉化為位元組流在網路中傳輸，那麼資料轉化為位元組流的或者將位元組流轉換成能讀取的固定格式時就需要進行序列化和反序列化，序列化和反序列化的速度也會影響遠端呼叫的效率。

3、如何進行網路傳輸（選擇何種網路協議）；

多數rpc框架選擇tcp作為傳輸協議，也有部分選擇http。如grpc使用http2。不同的協議各有利弊。tcp更加高效，而http在實際應用中更加的靈活。

都是網路互動的協議規範。通常用於多個微服務之間的通訊協議。

比較項規範

rest

rpc通訊協議

一般使用tcp效能低

高靈活度高低

高與低是對實現兩種規範框架的相對比較，但也不是絕對的，需要根據實際情況而定。

rest和rpc都常用於微服務架構中。

1、http相對更規範，更標準，更通用，無論哪種語言都支援http協議。如果你是對外開放api，例如開放平台，外部的程式語言多種多樣，你無法拒絕對每種語言的支援，現在開源中介軟體，基本最先支援的幾個協議都包含restful。

rpc在微服務中的利用

2、 rpc 框架作為架構微服務化的基礎元件，它能大大降低架構微服務化的成本，提高呼叫方與服務提供方的研發效率，遮蔽跨程序呼叫函式（服務）的各類複雜細節。讓呼叫方感覺就像呼叫本地函式一樣呼叫遠端函式、讓服務提供方感覺就像實現乙個本地函式一樣來實現服務。

最後建議

rest呼叫及測試都很方便，rpc就顯得有點繁瑣，但是rpc的效率是毋庸置疑的，所以建議在多系統之間的內部呼叫採用rpc。對外提供的服務，rest更加合適。