RPC 简介

1. RPC 是什么

RPC（Remote Procedure Call）远程过程调用协议，一种通过网络从远程计算机上请求服务，而 不需要了解底层网络技术 的协议。

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

这里的 Procedure (过程) 指的是在远程计算机上执行的一段代码或函数。在传统的编程中，当你调用一个 Procedure（也可以称为 Function 或 Subroutine，在不同的编程语言中叫法不同，但核心概念类似），它通常指的是你当前程序内部的一段可执行代码。例如业务处理、计算任务，更直白的说，就是程序，就是想调用本地方法一样调用远程的过程。

RPC 协议的主要目的是做到 不同服务间 调用方法像同一服务间调用 本地方法 一样

RPC 采用 C/S 的模式，通过 request-response 消息模式实现：

request-response

举个例子，我们定义一个函数，我们希望函数如果输入为 “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（接口描述文件层）序列化（protobuf/thrift serialization）
数据组织 （protobuf/thrift/json）
压缩（none/gzip/zlib/snappy/lz4）
协议（Sogou-std/Baidu-std/Thrift-framed/TRPC）
通信（TCP/HTTP）

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

rpc_level

如图从左到右，是用户接触得最多到最少的层次。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 再回来的整件事情是怎么做的：

rpc one-round life time

根据上图，可以更清楚地看到刚才提及的各个层级，其中压缩层、序列化层、协议层其实是互相解耦打通的，在 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 OK
SRPC-Status: 1
SRPC-Error: 0
Content-Type: application/json
Content-Encoding: identity
Content-Length: 16
Connection: Keep-Alive

{"message":"OK"}

5. 总结

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

通过这篇文章，相信我们可以清晰地了解到 RPC 是什么，接口长什么样，也可以通过与 HTTP 协议互通来理解协议层次，更重要的是可以知道具体纵向的每个层次，及横向对比我们常见的每种使用模式都有哪些。如果小伙伴对更多功能感兴趣，也可以通过阅读 SRPC 源码进行进一步了解。

6. 项目地址

https://github.com/sogou/srpc

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

7. 参考

https://www.cnblogs.com/kevinwan/p/14830073.html

posted @ 2025-06-11 21:29 光風霽月阅读(52) 评论(0) 收藏举报

刷新页面返回顶部

光風霽月