共计 3055 个字符，预计需要花费 8 分钟才能阅读完成。
发现一个不错的，工业级的，高性能 RPC 框架 srpc。
（1）RPC 简介；
（2）行业常见 RPC 框架；
（3）srpc 特点；
（4）srpc 上手指南，demo 示例；
（5）srpc 架构设计；
（6）srpc 相关资料与资源；
什么是 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 等； 画外音：因此，才能和其他 RPC 框架无缝互通。
（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 之后，服务端的代码可以利用框架提供的工具自动生成代码，业务服务提供方，只需要专注于业务接口的实现即可，你说帅气不帅气？画外音：具体的生成工具，与生成方法，请参看 git 上的文档。
最后，我觉得这个 srpc 最帅气的地方之一，就是：开源版本即线上工程版本，更新快，issue 响应快，并且文档真的很全！画外音：不少大公司，公司内部的版本和开源的版本是两套代码，开源版本没有文档，KPI 完成之后，开源就没人维护了，结果坑了一大票人。
文章的结尾，分享一些学习资源吧。
项目地址：https://github.com/sogou/srpc
项目 demo：
项目架构设计：
项目地址：https://github.com/sogou/srpc Star：800+
