RPC通信原理（二）

任何一种序列化框架，核心思想就是设计一种序列化协议，将对象的类型、属性类型、属性值一一按照固定的格式写到二进制字节流中来完成序列化，再按照固定的格式把数据一一读取出来，通过这些数据信息创建出一个新的对象，来完成反序列化。

public class Book implements Serializable {
	int id;
	String name;
	String title;
	String tag;
	String content;
	// 其他略
}

结论：首选Hessian和Protobuf，因为他们在性能、时间开销、空间开销、通用性、兼容性和安全性上，都满足了我们的要求

安全性：首要考虑，如果序列化存在安全漏洞，那么线上的服务就很可能被入侵（JDK原生序列化存在漏洞）
兼容性：序列化协议在版本升级后的兼容性是否很好，是否是跨平台、跨语言等
通用性：能够对任意类型进行序列化和反序列化，不会出现服务接口方法加一个某种类型的参数之后服务突然调用方不能正常调用的情况
性能、效率：序列化与反序列化过程是 RPC 调用的一个必须过程，性能和效率势必将直接关系到 RPC 框架整体的性能和效率
空间开销：也就是序列化之后的二进制数据的体积大小。序列化后的字节数据体积越小，网络传输的数据量就越小，传输数据的速度也就越快，在RPC调用中直接关系到请求响应的耗时

使用RPC框架的时候需要注意：

避免对象构造得过于复杂，属性很多，并且存在多层的嵌套
避免对象过于庞大：大字符串，超大数组等
避免使用序列化框架不支持得类型作为参数传递
防止对象有复杂得继承关系
- 子类进行序列化的时候会一步步往上把父类也序列化了
- 如果父类中的某些字段不需要被序列化，可以使用transient关键字修饰这些字段，使其在序列化过程中被忽略。

在应用层常见的就是HTTP协议，对于HTTP协议来说也有不少优缺点：

HTTP/1.1是用AXCII码来表示的，内存占用还是较大

但是如果自研协议也有不少优缺点：

网络IO其实就是计算机内存和外部设备之间拷贝数据的过程，对于单个进程是无法直接要到网卡的数据的，但是Linux kernel可以，在内核当中会存在一片内核缓冲区，内核会给上层提供一些列的系统接口来刷走这片数据。

操作系统中的IO模型：

同步阻塞IO
同步非阻塞IO
IO多路复用
信号驱动IO
异步IO

现在几乎都使用IO多路复用模型

什么是超时重试？

当其中某个提供者服务挂掉了之后，直接把错误返回给用户是不太好的，所以会有一个兜底的策略，也就是超时重试，可以去向其他的提供者再一次发起请求。

如何检测请求是否超时？

客户端超时设置：客户端在发送RPC请求时可以设置一个超时时间，如果在规定时间内未收到响应，则认为请求超时。通常在客户端发送请求后会启动一个定时器来监控超时，一旦超时则可以进行相应的处理，比如重试或者返回错误信息。
服务端超时处理：服务端也可以设置处理请求的超时时间，如果服务端在规定时间内未能处理完请求并返回响应，可以直接返回超时错误给客户端。
中间件/代理层管理：在RPC框架中，通常会有中间件或代理层来管理请求的转发和响应，这些中间件可以负责监控请求和响应的超时情况，并进行相应处理。
统一超时管理：有些RPC框架会提供统一的超时管理机制，用于集中管理请求的超时设置和处理。通过这种机制，可以方便地对所有请求进行统一的超时处理，确保系统的稳定性。

我们把所有的超时请求全都集中管理起来，如下图所示：