一、概要

RPC作用？
让不同服务间调用方法像同一服务间调用本地方法一样
在这里插入图片描述

二、RPC组成部分

在这里插入图片描述

Client：RPC协议调用方
Server：远程服务方法的具体实现
Stub/Proxy：RPC代理存在于客户端，因为要实现客户端对RPC框架“透明”调用，那么客户端不可能自行去管理消息格式、不可能自己去管理网络传输协议，也不可能自己去判断调用过程是否有异常。这一切工作在客户端都是交给RPC框架中的“代理”层来处理的。
Message Protocol：两端都能识别的、共同约定的消息格式。RPC的消息管理层对网络传输所承载的消息信息进行编码和解码操作。
Transfer/Network Protocol：传输协议层负责管理RPC框架所使用的网络协议、网络IO模型。传输层还需要统一RPC客户端和RPC服务端所使用的IO模型。例如Hessian的传输协议基于HTTP（应用层协议）；而Thrift的传输协议基于TCP（传输层协议）。
Selector/Processor：存在于RPC服务端，用于服务端的某一个RPC接口实现的特性（它并不知道自己是一个将要被RPC提供给第三方系统调用的服务）。所以在RPC框架中应该有一种“负责执行RPC接口实现”的角色。包括：管理RPC接口的注册、判断客户端的请求权限、控制接口实现类的执行在内的各种工作。
IDL：跨语言RPC框架一定会有IDL部分的存在。为了能找到一个各种语言能够理解的消息结构、接口定义的描述形式。

三、影响RPC框架性能的因素

网络IO模型：在高并发状态下RPC服务器性能会有很大差别，尤其是单位处理性能下内存、CPU资源的使用率。
基于的网络协议：可以采用应用层协议，也可以采用TCP协议，对工作性能有影响但不大。
消息封装格式：是目前RPC协议性能差异最重要的原因。要考虑的问题：消息的易读性、描述单位内容时的消息体大小、编码难度、解码难度、解决半包/粘包问题的难易度。
Schema 和序列化（Schema & Data Serialization）：
序列化和反序列化，是对象到二进制数据的转换，程序是可以理解对象的，对象一般含有 schema 或者结构，基于这些语义来做特定的业务逻辑处理。
考察一个序列化框架一般会关注以下几点：
- Encoding format 。是 human readable（是否能直观看懂 json）还是 binary(二进制)。
- Schema declaration 。也叫作契约声明，基于 IDL，比如 Protocol Buffers/Thrift，还是自描述的，比如 JSON、XML。另外还需要看是否是强类型的。
- 语言平台的中立性 。比如 Java 的 Native Serialization 就只能自己玩，而 Protocol Buffers 可以跨各种语言和平台。
- 新老契约的兼容性 。比如 IDL 加了一个字段，老数据是否还可以反序列化成功。
- 和压缩算法的契合度 。跑 benchmark (基准)和实际应用都会结合各种压缩算法，例如 gzip、snappy。
- 性能。这是最重要的，序列化、反序列化的时间，序列化后数据的字节大小是考察重点。
  序列化方式非常多，常见的有 Protocol Buffers， Avro，Thrift，XML，JSON，MessagePack，Kyro，Hessian，Protostuff，Java Native Serialize，FST 。
实现的服务处理管理方式：您可以让RPC的Selector/Processor使用单个线程运行服务的具体实现（这意味着上一个客户端的请求没有处理完，下一个客户端的请求就需要等待）、您也可以为每一个RPC具体服务的实现开启一个独立的线程运行（可以一次处理多个请求，但是操作系统对于“可运行的最大线程数”是有限制的）、您也可以线程池来运行RPC具体的服务实现（目前看来，在单个服务节点的情况下，这种方式是比较好的）、您还可以通过注册代理的方式让多个服务节点来运行具体的RPC服务实现。