RPC接口測試（二） RPC 與HTTP的區別

RPC 與HTTP的相同點

兩種風格的API區別，總結一下其實很是簡單：

1，RPC面向過程，只發送 GET 和 POST 請求。GET用來查詢信息，其餘狀況下一概用POST。請求參數是動詞，直接描述動做自己。,

2，RESTful面向資源，使用 POST、DELETE、PUT、GET 請求，分別對應增、刪、改、查操做。請求參數是名詞，這個名詞就是「增刪改查」想要操做的對象。

前面提到，這樣對比RPC與REST並不徹底準確，緣由在於RPC不只僅是一種API設計風格，它的概念比這要廣得多。PRC全稱是Remote Procedure Call，即遠程過程調用。我發送了一個RPC請求好比 POST /removeItem?itemId=456，其實是調用了服務端的一個方法 removeItem(int itemId)。在我本地電腦上能夠調用一個遠在服務端的方法，因此叫遠程過程調用。這個"遠"的概念也不必定是跨越網絡的，同一臺主機的兩個進程之間相互交流也徹底能夠是RPC。

 

只要是遠程調用均可以叫RPC，和是否是經過http沒什麼關係，REST就是一種經常使用的rpc。

固然rpc也有不經過http的，能夠直接走socket，或者其餘協議，在不一樣的場景甚至有優於http的性能表現，這個很正常。用http不是由於它性能好，而是由於它普適，隨便一個web容器就能跑起來你的應用。

 對外開放給全世界的API推薦採用RESTful，是否嚴格按照規範是一個要權衡的問題。要綜合成本、穩定性、易用性、業務場景等等多種因素。
內部調用推薦採用RPC方式，固然不能一律而論，還要看具體的業務場景。

 

RPC 與HTTP的不一樣點

在HTTP和RPC的選擇上，可能有些人是迷惑的，主要是由於，有些RPC框架配置複雜，若是走HTTP也能完成一樣的功能，那麼爲何要選擇RPC，而不是更容易上手的HTTP來實現了。

本文主要來闡述HTTP和RPC的異同，讓你們更容易根據本身的實際狀況選擇更適合的方案。

傳輸協議

RPC，能夠基於TCP協議，也能夠基於HTTP協議

HTTP，基於HTTP協議（在TCP協議之上進行封裝）

傳輸效率

RPC，使用自定義的TCP協議，可讓請求報文體積更小，或者使用HTTP2協議，也能夠很好的減小報文的體積，提升傳輸效率

HTTP，若是是基於HTTP1.1的協議，請求中會包含不少無用的內容，若是是基於HTTP2.0，那麼簡單的封裝如下是能夠做爲一個RPC來使用的，這時標準RPC框架更多的是服務治理

性能消耗，主要在於序列化和反序列化的耗時

RPC，能夠基於thrift實現高效的二進制傳輸

HTTP，大部分是經過json來實現的，字節大小和序列化耗時都比thrift要更消耗性能

負載均衡

RPC，基本都自帶了負載均衡策略

HTTP，須要配置Nginx，HAProxy來實現

服務治理（下游服務新增，重啓，下線時如何不影響上游調用者）

RPC，能作到自動通知，不影響上游

HTTP，須要事先通知，修改Nginx/HAProxy配置

總結：

  RPC主要用於公司內部的服務調用，性能消耗低，傳輸效率高，服務治理方便。HTTP主要用於對外的異構環境，瀏覽器接口調用，APP接口調用，第三方接口調用等。

 

 

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

- 速度來看，RPC要比http更快，雖然底層都是TCP，可是http協議的信息每每比較臃腫，不過能夠採用gzip壓縮。
- 難度來看，RPC實現較爲複雜，http相對比較簡單
- 靈活性來看，http更勝一籌，由於它不關心實現細節，跨平臺、跨語言。

所以，二者都有不一樣的使用場景：

- 若是對效率要求更高，而且開發過程使用統一的技術棧，那麼用RPC仍是不錯的。
- 若是須要更加靈活，跨語言、跨平臺，顯然http更合適

微服務，更增強調的是獨立、自治、靈活。而RPC方式的限制較多，所以微服務框架中，通常都會採用基於Http的Rest風格服務，像在公司對內系統用hsf協議，對接外部系統用微服務，調用RestTemplate這個類