浅谈RPC

从我们学习编程开始，就对『LPC』（local Procedure Call）十分熟悉，而PRC就是类似LPC的一种调用机制。在服务化、微服务化逐渐成为大中型分布式系统架构的主流方式的过程中，RPC作为基本通用服务成为系统标配的一部分。

RPC 的全称是 Remote Procedure Call 是一种进程间通信方式。它允许程序调用另一个地址空间（通常是共享网络的另一台机器上）的过程或函数，而不用程序员显式编码这个远程调用的细节。即程序员无论是调用本地的还是远程的，本质上编写的调用代码基本相同。RPC的概念源于Bruce Jay Nelson的论文Implementing Remote Procedure Calls，有兴趣的可以阅读一下。

RPC有许多成熟、开源的实现方案，这些方案均由大厂负责设计、开发，各有优点。
grpc（google）https://github.com/grpc/grpc
thrift（facebook）：独特的序列化格式和IDL，支持很多编程语言。thrift的代码看似分层很清楚，client、server选择很多，但没有一个足够通用，每个server实现都只能解决很小一块场景，每个client都线程不安全。实际使用中非常麻烦。thrift的代码质量也比较差，接口和生成的代码都比较乱。https://github.com/apache/thrift
dubbo（alibaba）https://github.com/alibaba/dubbo
sofa-pbrpc（baidu）：百度PS基于boost::asio和protobuf实现的RPC框架，这个库代码工整，接口清晰，支持同步和异步。sofa-pbrpc存在产品线自研框架的鲜明特点：不支持内部其他协议，对名字服务、负载均衡、服务认证、连接方式等多样化的需求的抽象不够一般化。https://github.com/baidu/sofa...
baidu-rpc（baidu）提供稳定的RPC框架；适用各类业务场景，提供优秀的延时，吞吐，并发度，具备优秀的多核扩展性；接口易懂，用户体验佳。有完备的调试和运维接口（HTTP）。https://github.com/brpc/brpc。

RPC原理和流程

1）服务消费方（client）调用以本地调用方式调用服务；
2）client stub接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体；
3）client stub找到服务地址，并将消息发送到服务端；
4）server stub收到消息后进行解码；
5）server stub根据解码结果调用本地的服务；
6）本地服务执行并将结果返回给server stub；
7）server stub将返回结果打包成消息并发送至消费方；
8）client stub接收到消息，并进行解码；
9）服务消费方得到最终结果。

RPC中需求关注的几个核心问题
1）序列化
接口定义方面需要关注客户端和服务端各需要哪些数据来确保调用的正常返回、调用次序和调用结果正确表示。
调用方：接口名称、方法名、参数类型及参数值、超时时间、requestID，标识唯一请求id。
返回方：返回值、状态码、requestID
传输协议方面现在最通用的方式是使用protobuf，能够有效对数据进行压缩并提供高效的转换效率。另外常用的协议还包括idl，百度内部使用nshead+mcpack等，facebook自定义了格式化方法。
2）通信模型：主流RPC框架都提供BIO+NIO，提供同步、异步通信机制
3）使用zookeeper、bns服务提供服务发现。
4）提供接口能够让用户自定义负载均衡算法。
5）提供策略框架提供业务策略处理能力。

参考资料：
1、http://birrell.org/andrew/pap...
2、http://blog.jobbole.com/92290/
3、http://blog.csdn.net/mindfloa...、http://blog.csdn.net/mindfloating/article/details/39474123