RPC原理实现剖析

      最近对RPC的一些实现原理，以及一些RPC框架比较感兴趣。所以，抽时间想研究一下RPC中涉及到的一些技术实现，通讯、序列化和反序列化、动态代理、通讯协议（消息的编解码）。

      在一个针对阿里找招聘的群里，发现一些阿里的技术文档 ，故下载下来查看了一下。一种有一位大牛正好讲到了RPC调用的一些实现原理或者涉及到的技术。本人是做java开发的，这位大牛也是基于java的角度来做了一些原来的剖析。故在此记录一下，作为指导自己想重复造轮子想法的一些借鉴。也希望有这方面应用的同行给予指导。下面言归正传，深入到RPC涉及技术的一些记录。

RPC是什么？

RPC remote procedure call 远程过程或者方法调用，它是一种跨进程间的方法或者过程调用。让程序客户端像调用本地方法一样，调用远程服务端暴露的方法。其中，不乏业务异常或者调用的运行时异常导致的调用失败，或返回错误信息。

RPC的数据结构

引用阿里的那位牛人博客中的，RPC的数据结构主要包含以下几个方面：

• user
• user stub
• RPC-runtime
• server stub
• server

每一部分相信很多人都知道他们是干什么用的，在此我也不多废话。如果不了解，请自行百度。

RPC选型的几个重要指标

1. 性能指标
2. 是否需要支持跨语言平台
3. 内网开放还是公网开放
4. 开源PRC框架的质量、以及社区活跃度

这里多说两句，早前的一家公司 最开始用的是java RMI框架，这是java api自带的实现远程服务间调用的框架，其学习成本低、基于java语言，不能跨语言调用；

后来公司升级到了阿里的Dubbo框架，这是阿里开源的支持多种协议的一种远程服务间调用框架。其中实现了dubbo自己的协议还有thrift协议等等第三方的协议，还暴露了很多的extend point，方面企业自己实现扩展。

现在这家公司现在使用的是hessian基于二进制通讯协议的远程服务间调用框架，后期随着业务量的不断增加可能会迁移到thrift协议。

thrift大家也知道支持跨语言平台的远程服务调用，对于现在的大多数互联网公司，不管你是P2P或者O2O都是基于app作为主要交易手段的，所以实现跨语言平台的远程服务调用就是业务所必须。

RPC的功能目标

让构建分布式应用更容易，提供强大远程调用能力的前提下，不失本地调用的简洁性。（引自：http://blog.csdn.net/mindfloating/article/details/39474123）

RPC各个组件的职责

rpc server  提供服务的导出

rpc client   负责服务接口的代理导入

rpc proxy  服务接口的代理实现

rpc invoker 

客服端  负责编码信息和发送请求到服务端并等待结果返回

服务方  负责真正的服务接口实现的调用并返回调用结果

rpc protocol  负责消息的编解码

rpc connector 负责维持客户端和服务端的通道以及发送数据请求

rpc acceptor  负责解释客户方请求并返回结果

rpc processor  负责在服务方的控制调用过程，包括线程池、超时时间等

rpc channel  数据传输通道

具体的各部分对应于java的实现，请参考：http://blog.csdn.net/mindfloating/article/details/39474123，这位阿里人的博客