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这个类