金科科技 做网站媒体发稿推广
RPC序列化
任何一种序列化框架，核心思想就是设计一种序列化协议，将对象的类型、属性类型、属性值一一按照固定的格式写到二进制字节流中来完成序列化，再按照固定的格式把数据一一读取出来，通过这些数据信息创建出一个新的对象，来完成反序列化。
public class Book implements Serializable {int id;String name;String title;String tag;String content;// 其他略
}
有哪些序列化框架
如何选择RPC序列化框架？
结论：首选Hessian和Protobuf，因为他们在性能、时间开销、空间开销、通用性、兼容性和安全性上，都满足了我们的要求
- 安全性：首要考虑，如果序列化存在安全漏洞，那么线上的服务就很可能被入侵（JDK原生序列化存在漏洞）
- 兼容性：序列化协议在版本升级后的兼容性是否很好，是否是跨平台、跨语言等
- 通用性：能够对任意类型进行序列化和反序列化，不会出现服务接口方法加一个某种类型的参数之后服务突然调用方不能正常调用的情况
- 性能、效率：序列化与反序列化过程是 RPC 调用的一个必须过程，性能和效率势必将直接关系到 RPC 框架整体的性能和效率
- 空间开销：也就是序列化之后的二进制数据的体积大小。序列化后的字节数据体积越小，网络传输的数据量就越小，传输数据的速度也就越快，在RPC调用中直接关系到请求响应的耗时
使用RPC框架的时候需要注意：
- 避免对象构造得过于复杂，属性很多，并且存在多层的嵌套
- 避免对象过于庞大：大字符串，超大数组等
- 避免使用序列化框架不支持得类型作为参数传递
- 防止对象有复杂得继承关系
- 子类进行序列化的时候会一步步往上把父类也序列化了
- 如果父类中的某些字段不需要被序列化，可以使用
transient关键字修饰这些字段，使其在序列化过程中被忽略。
小结
通信协议及操作系统的IO模型
在应用层常见的就是HTTP协议，对于HTTP协议来说也有不少优缺点：
- 共有协议，通用，便于跨系统的通信
- 各语言适配完善，解析库成熟，有利于构建异构系统
- HTTP/1.1协议偏重，体积偏大，性能较低
HTTP/1.1是用AXCII码来表示的，内存占用还是较大
但是如果自研协议也有不少优缺点：
- 协议私有，通信两端要一致
- 需要自研协议的解析库
- 可以做到协议精简，性能和安全性更高
网络IO其实就是计算机内存和外部设备之间拷贝数据的过程，对于单个进程是无法直接要到网卡的数据的，但是Linux kernel可以，在内核当中会存在一片内核缓冲区，内核会给上层提供一些列的系统接口来刷走这片数据。
操作系统中的IO模型：
- 同步阻塞IO
- 同步非阻塞IO
- IO多路复用
- 信号驱动IO
- 异步IO
现在几乎都使用IO多路复用模型
小结
超时重试与时间轮算法
什么是超时重试？
当其中某个提供者服务挂掉了之后，直接把错误返回给用户是不太好的，所以会有一个兜底的策略，也就是超时重试，可以去向其他的提供者再一次发起请求。
如何检测请求是否超时？
- 客户端超时设置：客户端在发送RPC请求时可以设置一个超时时间，如果在规定时间内未收到响应，则认为请求超时。通常在客户端发送请求后会启动一个定时器来监控超时，一旦超时则可以进行相应的处理，比如重试或者返回错误信息。
- 服务端超时处理：服务端也可以设置处理请求的超时时间，如果服务端在规定时间内未能处理完请求并返回响应，可以直接返回超时错误给客户端。
- 中间件/代理层管理：在RPC框架中，通常会有中间件或代理层来管理请求的转发和响应，这些中间件可以负责监控请求和响应的超时情况，并进行相应处理。
- 统一超时管理：有些RPC框架会提供统一的超时管理机制，用于集中管理请求的超时设置和处理。通过这种机制，可以方便地对所有请求进行统一的超时处理，确保系统的稳定性。
我们把所有的超时请求全都集中管理起来，如下图所示：
那么，能否给出一种解决方案可以减少遍历的次数，提高效率呢？
时间轮算法
在时钟轮机制中，有时间槽，每个槽位代表一个时间，时间指针按照时间单位走动，将任务放到对应的时间槽位上，当时间指针走到改槽位的时候就可以拿出来执行。
小结
熔断、降级、限流
怎么判断需要进行熔断？
通过计算一段时间内服务的可用率/失败率
那么熔断工作什么时候开始的呢？又是什么时候结束的？
当可用率过低/失败率过高的时候会对服务进行熔断，熔断的时候会设置一个熔断时间，当超过熔断时间的时候系统会尝试调用一下这个服务，如果调用成功了，就可以结束熔断，反之继续熔断。
为什么有了熔断降级还需要限流？
在实际的生产环境当中，服务发生的一系列问题很大可能是由于高并发而引起的，这也就需要业务方要能够进行自我保护，从而保证在搞并发的情况下系统依然可以稳定运行。
限流的作用是用来限制其请求的速率，保护后台相应服务，以免服务过载导致服务不可用的现象出现。
常见的限流算法
令牌桶算法
我们会有一个生成令牌的工具去不断生成令牌，然后把令牌放入令牌桶当中，如果桶中的令牌用完了就不能再访问了，但是这个方法面临高并发的场景时就有可能只能把服务打挂掉。
漏斗算法
无论流量有多大，我一次只放一定量的请求进来，可以达到削峰的效果。
滑动窗口算法
限定在一定时间内我只接受多少请求，多了的不接收。
小结
