目录
前言
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服务 | 必须按照特定服务框架的服务提供者规范 |
传递的数据 | 非面向对象封装，报文可查看原始数据； 如结构型json或简单的kv | 面向对象封装，复杂序列化，报文无法查看原始数据； 客户端仅需要传递对象数据即可，不需要按照特殊规则进行组装 |
报文大小 | 网路传输的报文较大， http请求和返回均会携带除数据外的其他必要信息， 对性能有一些影响 | 网络传输报文小，可提升性能 |
用途 | 可对外对内提供服务 | 仅对内提供服务 |
服务版本 | 不支持服务版本，需要服务提供者自行控制 | 支持服务版本，服务版本作为服务发现的一个元素 |
服务发现 | 非自动支持服务发现，需要依赖特定框架 | 自动支持 |
服务治理 | 非自动支持，需要依赖特定框架 | 自动提供 |
网络模型 | RESTful服务部署在servlet容器中， 如tomcat，servlet容器内部使用多路复用网络模型 | 依赖的网络框架(如netty)使用多路复用网络模型 |
编程语言限制 | 无限制 | 必须与所选服务框架一致 |
用于前后端分离 | 可以 | 不可以 |
如何选择
何时选用RESTful
供外部使用的服务 或 调用者使用任何编程语言均可直接访问的服务 或 用于前后端分离的服务
何时使用服务框架
供内部使用 且 调用者与提供者统一编程语言 且 业务服务器间交互，不用于前后端分离 且 性能要求高
微服务场景
面对微服务场景，服务提供者对服务进行为微服务化以及服务治理，但是对于服务使用者，希望更简洁灵活的使用服务，不受语言限制，所以RESTFul服务更适于微服务场景。
