非原创,仅做针对性总结:参考文章链接附于底部
名词解释
- RPC(Remote Procedure Call,远程过程调用)
- HTTP(HyperText Transfer Protocol 超文本传输协议)
RPC
主要是基于 TCP/IP
协议的,而 HTTP
服务主要是基于 HTTP
协议的,我们都知道 HTTP
协议是在传输层协议 TCP
之上的。
RPC 服务
RPC
架构里的四个核心的组件:
- 客户端(Client),服务的调用方。
- 服务端(Server),真正的服务提供者。
- 客户端存根(Client Stub),存放服务端的地址消息,再将客户端的请求参数打包成网络消息,然后通过网络远程发送给服务方。
- 服务端存根(Server Stub),接收客户端发送过来的消息,将消息解包,并调用本地的方法。
支持同步调用和异步调用
HTTP 服务
即:RESTful
风格的服务接口。优点就是简单、直接、开发方便。利用现成的 http
协议进行传输。
接口可能返回一个 JSON
字符串或者是 XML
文档。然后客户端再去处理这个返回的信息,从而可以比较快速地进行开发。
RPC VS HTTP
对于大型企业来说,内部子系统较多、接口非常多的情况下,RPC
框架的好处就显示出来了,首先就是长链接,不必每次通信都要像 http
一样去 3 次握手什么的,减少了网络开销;其次就是 RPC
框架一般都有注册中心,有丰富的监控管理;发布、下线接口、动态扩展等,对调用方来说是无感知、统一化的操作。
1. 传输协议
RPC,可以基于TCP协议,也可以基于HTTP协议
HTTP,基于HTTP协议
2. 传输效率
RPC,使用自定义的 TCP
协议,可以让请求报文体积更小,或者使用 HTTP2
协议,也可以很好的减少报文的体积,
提高传输效率
HTTP,如果是基于HTTP1.1的协议,请求中会包含很多无用的内容,如果是基于HTTP2.0
,那么简单的封装以下是可以作为一个 RPC
来使用的,这时标准 RPC
框架更多的是服务治理
3. 性能消耗
主要在于序列化和反序列化的耗时
RPC,可以基于thrift实现高效的二进制传输 HTTP,大部分是通过json来实现的,字节大小和序列化耗时都比thrift要更消耗性能
4. 负载均衡
RPC,基本都自带了负载均衡策略 HTTP,需要配置Nginx,HAProxy来实现
5.服务治理(下游服务新增,重启,下线时如何不影响上游调用者)
RPC,能做到自动通知,不影响上游 HTTP,需要事先通知,修改Nginx/HAProxy配置
上文来自于: