深入理解 RPC来源：https://blog.csdn.net/fangmeng1997/category_10396482.html
第一章 核心原理1. 什么是 RPC？RPC 的全称是 Remote Procedure Call，即远程过程调用。简单解读字面上的意思，远程肯定是指要跨机器而非本机，所以需要用到网络编程才能实现，但是不是只要通过网络通信访问到另一台机器的应用程序，就可以称之为 RPC 调用了？显然并不够。
我理解的 RPC 是帮助我们屏蔽网络编程细节，实现调用远程方法就跟调用本地一样的体验，我们不需要因为这个方法是远程调用就需要编写很多与业务无关的代码。
这就好比建在小河上的桥一样连接着河的两岸，如果没有小桥，我们需要通过划船、绕道等其他方式才能到达对面，但是有了小桥之后，我们就能像在路面上一样行走到达对面，并且跟在路面上行走的体验没有区别。因此，RPC 的作用就是体现在这样两个方面：
屏蔽远程调用跟本地调用的区别，让我们感觉就是调用项目内的方法；
隐藏底层网络通信的复杂性，让我们更专注于业务逻辑。
2. RPC 通信流程理解了什么是 RPC，接下来我们讲下 RPC 框架的通信流程。
如前面所讲，RPC 能帮助我们的应用透明地完成远程调用，发起调用请求的那一方叫做调用方，被调用的一方叫做服务提供方。为了实现这个的目标，我们就需要在 RPC 框架里面对整个通信细节进行封装，那一个完整的RPC 会涉及到哪些步骤呢？
我们已经知道 RPC 是一个远程调用，那肯定就需要通过网络来传输数据，并且 RPC 常用于业务系统之间的数据交互，需要保证其可靠性，所以 RPC 一般默认采用 TCP 来传输。我们常用的 HTTP 协议也是建立在 TCP 之上的。
网络传输的数据必须是二进制数据，但调用方请求的出入参数都是对象。对象是肯定没法直接在网络中传输的，需要提前把它转成可传输的二进制，并且要求转换算法是可逆的，这个过程我们一般叫做“序列化”。
调用方持续地把请求参数序列化成二进制后，经过 TCP 传输给了服务提供方。服务提供方从 TCP 通道里面收到二进制数据，那如何知道一个请求的数据到哪里结束，是一个什么类型的请求呢？
在这里我们可以想想高速公路，它上面有很多出口，为了让司机清楚地知道从哪里出去，管理部门会在路上建立很多指示牌，并在指示牌上标明下一个出口是哪里、还有多远。那回到数据包识别这个场景，我们是不是也可以建立一些“指示牌”，并在上面标明数据包的类型和长度，这样就可以正确的解析数据了。确实可以，并且我们把数据格式的约定内容叫做“协议”。大多数的协议会分成两部分，分别是数据头和消息体。数据头一般用于身份识别，包括协议标识、数据大小、请求类型、序列化类型等信息；消息体主要是请求的业务参数信息和扩展属性等。
根据协议格式，服务提供方就可以正确地从二进制数据中分割出不同的请求来，同时根据请求类型和序列化类型，把二进制的消息体逆向还原成请求对象。这个过程叫作“反序列化”。
服务提供方再根据反序列化出来的请求对象找到对应的实现类，完成真正的方法调用，然后把执行结果序列化后，回写到对应的 TCP 通道里面。调用方获取到应答的数据包后，再反序列化成应答对象，这样调用方就完成了一次 RPC 调用。
那上述几个流程就组成了一个完整的 RPC 吗？
在我看来，还缺点东西。因为对于研发人员来说，这样做要掌握太多的 RPC 底层细节，需要手动写代码去构造请求、调用序列化，并进行网络调用，整个 API 非常不友好。
那我们有什么办法来简化 API，屏蔽掉 RPC 细节，让使用方只需要关注业务接口，像调用本地一样来调用远程呢？
如果你了解 Spring，一定对其 AOP 技术很佩服，其核心是采用动态代理的技术，通过字节码增强对方法进行拦截增强，以便于增加需要的额外处理逻辑。其实这个技术也可以应用到 RPC 场景来解决我们刚才面临的问题。
由服务提供者给出业务接口声明，在调用方的程序里面，RPC 框架根据调用的服务接口提前生成动态代理实现类，并通过依赖注入等技术注入到声明了该接口的相关业务逻辑里面。该代理实现类会拦截所有的方法调用，在提供的方法处理逻辑里面完成一整套的远程调用，并把远程调用结果返回给调用方，这样调用方在调用远程方法的时候就获得了像调用本地接口一样的体验。
到这里，一个简单版本的 RPC 框架就实现了。上述流程如下图：
3. RPC 在架构中的位置围绕 RPC 我们讲了这么多，那 RPC 在架构中究竟处于什么位置呢？
如刚才所讲，RPC 是解决应用间通信的一种方式，而无论是在一个大型的分布式应用系统还是中小型系统中，应用架构最终都会从“单体”演进成“微服务化”，整个应用系统会被拆分为多个不同功能的应用，并将它们部署在不同的服务器中，而应用之间会通过 RPC 进行通信，可以说 RPC 对应的是整个分布式应用系统，就像是“经络”一样的存在。
那么如果没有 RPC，我们现实中的开发过程是怎样的一个体验呢？
所有的功能代码都会被我们堆砌在一个大项目中，开发过程中你可能要改一行代码，但改完后编译会花掉你 2 分钟，编译完想运行起来验证下结果可能要 5 分钟，是不是很酸爽？更难受的是在人数比较多的团队里面，多人协同开发的时候，如果团队其他人把接口定义改了，你连编译通过的机会都没有，系统直接报错，从而导致整个团队的开发效率都会非常低下。而且当我们准备要上线发版本的时候，QA 也很难评估这次的测试范围，为了保险起见我们只能把所有的功能进行回归测试，这样会导致我们上线新功能的整体周期都特别长。
无论你是研发还是架构师，我相信这种系统架构我们肯定都不能接受，那怎么才能解决这个问题呢？
我们首先都会想到可以采用“分而治之”的思想来进行拆分，但是拆分完的系统怎么保持跟未拆分前的调用方式一样呢？我们总不能因为架构升级，就把所有的代码都推倒重写一遍吧。
RPC 框架能够帮助我们解决系统拆分后的通信问题，并且能让我们像调用本地一样去调用远程方法。利用 RPC 我们不仅可以很方便地将应用架构从“单体”演进成“微服务化”，而且还能解决实际开发过程中的效率低下、系统耦合等问题，这样可以使得我们的系统架构整体清晰、健壮，应用可运维度增强。
当然 RPC 不仅可以用来解决通信问题，它还被用在了很多其他场景，比如：MQ、分布式缓存、数据库等。比如下面的应用架构图：
在这个应用中，使用了 MQ 来处理异步流程、Redis 缓存热点数据、MySQL 持久化数据，还有就是在系统中调用另外一个业务系统的接口，对我的应用来说这些都是属于 RPC调用，而 MQ、MySQL 持久化的数据也会存在于一个分布式文件系统中，他们之间的调用也是需要用 RPC 来完成数据交互的。
由此可见，RPC 确实是我们日常开发中经常接触的东西，只是被包装成了各种框架，导致我们很少意识到这就是 RPC，让 RPC 变成了我们最“熟悉的陌生人”。现在，回过头想想，我说 RPC 是整个应用系统的“经络”，这不为过吧？我们真的很有必要学好 RPC，不仅因为 RPC 是构建复杂系统的基石，还是提升自身认知的利器。
4. 总结本篇博客讲了下 RPC 的原理，RPC 就是提供一种透明调用机制，让使用者不必显式地区分本地调用和远程调用。RPC 虽然可以帮助开发者屏蔽远程调用跟本地调用的区别，但毕竟涉及到远程网络通信，所以这里还是有很多使用上的区别，比如：
调用过程中超时了怎么处理业务？
什么场景下最适合使用 RPC？
什么时候才需要考虑开启压缩？
无论你是一个初级开发者还是高级开发者，RPC 都应该是你日常开发过程中绕不开的一个话题，所以作为软件开发者的我们，真的很有必要详细地了解 RPC 实现细节。只有这样，才能帮助我们更好地在日常工作中使用 RPC。
第二章 协议1. 协议一提到协议，你最先想到的可能是 TCP 协议、UDP 协议等等，并且这些网络传输协议的实现有点晦涩难懂。虽然在 RPC 中我们也会用到这些协议，但这些协议更多的是对我们上层应用是透明的，我们 RPC 在使用过程中并不太需要关注他们的细节。那 RPC 协议到底是什么呢？
可能我举个例子，你立马就明白了。HTTP 协议是不是很熟悉（本博客里面所说的 HTTP 默认都是 1.X）， 这应该是我们日常工作中用得最频繁的协议了，每天打开浏览器浏览的网页就是使用的 HTTP 协议。那 HTTP 协议跟 RPC 协议又有什么关系呢？看起来他俩好像不搭边，但他们有一个共性就是都属于应用层协议。
所以我们要讲的 RPC 协议就是围绕应用层协议展开的。我们可以先了解下 HTTP 协议，我们先看看它的协议格式是什么样子的。回想一下我们在浏览器里面输入一个 URL 会发生什么？抛开 DNS 解析暂且不谈，浏览器收到命令后会封装一个请求，并把请求发送到 DNS 解析出来的 IP 上，通过抓包工具我们可以抓到请求的数据包，如下图所示：
2. 协议的作用看完 HTTP 协议之后，你可能会有一个疑问，我们为什么需要协议这个东西呢？没有协议就不能通信吗？
我们知道只有二进制才能在网络中传输，所以 RPC 请求在发送到网络中之前，他需要把方法调用的请求参数转成二进制；转成二进制后，写入本地 Socket 中，然后被网卡发送到网络设备中。
但在传输过程中，RPC 并不会把请求参数的所有二进制数据整体一下子发送到对端机器上，中间可能会拆分成好几个数据包，也可能会合并其他请求的数据包（合并的前提是同一个 TCP 连接上的数据），至于怎么拆分合并，这其中的细节会涉及到系统参数配置和 TCP 窗口大小。对于服务提供方应用来说，他会从 TCP 通道里面收到很多的二进制数据，那这时候怎么识别出哪些二进制是第一个请求的呢？
这就好比让你读一篇没有标点符号的文章，你要怎么识别出每一句话到哪里结束呢？很简单啊，我们加上标点，完成断句就好了。
同理在 RPC 传输数据的时候，为了能准确地“断句”，我们也必须在应用发送请求的数据包里面加入“句号”，这样才能帮我们的接收方应用从数据流里面分割出正确的数据。这个数据包里面的句号就是消息的边界，用于标示请求数据的结束位置。举个具体例子，调用方发送 AB、CD、EF 3 个消息，如果没有边界的话，接收端就可能收到 ABCDEF 或者ABC、DEF 这样的消息，这就会导致接收的语义跟发送的时候不一致了。
所以呢，为了避免语义不一致的事情发生，我们就需要在发送请求的时候设定一个边界，然后在收到请求的时候按照这个设定的边界进行数据分割。这个边界语义的表达，就是我们所说的协议。
3. 如何设计协议？理解了协议的作用，我们再来看看在 RPC 里面是怎么设计协议的。可能你会问：“前面你不是说了 HTTP 协议跟 RPC 都属于应用层协议，那有了现成的 HTTP 协议，为啥不直接用，还要为 RPC 设计私有协议呢？”
这还要从 RPC 的作用说起，相对于 HTTP 的用处，RPC 更多的是负责应用间的通信，所以性能要求相对更高。但 HTTP 协议的数据包大小相对请求数据本身要大很多，又需要加入很多无用的内容，比如换行符号、回车符等；还有一个更重要的原因是，HTTP 协议属于无状态协议，客户端无法对请求和响应进行关联，每次请求都需要重新建立连接，响应完成后再关闭连接。因此，对于要求高性能的 RPC 来说，HTTP 协议基本很难满足需求，所以 RPC 会选择设计更紧凑的私有协议。
那怎么设计一个私有 RPC 协议呢？
在设计协议前，我们先梳理下要完成 RPC 通信的时候，在协议里面需要放哪些内容。
首先要想到的就是我们前面说的消息边界了，但 RPC 每次发请求发的大小都是不固定的，所以我们的协议必须能让接收方正确地读出不定长的内容。我们可以先固定一个长度（比如4 个字节）用来保存整个请求数据大小，这样收到数据的时候，我们先读取固定长度的位置里面的值，值的大小就代表协议体的长度，接着再根据值的大小来读取协议体的数据，整个协议可以设计成这样：
但上面这种协议，只实现了正确的断句效果，在 RPC 里面还行不通。因为对于服务提供方来说，他是不知道这个协议体里面的二进制数据是通过哪种序列化方式生成的。如果不能知道调用方用的序列化方式，即使服务提供方还原出了正确的语义，也并不能把二进制还原成对象，那服务提供方收到这个数据后也就不能完成调用了。因此我们需要把序列化方式单独拿出来，类似协议长度一样用固定的长度存放，这些需要固定长度存放的参数我们可以统称为“协议头”，这样整个协议就会拆分成两部分：协议头和协议体。
在协议头里面，我们除了会放协议长度、序列化方式，还会放一些像协议标示、消息 ID、消息类型这样的参数，而协议体一般只放请求接口方法、请求的业务参数值和一些扩展属性。这样一个完整的 RPC 协议大概就出来了，协议头是由一堆固定的长度参数组成，而协议体是根据请求接口和参数构造的，长度属于可变的，具体协议如下图所示：
可扩展的协议
刚才讲的协议属于定长协议头，那也就是说往后就不能再往协议头里加新参数了，如果加参数就会导致线上兼容问题。举个具体例子，假设你设计了一个 88Bit 的协议头，其中协议长度占用 32bit，然后你为了加入新功能，在协议头里面加了 2bit，并且放到协议头的最后。升级后的应用，会用新的协议发出请求，然而没有升级的应用收到的请求后，还是按照 88bit 读取协议头，新加的 2 个 bit 会当作协议体前 2 个 bit 数据读出来，但原本的协议体最后 2 个 bit 会被丢弃了，这样就会导致协议体的数据是错的。
可能你会想：“那我把参数加在不定长的协议体里面行不行？而且刚才你也说了，协议体里面会放一些扩展属性。”
没错，协议体里面是可以加新的参数，但这里有一个关键点，就是协议体里面的内容都是经过序列化出来的，也就是说你要获取到你参数的值，就必须把整个协议体里面的数据经过反序列化出来。但在某些场景下，这样做的代价有点高啊！
比如说，服务提供方收到一个过期请求，这个过期是说服务提供方收到的这个请求的时间大于调用方发送的时间和配置的超时时间，既然已经过期，就没有必要接着处理，直接返回一个超时就好了。那要实现这个功能，就要在协议里面传递这个配置的超时时间，那如果之前协议里面没有加超时时间参数的话，我们现在把这个超时时间加到协议体里面是不是就有点重了呢？显然，会加重 CPU 的消耗。
所以为了保证能平滑地升级改造前后的协议，我们有必要设计一种支持可扩展的协议。其关键在于让协议头支持可扩展，扩展后协议头的长度就不能定长了。那要实现读取不定长的协议头里面的内容，在这之前肯定需要一个固定的地方读取长度，所以我们需要一个固定的写入协议头的长度。整体协议就变成了三部分内容：协议头固定部分、协议头扩展部分、协议体内容，前两部分我们还是可以统称为“协议头”，具体协议如下：
最后，我想说，设计一个简单的 RPC 协议并不难，难的就是怎么去设计一个可“升级”的协议。不仅要让我们在扩展新特性的时候能做到向下兼容，而且要尽可能地减少资源损耗，所以我们协议的结构不仅要支持协议体的扩展，还要做到协议头也能扩展。
4. 总结我们人类区别于其他动物的一个很大原因，就是我们能够通过语言去沟通，用文字去沉淀文明，从而让我们能站在巨人的肩膀上成长，但为了保证我们记录的文字能够被其他人理解，我们必须通过符号去实现断句，否则就可能导致文字的意义被曲解，甚至闹出笑话。
在 RPC 里面，协议的作用就类似于文字中的符号，作为应用拆解请求消息的边界，保证二进制数据经过网络传输后，还能被正确地还原语义，避免调用方跟被调用方之间的“鸡同鸭讲”。
但我们在设计协议的时候，也不能只单纯考虑满足目前功能，还应该从更高的层次出发。就好比我们设计系统架构一样，我们需要保证设计出来的系统能够能很好地扩展，支持新增功能。
第三章 序列化1. 为什么需要序列化？首先，我们得知道什么是序列化与反序列化。
我们先回顾下RPC通信的流程：
网络传输的数据必须是二进制数据，但调用方请求的出入参数都是对象。对象是不能直接在网络中传输的，所以我们需要提前把它转成可传输的二进制，并且要求转换算法是可逆的，这个过程我们一般叫做“序列化”。这时，服务提供方就可以正确地从二进制数据中分割出不同的请求，同时根据请求类型和序列化类型，把二进制的消息体逆向还原成请求对象，这个过程我们称之为“反序列化”。
这两个过程如下图所示：
总结来说，序列化就是将对象转换成二进制数据的过程，而反序列就是反过来将二进制转换为对象的过程。
那么 RPC 框架为什么需要序列化呢？还是请你回想下 RPC 的通信流程：
不妨借用个例子帮助你理解，比如发快递，我们要发一个需要自行组装的物件。发件人发之前，会把物件拆开装箱，这就好比序列化；这时候快递员来了，不能磕碰呀，那就要打包，这就好比将序列化后的数据进行编码，封装成一个固定格式的协议；过了两天，收件人收到包裹了，就会拆箱将物件拼接好，这就好比是协议解码和反序列化。
所以现在你清楚了吗？因为网络传输的数据必须是二进制数据，所以在 RPC 调用中，对入参对象与返回值对象进行序列化与反序列化是一个必须的过程。
2. 有哪些常用的序列化？那这么看来，你会不会觉得这个过程很简单呢？实则不然，很复杂。我们可以先看看都有哪些常用的序列化，下面我来简单地介绍下几种常用的序列化方式。
JDK 原生序列化如果你会使用 Java 语言开发，那么你一定知道 JDK 原生的序列化，下面是 JDK 序列化的一个例子：
1234567891011121314151617181920212223242526272829303132333435363738import java.io.*;public class Student implements Serializable { private int no; //学号 private String name; //姓名 public int getNo() { return no; } public void setNo(int no) { this.no = no; } public String getName() { return name; } public void setName(String name) { this.name = name; } @Override public String toString() { return "Student{" + "no=" + no + ", name='" + name + '\'' + '}'; } public static void main(String[] args) throws Exception { String home = System.getProperty("user.home"); String basePath = home + "/Desktop"; FileOutputStream fos = new FileOutputStream(basePath + "student.dat"); Student student = new Student(); student.setNo(100); student.setName("TEST_STUDENT"); ObjectOutputStream oos = new ObjectOutputStream(fos); oos.writeObject(student); oos.flush(); oos.close(); FileInputStream fis = new FileInputStream(basePath + "student.dat"); ObjectInputStream ois = new ObjectInputStream(fis); Student deStudent = (Student) ois.readObject(); ois.close(); System.out.println(deStudent); }}
我们可以看到，JDK 自带的序列化机制对使用者而言是非常简单的。序列化具体的实现是由 ObjectOutputStream 完成的，而反序列化的具体实现是由 ObjectInputStream 完成的。
那么 JDK 的序列化过程是怎样完成的呢？我们看下下面这张图：
序列化过程就是在读取对象数据的时候，不断加入一些特殊分隔符，这些特殊分隔符用于在反序列化过程中截断用。
头部数据用来声明序列化协议、序列化版本，用于高低版本向后兼容
对象数据主要包括类名、签名、属性名、属性类型及属性值，当然还有开头结尾等数据，除了属性值属于真正的对象值，其他都是为了反序列化用的元数据
存在对象引用、继承的情况下，就是递归遍历“写对象”逻辑
实际上任何一种序列化框架，核心思想就是设计一种序列化协议，将对象的类型、属性类型、属性值一一按照固定的格式写到二进制字节流中来完成序列化，再按照固定的格式一一读出对象的类型、属性类型、属性值，通过这些信息重新创建出一个新的对象，来完成反序列化。
JSON 序列化JSON 可能是我们最熟悉的一种序列化格式了，JSON 是典型的 Key-Value 方式，没有数据类型，是一种文本型序列化框架，JSON 的具体格式和特性，网上相关的资料非常多，这里就不再介绍了。
他在应用上还是很广泛的，无论是前台 Web 用 Ajax 调用、用磁盘存储文本类型的数据，还是基于 HTTP 协议的 RPC 框架通信，都会选择 JSON 格式。
但用 JSON 进行序列化有这样两个问题，你需要格外注意：
JSON 进行序列化的额外空间开销比较大，对于大数据量服务这意味着需要巨大的内存和磁盘开销；
JSON 没有类型，但像 Java 这种强类型语言，需要通过反射统一解决，所以性能不会太好。
所以如果 RPC 框架选用 JSON 序列化，服务提供者与服务调用者之间传输的数据量要相对较小，否则将严重影响性能。
Hessian 序列化Hessian 是动态类型、二进制、紧凑的，并且可跨语言移植的一种序列化框架。Hessian 协议要比 JDK、JSON 更加紧凑，性能上要比 JDK、JSON 序列化高效很多，而且生成的字节数也更小。
使用代码示例如下：
12345678910111213141516Student student = new Student();student.setNo(101);student.setName("HESSIAN");//把student对象转化为byte数组ByteArrayOutputStream bos = new ByteArrayOutputStream();Hessian2Output output = new Hessian2Output(bos);output.writeObject(student);output.flushBuffer();byte[] data = bos.toByteArray();bos.close();//把刚才序列化出来的byte数组转化为student对象ByteArrayInputStream bis = new ByteArrayInputStream(data);Hessian2Input input = new Hessian2Input(bis);Student deStudent = (Student) input.readObject();input.close();System.out.println(deStudent);
相对于 JDK、JSON，由于 Hessian 更加高效，生成的字节数更小，有非常好的兼容性和稳定性，所以 Hessian 更加适合作为 RPC 框架远程通信的序列化协议。
但 Hessian 本身也有问题，官方版本对 Java 里面一些常见对象的类型不支持，比如：
Linked 系列，LinkedHashMap、LinkedHashSet 等，但是可以通过扩展CollectionDeserializer 类修复；
Locale 类，可以通过扩展 ContextSerializerFactory 类修复；
Byte/Short 反序列化的时候变成 Integer。
以上这些情况，你在实践时需要格外注意。
Protobuf 序列化Protobuf 是 Google 公司内部的混合语言数据标准，是一种轻便、高效的结构化数据存储格式，可以用于结构化数据序列化，支持 Java、Python、C++、Go 等语言。Protobuf使用的时候需要定义 IDL（Interface description language），然后使用不同语言的 IDL编译器，生成序列化工具类，它的优点是：
序列化后体积相比 JSON、Hessian 小很多；
IDL 能清晰地描述语义，所以足以帮助并保证应用程序之间的类型不会丢失，无需类似XML 解析器；
序列化反序列化速度很快，不需要通过反射获取类型；
消息格式升级和兼容性不错，可以做到向后兼容。
使用代码示例如下：
12345678910111213141516171819202122232425/*** // IDL 文件格式* synax = "proto3";* option java_package = "com.test";* option java_outer_classname = "StudentProtobuf"; ** message StudentMsg {* //序号* int32 no = 1;* //姓名* string name = 2;* * }**/StudentProtobuf.StudentMsg.Builder builder = StudentProtobuf.StudentMsg.newBuilder();builder.setNo(103);builder.setName("protobuf");//把student对象转化为byte数组StudentProtobuf.StudentMsg msg = builder.build();byte[] data = msg.toByteArray();//把刚才序列化出来的byte数组转化为student对象StudentProtobuf.StudentMsg deStudent = StudentProtobuf.StudentMsg.parseFrom(data);System.out.println(deStudent);
Protobuf 非常高效，但是对于具有反射和动态能力的语言来说，这样用起来很费劲，这一点就不如 Hessian，比如用 Java 的话，这个预编译过程不是必须的，可以考虑使用 Protostuff。
Protostuff 不需要依赖 IDL 文件，可以直接对 Java 领域对象进行反 / 序列化操作，在效率上跟 Protobuf 差不多，生成的二进制格式和 Protobuf 是完全相同的，可以说是一个 Java版本的 Protobuf 序列化框架。但在使用过程中，我遇到过一些不支持的情况，也同步给你：
不支持 null；
ProtoStuff 不支持单纯的 Map、List 集合对象，需要包在对象里面。
3. RPC 框架中如何选择序列化？我刚刚简单地介绍了几种最常见的序列化协议，其实远不止这几种，还有 Message pack、kryo 等。那么面对这么多的序列化协议，在RPC 框架中我们该如何选择呢？
首先你可能想到的是性能和效率，不错，这的确是一个非常值得参考的因素。我刚才讲过，序列化与反序列化过程是 RPC 调用的一个必须过程，那么序列化与反序列化的性能和效率势必将直接关系到 RPC 框架整体的性能和效率。
那除了这点，你还想到了什么？
对，还有空间开销，也就是序列化之后的二进制数据的体积大小。序列化后的字节数据体积越小，网络传输的数据量就越小，传输数据的速度也就越快，由于 RPC 是远程调用，那么网络传输的速度将直接关系到请求响应的耗时。
现在请你再想想，还有什么因素可以影响到我们的选择？
没错，就是序列化协议的通用性和兼容性。在 RPC 的运营中，序列化问题恐怕是我碰到的和解答过的最多的问题了，经常有业务会向我反馈这个问题，比如某个类型为集合类的入参服务调用者不能解析了，服务提供方将入参类加一个属性之后服务调用方不能正常调用，升级了 RPC 版本后发起调用时报序列化异常了…
在序列化的选择上，与序列化协议的效率、性能、序列化协议后的体积相比，其通用性和兼容性的优先级会更高，因为他是会直接关系到服务调用的稳定性和可用率的，对于服务的性能来说，服务的可靠性显然更加重要。我们更加看重这种序列化协议在版本升级后的兼容性是否很好，是否支持更多的对象类型，是否是跨平台、跨语言的，是否有很多人已经用过并且踩过了很多的坑，其次我们才会去考虑性能、效率和空间开销。
还有一点我要特别强调。除了序列化协议的通用性和兼容性，序列化协议的安全性也是非常重要的一个参考因素，甚至应该放在第一位去考虑。以 JDK 原生序列化为例，它就存在漏洞。如果序列化存在安全漏洞，那么线上的服务就很可能被入侵。
综合上面几个参考因素，现在我们再来总结一下这几个序列化协议。
我们首选的还是 Hessian 与 Protobuf，因为他们在性能、时间开销、空间开销、通用性、兼容性和安全性上，都满足了我们的要求。其中 Hessian 在使用上更加方便，在对象的兼容性上更好；Protobuf 则更加高效，通用性上更有优势。
4. RPC 框架在使用时要注意哪些问题？了解了在 RPC 框架中如何选择序列化，那么我们在使用过程中需要注意哪些序列化上的问题呢？
我刚才讲过，在 RPC 的运营中，我遇到的最多的问题就是序列化问题了，除了早期 RPC框架本身出现的问题以外，大多数问题都是使用方使用不正确导致的，接下来我们就盘点下这些高频出现的人为问题。
对象构造得过于复杂：属性很多，并且存在多层的嵌套，比如 A 对象关联 B 对象，B 对象又聚合 C 对象，C 对象又关联聚合很多其他对象，对象依赖关系过于复杂。序列化框架在序列化与反序列化对象时，对象越复杂就越浪费性能，消耗 CPU，这会严重影响 RPC 框架整体的性能；另外，对象越复杂，在序列化与反序列化的过程中，出现问题的概率就越高。
对象过于庞大：我经常遇到业务过来咨询，为啥他们的 RPC 请求经常超时，排查后发现他们的入参对象非常得大，比如为一个大 List 或者大 Map，序列化之后字节长度达到了上兆字节。这种情况同样会严重地浪费了性能、CPU，并且序列化一个如此大的对象是很耗费时间的，这肯定会直接影响到请求的耗时。
使用序列化框架不支持的类作为入参类：比如 Hessian 框架，他天然是不支持LinkHashMap、LinkedHashSet 等，而且大多数情况下最好不要使用第三方集合类，如Guava 中的集合类，很多开源的序列化框架都是优先支持编程语言原生的对象。因此如果入参是集合类，应尽量选用原生的、最为常用的集合类，如 HashMap、ArrayList。
对象有复杂的继承关系：大多数序列化框架在序列化对象时都会将对象的属性一一进行序列化，当有继承关系时，会不停地寻找父类，遍历属性。就像问题 1 一样，对象关系越复杂，就越浪费性能，同时又很容易出现序列化上的问题。
在 RPC 框架的使用过程中，我们要尽量构建简单的对象作为入参和返回值对象，避免上述问题。
5. 总结我们深入学习了什么是序列化，并介绍了如 JDK 原生序列化、JSON、Hessian 以及Protobuf 等几种常见的序列化方式。
除了这些基础知识之外，我们重点讲解了在 RPC 框架中如何去选择序列化协议，我们有这样几个很重要的参考因素，优先级从高到低依次是安全性、通用性和兼容性，之后我们会再考虑序列化框架的性能、效率和空间开销。
这归根结底还是因为服务调用的稳定性与可靠性，要比服务的性能与响应耗时更加重要。另外对于 RPC 调用来说，整体调用上，最为耗时、最消耗性能的操作大多都是服务提供者执行业务逻辑的操作，这时序列化的开销对于服务整体的开销来说影响相对较小。
在使用 RPC 框架的过程中，我们构造入参、返回值对象，主要记住以下几点：
对象要尽量简单，没有太多的依赖关系，属性不要太多，尽量高内聚；入参对象与返回值对象体积不要太大，更不要传太大的集合；尽量使用简单的、常用的、开发语言原生的对象，尤其是集合类；对象不要有复杂的继承关系，最好不要有父子类的情况。实际上，虽然 RPC 框架可以让我们发起全程调用就像调用本地，但在 RPC 框架的传输过程中，入参与返回值的根本作用就是用来传递信息的，为了提高 RPC 调用整体的性能和稳定性，我们的入参与返回值对象要构造得尽量简单，这很重要。
第四章 动态代理1. 动态代理如果我问你，你知道动态代理吗？ 你可能会如数家珍般地告诉我动态代理的作用以及好处。那我现在接着问你，你在项目中用过动态代理吗？这时候可能有些人就会犹豫了。那我再换一个方式问你，你在项目中有实现过统一拦截的功能吗？比如授权认证、性能统计等等。你可能立马就会想到，我实现过呀，并且我知道可以用 Spring 的 AOP 功能来实现。
没错，进一步再想，在 Spring AOP 里面我们是怎么实现统一拦截的效果呢？并且是在我们不需要改动原有代码的前提下，还能实现非业务逻辑跟业务逻辑的解耦。这里的核心就是采用动态代理技术，通过对字节码进行增强，在方法调用的时候进行拦截，以便于在方法调用前后，增加我们需要的额外处理逻辑。
那话说回来，动态代理跟 RPC 又有什么关系呢？
2. 远程调用的魔法我说个具体的场景，你可能就明白了。
在项目中，当我们要使用 RPC 的时候，我们一般的做法是先找服务提供方要接口，通过 Maven 或者其他的工具把接口依赖到我们项目中。我们在编写业务逻辑的时候，如果要调用提供方的接口，我们就只需要通过依赖注入的方式把接口注入到项目中就行了，然后在代码里面直接调用接口的方法 。
我们都知道，接口里并不会包含真实的业务逻辑，业务逻辑都在服务提供方应用里，但我们通过调用接口方法，确实拿到了想要的结果，是不是感觉有点神奇呢？想一下，在 RPC 里面，我们是怎么完成这个魔术的。
这里面用到的核心技术就是前面说的动态代理。RPC 会自动给接口生成一个代理类，当我们在项目中注入接口的时候，运行过程中实际绑定的是这个接口生成的代理类。这样在接口方法被调用的时候，它实际上是被生成代理类拦截到了，这样我们就可以在生成的代理类里面，加入远程调用逻辑。
通过这种“偷梁换柱”的手法，就可以帮用户屏蔽远程调用的细节，实现像调用本地一样地调用远程的体验，整体流程如下图所示：
3. 实现原理动态代理在 RPC 里面的作用，就像是个魔术。我们以 Java 为例，看一个具体例子，代码如下所示：
1234567891011121314151617181920212223242526272829303132333435363738394041424344454647/*** 要代理的接口*/public interface Hello { String say();}/*** 真实调用对象*/public class RealHello { public String invoke(){ return "i'm proxy"; }}/*** JDK代理类生成*/public class JDKProxy implements InvocationHandler { private Object target; JDKProxy(Object target) { this.target = target; } @Override public Object invoke(Object proxy, Method method, Object[] paramValues) { return ((RealHello)target).invoke(); }}/*** 测试例子*/public class TestProxy { public static void main(String[] args){ // 构建代理器 JDKProxy proxy = new JDKProxy(new RealHello()); ClassLoader classLoader = ClassLoaderUtils.getCurrentClassLoader(); // 把生成的代理类保存到文件 System.setProperty("sun.misc.ProxyGenerator.saveGeneratedFiles","true"); // 生成代理类 Hello test = (Hello) Proxy.newProxyInstance(classLoader, new Class[]{Hello.class}); // 方法调用 System.out.println(test.say()); }}
这段代码想表达的意思就是：给 Hello 接口生成一个动态代理类，并调用接口 say() 方法，但真实返回的值居然是来自 RealHello 里面的 invoke() 方法返回值。你看，短短 50 行的代码，就完成了这个功能，是不是还挺有意思的？
那既然重点是代理类的生成，那我们就去看下 Proxy.newProxyInstance 里面究竟发生了什么？
一起看下下面的流程图，具体代码细节你可以对照着 JDK 的源码看（上文中有类和方法，可以直接定位），我是按照 1.7.X 版本梳理的。