又发现一个不错的，工业级的，高性能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：
README_cn.md
项目架构设计：
docs/wiki.md
作者知乎：
https://www.zhihu.com/people/liyingxin1412/posts
作者联系方式：
发现bug可以随时提交给她，响应绝对快速。
项目地址：https://github.com/sogou/srpc
Star：800
画外音：srpc还有很多优秀的设计，等待大家去挖掘。
末了，希望这个1W行代码的RPC框架，能够帮助大家更透彻的了解RPC的底层原理。
