简述RPC与HTTP对比

目录

前言

RPC

RPC简述

REST

RPC服务框架

RPC与HTTP的对比

如何选择

何时选用RESTful

何时使用服务框架

微服务场景

---

前言

本文针对‘项目都会涉及的RPC服务和HTTP服务’进行对比，作为总结沉淀。能力有限，不够深入和全面，还请指点。

RPC

RPC简述

RPC，Remote Procedure Call，远程进程调用，属于一种架构概念，没有特定的实现方式，而是体现服务使用者、服务提供者的基本关系。如client端整理报文，发送给远程服务；远程服务器接收报文并解析，传给具体服务。RPC具有多种实现方式，可以是古老的基于http的webservice，可以是基于http的RESTful服务，也可是基于网络框架(如netty)实现的服务框架(如dubbo)。

REST

REST,Representational State Transfer，表述性状态传输，是一种架构设计风格，没有明确的标准。
满足如下REST风格的设计，即可称为RESTful。

• 客户端与服务端之间的交互在请求之间是无状态的，从客户端到服务端的每个请求都必须包含理解请求所必需的信息
• 每个资源对应唯一的URI
• 客户端使用GET、POST、PUT、DELETE操作方法对服务端资源进行操作
  • GET用来获取资源
  • POST用来新建资源（也可以用于更新资源）
  • PUT用来更新资源
  • DELETE用来删除资源

RESTful具有轻量级、http直接传输数据、无编程语言约束等特性，作为web service的一种实现方式。

RPC服务框架

基于网络框架实现的服务框架，自研或第三方机构研发的RPC服务中间件，具有侵入性，需要依赖第三方lib，且编程语言必须一致。

 

RPC与HTTP的对比

在互联网背景下，rpc与http的对比，应该具体为 基于http的RESTful服务 与 基于网络服务框架实现的服务 的对比。

	基于http的RESTful服务	基于网络服务框架实现的服务
应用层协议	基于http协议	自定义协议
网络与传输层协议	TCP和IP协议	TCP和IP协议
使用难度	简单，快速开发与使用接口	具有一些学习成本，简单，快速开发与使用接口
依赖特定框架	不需要强制依赖特定框架， 如果选择基于http的服务框架(netflix)，是需要准备环境的	强制依赖特定服务框架，需要额外准备环境，如服务发现
客户端要求	客户端无要求，可以通过任何http client调用服务	必须按照特定服务框架的服务消费者规范
服务提供者要求	服务提供者无要求，可以通过任意方式暴露RestFul服务	必须按照特定服务框架的服务提供者规范
传递的数据	非面向对象封装，报文可查看原始数据； 客户端按照接口规范和uri-param格式进行组装， 如结构型json或简单的kv	面向对象封装，复杂序列化，报文无法查看原始数据； 客户端仅需要传递对象数据即可，不需要按照特殊规则进行组装
报文大小	网路传输的报文较大， http请求和返回均会携带除数据外的其他必要信息， 对性能有一些影响	网络传输报文小，可提升性能
用途	可对外对内提供服务	仅对内提供服务
服务版本	不支持服务版本，需要服务提供者自行控制	支持服务版本，服务版本作为服务发现的一个元素
服务发现	非自动支持服务发现，需要依赖特定框架	自动支持
服务治理	非自动支持，需要依赖特定框架	自动提供
网络模型	RESTful服务部署在servlet容器中， 如tomcat，servlet容器内部使用多路复用网络模型	依赖的网络框架(如netty)使用多路复用网络模型
编程语言限制	无限制	必须与所选服务框架一致
用于前后端分离	可以	不可以

如何选择

何时选用RESTful

供外部使用的服务 或 调用者使用任何编程语言均可直接访问的服务 或 用于前后端分离的服务

何时使用服务框架

供内部使用 且 调用者与提供者统一编程语言 且 业务服务器间交互，不用于前后端分离 且 性能要求高

微服务场景

面对微服务场景，服务提供者对服务进行为微服务化以及服务治理，但是对于服务使用者，希望更简洁灵活的使用服务，不受语言限制，所以RESTFul服务更适于微服务场景。