乘风原创程序

  • 一文带你搞懂 RPC 到底是个啥
  • 2021/7/2 14:08:43
  • 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序列化(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 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. 项目地址

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