一文带你搞懂 RPC 到底是个啥

RPC（Remote Procedure Call），是一个大家既熟悉又陌生的词，只要涉及到通信，必然需要某种网络协议。我们很可能用过HTTP，那么RPC又和HTTP有什么区别呢？RPC还有什么特点，常见的选型有哪些？

1. RPC是什么

RPC可以分为两部分：用户调用接口 + 具体网络协议。前者为开发者需要关心的，后者由框架来实现。

举个例子，我们定义一个函数，我们希望函数如果输入为“Hello World”的话，输出给一个“OK”，那么这个函数是个本地调用。如果一个远程服务收到“Hello World”可以给我们返回一个“OK”，那么这是一个远程调用。我们会和服务约定好远程调用的函数名。因此，我们的用户接口就是：输入、输出、远程函数名，比如用 SRPC 开发的话，client端的代码会长这样：

int main()
{
   
    Example::SRPCClient client(IP, PORT);
    EchoRequest req; // 用户自定义的请求结构
    EchoResponse resp; // 用户自定义的回复结构

    req.set_message("Hello World");
    client.Echo(&req, &resp, NULL); // 调用远程函数名为Echo
    return 0;
}

具体网络协议，是框架来实现的，把开发者要发出和接收的内容以某种应用层协议打包进行网络收发。这里可以和HTTP进行一个明显的对比：

• HTTP也是一种网络协议，但包的内容是固定的，必须是：请求行 + 请求头 + 请求体；
• RPC是一种自定义网络协议，由具体框架来定，比如SRPC里支持的RPC协议有：SRPC/thrift/BRPC/tRPC

这些RPC协议都和HTTP平行，是应用层协议。我们再进一步思考，HTTP只包含具体网络协议，也可以返回比如我们常见的HTTP/1.1 200 OK，但仿佛没有用户调用接口，这是为什么呢？

这里需要搞清楚，用户接口的功能是什么？最重要的功能有两个：

• 定位要调用的服务；
• 让我们的消息向前/向后兼容；

我们用一个表格来看一下HTTP和RPC分别是怎么解决的：

	定位要调用的服务	消息前后兼容
HTTP	URL	开发者自行在消息体里解决
RPC	指定Service和Method名	交给具体IDL

因此，HTTP的调用减少了用户调用接口的函数，但是牺牲了一部分消息向前/向后兼容的自由度。但是，开发者可以根据自己的习惯进行技术选型，因为RPC和HTTP之间大部分都是协议互通的！是不是很神奇？接下来我们看一下RPC的层次架构，就可以明白为什么不同RPC框架之间、以及RPC和HTTP协议是如何做到互通的。

2. RPC有什么

我们可以从SRPC的架构层次上来看，RPC框架有哪些层，以及SRPC目前所横向支持的功能是什么：

• 用户代码（client的发送函数/server的函数实现）
• IDL序列化