什么是RPC？

Remote Procedure Call，远程过程调用。

什么是“远程”，为什么“远”？

先来看下什么是“近”，即“本地函数调用”。

当我们写下：

int result = Add(1, 2);

这行代码的时候，到底发生了什么？

（1）传递两个入参；

（2）调用了本地代码段中的函数，执行运算逻辑；

（3）返回一个出参；

这三个动作，都发生在同一个进程空间里，这是本地函数调用。

那有没有办法，调用一个跨进程的函数呢？

典型的，这个进程部署在另一台服务器上。

最容易想到的，两个进程约定一个协议格式，使用Socket通信，来传输：

（1）入参；

（2）调用哪个函数；

（3）出参；

如果能够实现，那这就是“远程”过程调用。

为什么需要RPC框架呢？

如果没有统一的RPC框架，各个团队的服务提供方就需要各自实现一套序列化、反序列化、网络框架、连接池、收发线程、超时处理、状态机等“业务之外”的重复技术劳动，造成整体的低效。

RPC框架的职责，就是要屏蔽各种复杂性：

（1）调用方client感觉就像调用本地函数一样，来调用服务；

（2）提供方server感觉就像实现一个本地函数一样，来实现服务；

有哪些常见的，出圈的RPC框架呢？

（1）gRPC，Google出品，支持多语言；

（2）Thrift，Facebook出品，支持多语言；

（3）Dubbo，阿里开源的，支持Java；

（4）bRPC，百度开源的，支持C++，Java；

（5）tRPC，腾讯RPC框架，支持多语言；

（6）...

今天和大家分享的srpc，作者是搜狗的媛架构师liyingxin，基于WF，代码量1W左右：

（1）非常适合用来学习RPC的架构设计；

（2）又是一个工业级的产品，QPS可以到50W，应该是行业能目前性能最好的RPC框架了吧，有不少超高并发的线上应用都使用它。

什么是srpc？

基于WF的轻量级，超高性能，工业级RPC框架，兼容多协议，例如百度bRPC，腾讯tRPC，Google的gRPC，以及FB的thrift协议。

srpc有些什么特点？

（1）支持多种IDL格式，包括Protobuf，Thrift等，对于这类项目，可以一键迁移；

（2）支持多种序列化方式，包括Protobuf，Thrift，json等；

（3）支持多压缩方法，对应用透明，包括gzip，zlib，lz4，snappy等；

（4）支持多协议，对应用透明，包括http，https，ssl，tcp等；

（5）高性能；

不同客户端线程压力下的性能表现非常稳定，QPS在50W左右，优于同等压测配置的bRPC与thrift。

（6）轻量级，低门槛，1W行左右代码，只需引入一个静态库；

如何快速上手，体验这个帅气的RPC框架呢？

简单来说，只需要三个步骤。

第一步：定义IDL描述文件。

syntax = "proto3";// proto2 or proto3

message EchoRequest {

string message = 1;

string name = 2;

};

message EchoResponse {

string message = 1;

};

service Example {

rpc Echo(EchoRequest) returns (EchoResponse);

};

第二步：生成代码，并实现ServiceIMPL，server端就搞定了。

class ExampleServiceImpl : public Example::Service

{

public:

void Echo(EchoRequest *request,

EchoResponse *response,

RPCContext *ctx) override

{

response->set_message("Hi, " + request->name());

}

};

make一把，一气呵成。

第三步：自己定义一个请求客户端，向服务端发送echo请求。

int main()

{

Example::SRPCClient client("127.0.0.1", 1412);

EchoRequest req;

req.set_message("Hello, srpc!");

req.set_name("zhangsan");

client.Echo(&req,

[](EchoResponse *response, RPCContext *ctx){});

return 0;

}

srpc的架构设计思路是怎样的？

作为一个RPC框架，srpc的架构是异常清晰的，用户需要关注这3个层次：

（1）IDL接口描述文件层；

（2）RPC序列化协议层；

（3）网络通讯层；

同时，每一层次又提供了多种选择，用户可以任意的组合：

如上图所示：

（1）IDL层，用户可以选择Protobuf或者Thrift；

（2）协议层，可以选择Thrift，bRPC，tRPC等；

（3）通信层，可以选择tcp或者http；

在此分层架构之下，RPC的客户端要做什么工作，RPC的服务端要做什么工作，srpc框架又做了什么工作呢？

首先必须在IDL中要定义好：

（1）逻辑请求包request；

（2）逻辑响应包response；

（3）服务接口函数method；

RPC-client的工作就异常简单了：

（1）调用method；

（2）绑定回调函数，处理回调；

对应上图中顶部方框的绿色部分。

RPC-server的工作也非常简单，像实现一个本地函数一样，提供远程的服务：

（1）实现method；

（2）接受request，逻辑处理，返回response；

对应上图中底部方框的黄色部分。

srpc框架完成了绝大部分的工作：

（1）对request序列化，压缩，处理生成二进制报文；

（2）连接池，超时，任务队列，异步等处理；

（3）对request二进制报文处理，解压缩，反序列化；

...

对应上图中中间的方框的红色部分，以及大部分流程。

在这个过程中，srpc采用插件化设计，各种复杂性细节，对接口调用方与服务提供方，都是透明的，并且具备良好的扩展性。

如上图所示，用户只需要关注IDL，即逻辑请求，响应，接口的调用与实现。框架层面，将各种能力以插件的方式集成进来，向用户提供不同能力的组合选择。

另外，定义好IDL之后，服务端的代码可以利用框架提供的工具自动生成代码，业务服务提供方，只需要专注于业务接口的实现即可。本文部分摘自“架构师之路”。