1 参考文献
RPC框架：从原理到选型，一文带你搞懂RPC (qq.com)
2 应用场景
RPC是远程过程调用协议 多应用于分布式场景
有许多实现了此协议的框架 例如Dubbo框架 Thrift框架
具体的应用场景 部署在服务器1上的程序a 需要调用部署在服务器2上的程序b 的某个API 方法或者服务
由于两个程序并不共享同一台服务器上的物理地址 不能本地调用
且两个程序并没有发布在网络仓库中 不能以打包下载依赖的方式调用
但是其实分析 这种情况下 并不是非得把另一台机器上的代码克隆到本地服务器才能调用的 程序无非就是对象+方法 将a中提供的对象（数据）传入b的方法运行 得到副作用或者结果 再进行回传 即可
过程中需要先定位到设备 再定位到设备上运行的应用程序 及 调用的接口号
RPC即为数据对象经过特定的编码，使用某种通信协议，使用某种I/O进行网络通信的过程
遇到这种情况能 使用RPC协议 进行远程调用
3 个人思考与疑惑
其实结合了业务场景学习 理解技术要简单很多 也有助于框架的设计
我认为RPC协议实现的最关键是 传输数据的可靠性和传输效率
这两点均与计算机网络的各类协议和实现有关 而且也取决于对数据传输（序列化 反序列化）
传输的数据可能并不需要像web page一样显示 不需要遵从目前已有的应用层协议 （也可以自己定义一个rpc应用层协议）
还有一点就是 已知是分布式项目 那么必然有多个服务器上的应用可能同时请求一个接口， 如果不设计好必然会导致信息讹误
所以还有以下：
-
阻塞I/O（Blocking I/O）
-
轮询非阻塞I/O（Non-blocking I/O）
-
多路复用 I/O （Multiplexing I/O）
-
异步I/O（Asynchronous I/O）
（回忆以前学过的NIO AIO Netty等基础知识）
不过具体实现起来其实网络通信和序列化 反序列化并不是最复杂的
复杂的是接收到信息之后 如何进行进程之间的通讯 得到这个请求和执行
4 RPC特点
-
RPC是协议， 既然是协议就只是一套规范，具体的实现需要由遵从这套规范的框架完成
-
网络协议和网络IO模型对其透明 与底层传输的网络协议无关 具体是TCP/IP的什么协议簇都无关
（难道不需要通过网络协议保证传输的安全性和可靠性吗）
- 信息格式对其透明 在数据传输过程中需要序列化和反序列化 之前也也讨论过 有多种序列化方式
- RPC的实现不应该与信息格式有关 可以按需选择
- 语言无关性 不论是用什么语言编写的应用程序 依照RPC协议远端调用时都应该可行
5 涉及技术
1）反射技术
如何准确的定位到服务器上的进程和应用具体的方法或接口
还是离不开反射技术 框架不可能离开反射技术
2）代理技术
使用了代理技术 实现关键步骤 封装通信细节才能让用户像以本地调用方式调用远程服务
需要实现RPCProxyClient代理类，代理类的invoke方法中封装了与远端服务通信的细节, 在执行该方法的前后对数据进行封装和解码等，让用于感觉就像是直接调用该方法一样，殊不知，我们对方法前后都经过了复杂的处理。
3）序列化和反序列化技术
在上一节已经介绍过并且借助框架实现了protocol buffer序列化反序列化操作
同时前文提到了RPC协议应该是信息编码透明的 选择怎样的序列化技术取决于系统的具体需求
客户端的请求消息结构一般需要包括以下内容：
- 接口名称：在我们的例子里接口名是“HelloWorldService”，如果不传，服务端就不知道调用哪个接口了；
- 方法名：一个接口内可能有很多方法，如果不传方法名服务端也就不知道调用哪个方法；
- 参数类型&参数值：参数类型有很多，比如有int、long、double、string、map、list以及相应的参数值；
- 超时时间 + requestID（标识唯一请求id）
服务端返回的消息结构一般包括以下内容：
- 状态code + 返回值
- requestID
4）注册中心
可以直接使用现存的注册中心 （例如java使用的zookeeper） 对任务进行注册 管理 和调度
6 疑惑
即使是知道RPC实现远程过程调度一定要使用上述的技术点 但是光靠这几点没有能够理清楚整个流程的实现
还留有的空白有：
网络层究竟如何实现的
感觉还得是继续了解注册中心 的 技术 这里还不是很清楚
