分佈式調用技術 RPC VS REST

 

一 分佈式調用大致上就分爲兩類，RPC式的，REST式的，二者的區別主要是就是：

1. RPC是面向動做的（方法調用）

2. REST是面向資源的（URL表示資源，HTTP動詞表示動做）

從變現形式來看，RPC的編程模型較重量級，REST的編程模型更輕量級

 

二 REST vs RPC

     REST is not a framework like WCF, a protocol like HTTP, a framework like JAX-RS, or a communication format like SOAP.  REST is an architecture, a structured way of representing a software solution - specifically, exposing aspects of a solution to a set of remote client-consumers.  The central tenet of REST is that these aspects of a solution can be modeled as resources which the client can consume or act upon.  

 

This resource-oriented thinking, and not the implementation details of how one communicates between client and server, is what REST is actually all about.  This is the key difference that separates actual RESTful APIs from RPC based on HTTP verbs.

 

 

三  接口調用一般包含兩個部分， 序列化和通訊協議。

     常見的序列化協議包括json、xml、hession、protobuf、thrift、text、bytes等；

     通訊比較流行的是http、soap、websockect，RPC一般基於TCP實現，經常使用框架例如dubbo，netty、mina、thrift。

 

首先解釋下兩種接口調用：

Rest：嚴格意義上說接口很規範，操做對象即爲資源，對資源的四種操做（post、get、put、delete），而且參數都放在URL上,

         可是不嚴格的說Http+json、Http+xml，常見的http api均可以稱爲Rest接口。

Rpc:   咱們常說的遠程方法調用，就是像調用本地方法同樣調用遠程方法，通訊協議大多采用二進制方式

 

四  http vs 高性能二進制協議
      http相對更規範，更標準，更通用，不管哪一種語言都支持http協議。

       若是你是對外開放API，例如開放平臺，外部的編程語言多種多樣，你沒法拒絕對每種語言的支持，

       相應的，若是採用http，無疑在你實現SDK以前，支持了全部語言，

       因此，如今開源中間件，基本最早支持的幾個協議都包含RESTful。

    RPC協議性能要高的多，例如Protobuf、Thrift、Kyro等，

    （若是算上序列化）吞吐量大概能達到http的二倍。響應時間也更爲出色。

      千萬不要小看這點性能損耗，公認的，微服務作的比較好的，例如，netflix、阿里，曾經都傳出過爲了提高性能而合併服務。

      若是是交付型的項目，性能更爲重要，由於你賣給客戶每每靠的就是性能上微弱的優點。

     

  不管是Google、Amazon、netflix（聽說極可能轉向grpc），仍是阿里，實際上內部都是採用性能更高的RPC方式。而對外開放的纔是RESTful。

  Rest 調用及測試都很方便，Rpc就顯得有點麻煩，可是Rpc的效率是毋庸置疑的，因此建議在多系統之間採用Rpc，對外提供服務，Rest是很適合的
  duboo在生產者和消費者兩個微服務之間的通訊採用的就是Rpc,無疑在服務之間的調用Rpc更變現的優秀

 

五  Rpc在微服務中的使用

一、 RPC 框架是架構微服務化的首要基礎組件 ，

          它能大大下降架構微服務化的成本，提升調用方與服務提供方的研發效率，屏蔽跨進程調用函數（服務）的各種複雜細節
二、RPC 框架的職責是：

          讓調用方感受就像調用本地函數同樣調用遠端函數、讓服務提供方感受就像實現一個本地函數同樣來實現服務

 

 

RPC的好處：

     RPC 的主要功能目標是讓構建分佈式計算（應用）更容易，在提供強大的遠程調用能力時不損失本地調用的語義簡潔性。

     爲實現該目標，RPC 框架需提供一種透明調用機制讓使用者沒必要顯式的區分本地調用和遠程調用。

     服務化的一個好處就是，不限定服務的提供方使用什麼技術選型，可以實現大公司跨團隊的技術解耦。 
     若是沒有統一的服務框架，RPC框架，

          各個團隊的服務提供方就須要各自實現一套序列化、反序列化、網絡框架、鏈接池、收發線程、超時處理、狀態機等「業務以外」的重複技術勞動，形成總體的低效。

    因此，統一RPC框架把上述「業務以外」的技術勞動統一處理，是服務化首要解決的問題。

 

 

六 幾種協議

  Socket使用時能夠指定協議Tcp,Udp等；

  RIM使用Jrmp協議，Jrmp又是基於TCP/IP；

  RPC底層使用Socket接口，定義了一套遠程調用方法；

  HTTP是創建在TCP上，不是使用Socket接口，須要鏈接方主動發數據給服務器，服務器沒法主動發數據個客戶端；

  Web Service提供的服務是基於web容器的，底層使用http協議，相似一個遠程的服務提供者，

       好比天氣預報服務，對各地客戶端提供天氣預報，是一種請求應答的機制，是跨系統跨平臺的。

       就是經過一個servlet，對外提供服務。
 hessian是一套用於創建web service的簡單的二進制協議，

      用於替代基於XML的web service，

      是創建在rpc上的，hessian有一套本身的序列化格式將數據序列化成流，而後經過http協議發送給服務器

 

在微服務架構中，各個服務之間可能千差萬別，rest接口更加靈活，若是使用RPC則會有不少約束

 

 

 

參考：

1  https://sites.google.com/site/wagingguerillasoftware/rest-series/what-is-restful-rest-vs-rpc

2  https://blog.csdn.net/iter_zc/article/details/39341983

3  http://www.javashuo.com/article/p-nnouzves-mk.html