什么是RPC
RPC(Remote Procedure Call),又叫做远程过程调用。它并不是一个具体的协议,而是一种调用方式。
像之前的单体时代,我们的 service 调用就是自己实现的方法,是本地进程内的调用。
public User getUserById(Long id) {
return userDao.getUserById(id); // 这叫本地调用
}
现在都是微服务了,根据业务模块做了不同的拆分,像用户的服务不用我这个小组负责,我这小组只要写订单服务就行了。
但是我们服务需要用到用户的信息,于是我们需要调用用户小组的服务,于是代码变成了以下这种
public User getUserById(Long id) {
return userConsumer.getUserById(id); // 远程调用
}
我们像调用本地方法那样去调用它,屏蔽掉一些网络细节,这样用起来岂不是很方便。
值得注意的是,虽然大部分RPC协议底层使用TCP,但实际上它们不一定非得使用TCP,改用UDP或者HTTP,其实也可以做到类似的功能。
既然有RPC了,为什么还要有HTTP?
RPC 调用使用的场景更多的公司内部的多个服务之间的通信。
服务的拆分独立部署,那服务间的调用就必然需要网络通信,用 Http的方式 调用当然可行,但是比较麻烦。
想要服务被拆分了但是使用起来还是和之前本地调用一样方便,所以就出现了 RPC 框架,来屏蔽这些底层调用细节,使得我们编码上还是和之前本地调用相差不多。
HTTP 协议比较的冗余,RPC 都是内部调用所以不需要太考虑通用性,只要公司内部保持格式统一即可。
HTTP和RPC有什么区别
我们来看看RPC和HTTP区别比较明显的几个点。
服务发现
首先要向某个服务器发起请求,你得先建立连接,而建立连接的前提是,你得知道IP地址和端口。这个找到服务对应的IP端口的过程,其实就是服务发现。
在HTTP中,你知道服务的域名,就可以通过DNS服务去解析得到它背后的IP地址。
而RPC的话,就有些区别,一般会有专门的中间服务去保存服务名和IP信息,比如consul。想要访问某个服务,就去这些中间服务去获得IP和端口信息。
底层连接形式
以主流的HTTP1.1协议为例,其默认在建立底层TCP连接之后会一直保持这个连接(keep alive),之后的请求和响应都会复用这条连接。
RPC,也跟HTTP类似,也是通过建立TCP长链接进行数据交互,但不同的地方在于,RPC协议一般还会再建个连接池,在请求量大的时候,建立多条连接放在池内,要发数据的时候就从池里取一条连接出来,用完放回去,下次再复用,可以说非常环保。
由于连接池有利于提升网络请求性能,所以不少编程语言的网络库里都会给HTTP加个连接池,比如go就是这么干的。这一块两者也没太大区别。
传输的内容
基于TCP传输的消息:header是用于标记一些特殊信息、body则是放我们真正需要传输的内容。
可以看到像header里的很多信息,其实如果我们约定好之后,就不用每次都传输了,比如"content-type"这个字段。
RPC,因为它定制化程度更高,可以采用体积更小的protobuf或其他序列化协议去保存结构体数据,同时也不需要像HTTP那样考虑各种浏览器行为,比如302重定向跳转什么的。因此性能也会更好一些。
HTTP原理
RPC原理