一、RPC框架
1、rpc简介
RPC（Remote Procedure Call，远程过程调用），它指的是通过网络调用另一台计算机上部署服务的技术。常见的rpc框架：Dubbo、Grpc、Thrift。
RMI
Java 原生就有一套远程调用框架叫做 RMI（Remote Method Invocation），它可以让 Java 程序通过网络调用另一台机器上的 Java 对象的方法。它是一种远程调用的方法。之所以 RMI 没有像 Dubbo、Grpc 一样大火，是因为它存在着一些缺陷：
RMI 使用专为 Java 远程对象定制的协议 JRMP（Java Remote Messaging Protocol）进行通信，这限制了它的通信双方只能是 Java 语言的程序，无法实现跨语言通信；
RMI 使用 Java 原生的对象序列化方式，生成的字节数组空间较大，效率很差。
Web Service
它也可以认为是 RPC 的一种实现方式。它的优势是使用 HTTP+SOAP 协议，保证了调用可以跨语言、跨平台。只要你支持 HTTP 协议，可以解析 XML，那么就能够使用 Web Service。在我看来，由于它使用 XML 封装数据，数据包大，性能还是比较差。
2、rpc调用过程
- 在一次 RPC 调用过程中，客户端首先会将调用的类名、方法名、参数名、参数值等信息，序列化成二进制流；
- 然后客户端将二进制流通过网络发送给服务端；
- 服务端接收到二进制流之后将它反序列化，得到需要调用的类名、方法名、参数名和参数值，再通过动态代理的方式调用对应的方法得到返回值；
- 服务端将返回值序列化，再通过网络发送给客户端；
- 客户端对结果反序列化之后，就可以得到调用的结果了。
3、rpc优化
网络传输
网络传输优化中，你首先要做的是选择一种高性能的 I/O 模型。所谓 I/O 模型，就是我们处理 I/O 的方式。而一般单次 I/O 请求会分为两个阶段：
-
等待资源的阶段：阻塞、非阻塞
-
使用资源阶段：同步、异步
将这两个阶段的四种处理方式做一些排列组合，再做一些补充，就得到了我们常见的五种 I/O 模型：
- 同步阻塞 I/O；
- 同步非阻塞 I/O；
- 同步多路 I/O 复用；
- 信号驱动 I/O；
- 异步 I/O。
这五种 I/O 模型中最被广泛使用的是多路 I/O 复用，Linux 系统中的 select、epoll 等系统调用都是支持多路 I/O 复用模型的，Java 中的高性能网络框架 Netty 默认也是使用这种模型。你可以选择它。
网络参数
Nagles算法： 如果是连续的小数据包，大小没有一个 MSS（Maximum SegmentSize，最大分段大小），并且还没有收到之前发送的数据包的 Ack 信息，那么这些小数据包就会在发送端暂存起来，直到小数据包累积到一个 MSS，或者收到一个 Ack 为止。这原本是为了减少不必要的网络传输，但是如果接收端开启了 DelayedACK（延迟 ACK 的发送，这样可以合并多个 ACK，提升网络传输效率），那就会发生发送端发送第一个数据包后接收端没有返回 ACK，这时发送端发送了第二个数据包，因为 Nagle 算法的存在，并且第一个发送包的 ACK 还没有返回，所以第二个包会暂存起来。而 DelayedACK 的超时时间默认是 40ms，所以一旦到了 40ms，接收端回给发送端 ACK，那么发送端才会发送第二个包，这样就增加了延迟。
解决的方式非常简单：只要在 Socket 上开启 tcp_nodelay 就好了，这个参数关闭了 Nagle 算法，这样发送端就不需要等到上一个发送包的 ACK 返回直接发送新的数据包就好了。这对于强网络交互的场景来说非常的适用，基本上，如果你要自己实现一套网络框架，tcp_nodelay 这个参数最好是要开启的。
序列化
一次 RPC 调用需要经历两次数据序列化的过程和两次数据反序列化的过程，可见它们对于 RPC 的性能影响是很大的，那么我们在选择序列化方式的时候需要考虑哪些因素呢？
- 性能，性能包括时间上的开销和空间上的开销，时间上的开销就是序列化和反序列化的速度，这是显而易见需要重点考虑的，而空间上的开销则是序列化后的二进制串的大小，过大的二进制串也会占据传输带宽影响传输效率。
- 兼容性，我们需要考虑的是它是否可以跨语言、跨平台，这一点也非常重要，因为一般的公司的技术体系都不是单一的，使用的语言也不是单一的，那么如果你的 RPC 框架中传输的数据只能被一种语言解析，这无疑限制了框架的使用。
- 扩展性也是一个需要考虑的重点问题。你想想，如果对象增加了一个字段就会造成传输协议的不兼容，导致服务调用失败，这会是多么可怕的事情。
综合上面的几个考虑点，在我看来，我们的序列化备选方案主要有以下几种：
- JSON，它起源于 JavaScript 是一种最广泛使用的序列化协议，它的优势简单易用，同时在性能上相比 XML 有比较大的优势。
- Thrift 和 Protobuf 都是需要引入 IDL（Interface description language）的，也就是需要按照约定的语法写一个 IDL 文件，然后通过特定的编译器将它转换成各语言对应的代码，从而实现跨语言的特点。Thrift 是 Facebook 开源的高性能的序列化协议，也是一个轻量级的 RPC 框架；Protobuf 是谷歌开源的序列化协议。它们的共同特点是无论在空间上还是时间上都有着很高的性能，缺点就是由于 IDL 存在带来一些使用上的不方便。
那么你要如何选择这几种序列化协议呢？这里我给你几点建议：
- 如果对于性能要求不高，在传输数据占用带宽不大的场景下可以使用 JSON 作为序列化协议；
- 如果对于性能要求比较高，那么使用 Thrift 或者 Protobuf 都可以。而 Thrift 提供了配套的 RPC 框架，所以想要一体化的解决方案，你可以优先考虑 Thrift；
- 在一些存储的场景下，比如说你的缓存中存储的数据占用空间较大，那么你可以考虑使用 Protobuf 替换 JSON 作为存储数据的序列化方式。
