浅谈RPC的理解
- 前言
- RPC体系
- Dubbo架构
- 最后
前言
本文中部分知识涉及Dubbo,需要对Dubbo有一定的理解,且对源码有一定了解
如果不了解,可以参考学习我之前的文章:
- 浅谈Spring整合Dubbo源码(@Service和@Reference注解部分)
- 浅谈Dubbo服务导出到注册中心源码
- 浅谈Dubbo服务引入源码(@ReferenceBean依赖注入)
- 浅谈Dubbo核心概念及架构流程
RPC体系
RPC与HTTP协议都属于网络协议中的应用层,HTTP协议侧重描述通信层面的约定,而RPC更加侧重于远程过程调用的目的(可以使程序能在网络上请求远程计算机上的服务,而无须关心底层网络技术细节),即两者并不冲突,比如RPC框架的实现之一Feign,其底层通信就是使用的HttpClient。
基于RPC需要具备的各项能力,可以对整个RPC的调用过程进行分层,将各项能力分布在各层中,最终达成我们的目的。下图为RPC各层的梳理,同时将开源的Dubbo框架架构图中的各层与RPC的各层进行了映射:
整体执行流程如下:
- 客户端调用:客户端通过本地调用远程过程的方式,就像调用本地方法一样;
- 数据序列化:客户端将调用的参数序列化为可以在网络上传输的格式,如二进制流或 JSON;
- 网络传输:序列化后的数据通过网络传输到远程服务器;
- 数据反序列化:服务器接收到数据后,将其反序列化为原始参数;
- 服务端执行:服务器执行相应的过程,并将结果返回;
- 结果序列化:服务器将执行结果序列化为可以在网络上传输的格式;
- 网络传输:序列化后的结果通过网络传输到客户端;
- 结果反序列化:客户端接收到结果后,将其反序列化为最终的返回值;
- 客户端接收结果:客户端获得最终的执行结果,完成整个过程。
Dubbo架构
在了解了RPC体系以后,再看Dubbo的架构图,尽管图中节点很多,但是我们可以很方便的抓住核心点(起码我很有感觉),即明白这是哪一层,这一层要干嘛,相关节点的大致作用。
最后
我们可以明确,类比于其他RPC框架,它们面对的问题、以及要解决的问题都是相同的,只不过不同的框架相关的实现有差异,仅此而已。
同时我们不难发现,不同RPC框架经常说的性能问题,其本质也就是①Message Protocol(消息管理层)、②Transfer/Network Protocol(传输管理层)、③描述后的URL(描述服务的协议方式)、④Registration Center(注册中心)之间的差异。