写点什么

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

发布于: 2021 年 05 月 31 日

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

2. RPC 有什么

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

  • 用户代码(client 的发送函数/server 的函数实现)

  • IDL 序列化(protobuf/thrift serialization)

  • 数据组织 (protobuf/thrift/json)

  • 压缩(none/gzip/zlib/snappy/lz4)

  • 协议 (Sogou-std/Baidu-std/Thrift-framed/TRPC)

  • 通信 (TCP/HTTP)


我们先关注以下三个层级:

如图从左到右,是用户接触得最多到最少的层次。IDL 层会根据开发者定义的请求/回复结构进行代码生成,目前小伙伴们用得比较多的是 protobuf 和 thrift,而刚才说到的用户接口和前后兼容问题,都是 IDL 层来解决的。SRPC 对于这两个 IDL 的用户接口实现方式是:

  • thrift:IDL 纯手工解析,用户使用 srpc 是不需要链 thrift 的库的 !!!

  • protobuf:service 的定义部分纯手工解析


中间那列是具体的网络协议,而各 RPC 能互通,就是因为大家实现了对方的“语言”,因此可以协议互通。


而 RPC 作为和 HTTP 并列的层次,第二列和第三列理论上是可以两两结合的,只需要第二列的具体 RPC 协议在发送时,把 HTTP 相关的内容进行特化,不要按照自己的协议去发,而按照 HTTP 需要的形式去发,就可以实现 RPC 与 HTTP 互通。

3. RPC 的生命周期

到此我们可以通过 SRPC 看一下,把 request 通过 method 发送出去并处理 response 再回来的整件事情是怎么做的:

根据上图,


可以更清楚地看到刚才提及的各个层级,其中压缩层、序列化层、协议层其实是互相解耦打通的,在 SRPC 代码上实现得非常统一,横向增加任何一种压缩算法或 IDL 或协议都不需要也不应该改动现有的代码,才是一个精美的架构~


我们一直在说生成代码,到底有什么用呢?图中可以得知,生成代码是衔接用户调用接口和框架代码的桥梁,这里以一个最简单的 protobuf 自定义协议为例:example.proto


syntax = "proto3";
message EchoRequest{ string message = 1;};
message EchoResponse{ string message = 1;};
service Example{ rpc Echo(EchoRequest) returns (EchoResponse);};
复制代码


我们定义好了请求、回复、远程服务的函数名,通过以下命令就可以生成出接口代码example.srpc.h


protoc example.proto --cpp_out=./ --proto_path=./srpc_generator protobuf ./example.proto ./
复制代码


我们一窥究竟,看看生成代码到底可以实现什么功能:


// SERVER代码class Service : public srpc::RPCService{public:    // 用户需要自行派生实现这个函数,与刚才pb生成的是对应的    virtual void Echo(EchoRequest *request, EchoResponse *response,                      srpc::RPCContext *ctx) = 0;};
// CLIENT代码using EchoDone = std::function<void (EchoResponse *, srpc::RPCContext *)>;
class SRPCClient : public srpc::SRPCClient {public: // 异步接口 void Echo(const EchoRequest *req, EchoDone done); // 同步接口 void Echo(const EchoRequest *req, EchoResponse *resp, srpc::RPCSyncContext *sync_ctx); // 半同步接口 WFFuture<std::pair<EchoResponse, srpc::RPCSyncContext>> async_Echo(const EchoRequest *req);};
复制代码


作为一个高性能 RPC 框架,SRPC 生成的 client 代码中包括了:同步、半同步、异步接口,文章开头展示的是一个同步接口的做法。


而 server 的接口就更简单了,作为一个服务端,我们要做的就是收到请求->处理逻辑->返回回复,而这个时候,框架已经把刚才提到的网络收发、解压缩、反序列化等都给做好了,然后通过生成代码调用到用户实现的派生 service 类的函数逻辑中。


由于一种协议定义了一种 client/server,因此其实我们同样可以得到的 server 类型有第二部分提到过的若干种:


  • SRPCServer

  • SRPCHttpServer

  • BRPCServer

  • TRPCServer

  • ThriftServer

  • ...

4. 一个完整的 server 例子

最后我们用一个完整的 server 例子,来看一下用户调用接口的使用方式,以及如何跨协议使用 HTTP 作为 client 进行调用。刚才提到,srpc_generator 在生成接口的同时,也会自动生成空的用户代码,我们这里打开 server.pb_skeleton.cc 直接改两行,即可 run 起来:


#include "example.srpc.h"#include "workflow/WFFacilities.h"
using namespace srpc;static WFFacilities::WaitGroup wait_group(1);
void sig_handler(int signo){ wait_group.done();}
class ExampleServiceImpl : public Example::Service{public:
void Echo(EchoRequest *request, EchoResponse *response, srpc::RPCContext *ctx) override { response->set_message("OK"); // 具体逻辑在这里添加,我们简单地回复一个OK }};
int main(){ unsigned short port = 80; // 因为要启动Http服务 SRPCHttpServer server; // 我们需要构造一个SRPCHttpServer
ExampleServiceImpl example_impl; server.add_service(&example_impl);
server.start(port); wait_group.wait(); server.stop(); return 0;}
复制代码


只要安装了 srpc,linux 下即可通过以下命令编译出可执行文件:


g++ -o server server.pb_skeleton.cc example.pb.cc -std=c++11 -lsrpc
复制代码


接下来是激动人心的时刻了,我们用人手一个的curl来发起一个 HTTP 请求:


$ curl -i 127.0.0.1:80/Example/Echo -H 'Content-Type: application/json' -d '{message:"Hello World"}'HTTP/1.1 200 OKSRPC-Status: 1SRPC-Error: 0Content-Type: application/jsonContent-Encoding: identityContent-Length: 16Connection: Keep-Alive
{"message":"OK"}
复制代码

5. 总结

今天我们基于 C++ 实现的开源项目 SRPC 深入分析了 RPC 的基本原理。SRPC 整体代码风格简洁、架构层次精巧,整体约 1 万行代码,如果你使用 C++,那可能非常适合你用来学习 RPC 架构。


通过这篇文章,相信我们可以清晰地了解到 RPC 是什么,接口长什么样,也可以通过与 HTTP 协议互通来理解协议层次,更重要的是可以知道具体纵向的每个层次,及横向对比我们常见的每种使用模式都有哪些。

6. 项目地址

更多功能可以通过阅读源码进一步了解:https://github.com/sogou/srpc

SRPC 底层通讯基于搜狗异步网络与计算框架 Workflow:https://github.com/sogou/workflow

欢迎使用并 star 支持一下作者的开源精神!

发布于: 2021 年 05 月 31 日阅读数: 459
用户头像

保持简单 2017.10.24 加入

go-zero作者

评论

发布
暂无评论
一文带你搞懂RPC到底是个啥