Rpc（Remote Procedure Call，远程进程调用）框架是一种用于实现分布式系统中不同节点之间通信和调用的技术框架。
RPC的过程可以概括为以下几个流程
- 客户端调用：在分布式系统中，客户端想要调用远程服务器上的某个方法或函数时，会通过RPC框架提供的接口指定要调用的方法名称、参数等信息。（user）
- 序列化：RPC框架将客户端的调用请求进行序列化，把方法名称、参数等信息转换为可以在网络上传输的字节流。常见的序列化方式有JSON、Protobuf等，这一步一般是写一个idl，使用框架生成响应的代码。（User-stub）
- 网络传输：序列化后的请求通过网络传输发送到远程服务器。常用的网络协议包括TCP、HTTP等。（RPC-run-time）
从这一步开始转到服务器内容
- 反序列化：远程服务器接收到客户端的请求后，RPC框架对请求进行反序列化，将字节流转换回方法名称、参数等信息。（service-stub）
- 服务器执行：服务器根据方法名称找到对应的实际方法，并传入参数执行该方法。执行完毕后，将结果进行序列化，并通过网络传输返回给客户端。(service)
- 结果反序列化：客户端的RPC框架接收到结果后进行反序列化，将结果提供给客户端程序使用。(service)
RPC的优点，为什么要用Rpc
单一职责，有利于分工协作
可扩展性更强，资源使用率更优
故障隔离，可靠性更高
RPC的弊端
服务宕机
网络异常
请求量过多
RPC的分层设计
1.编解码层
生成代码可以看作编解码层的一部分
客户端和服务端依赖于同一份IDL文件，接受同一个约束
IDL文件有三种类型
1.代码自带的语言，Java.io.serializabele,好用但和语言绑定
2.json文件，csv文件等文本文件，可读但效果不好
3.二进制编码，protobuf，把数据转化为二进制流
2.协议层
字节流之间的传输之间的约定
比如一些特殊的字符，让你知道信息什么时候开始，什么时候结束
3.网络通讯层
socket api
应用层与传输层之间，一般选用封装好的网络库，即层与层之间用于通讯的接口
就这几个角度来看，从TCP/IP四层模型上来看，RPC主要集中在应用层和传输层，编解码后通过协议进行传输
RPC的关键指标
1.稳定性
保障策略，熔断
保护调用方，防止在被调用方出现问题时，影响到整个网络链路
保障策略，限流
保护被调用方，防止被调用方被大量流量压垮
保障策略，超时控制
避免资源浪费在不需要的地方
如何提高稳定性
负载均衡，均匀调用
长尾请求
关于延迟有一个常用的P99标准，即99%的请求延迟要满足在一定耗时以内，而剩下的1%的请求会大于这个耗时。这1%的请求就被认为是长尾请求。长尾请求虽然占比一般较少，但对用户体验的影响却可能很大。
你可以设置一个t，他小于长尾请求的时间，时长错过这个时间，就再发一个请求，选响应小的
框架如何使用这些策略
注册中间件，这里感觉没什么内容，使用时也是直接调用库
而对于一个全新的中间件，我认为关键还是在一下几点，以熔断为例
1. 设计中间件架构
选择中间件的位置：例如在请求处理的管道中，通常位于客户端请求到达后端服务之前。
定义中间件接口：包括处理请求、响应、错误和熔断逻辑的方法。
2. 实现中间件
请求处理（得到输入）：记录请求和响应的时间，计算错误率。
熔断逻辑（代码逻辑）：检查是否满足熔断条件，如果满足则执行熔断操作。
恢复机制（实现目标）：实现熔断后的恢复逻辑，如计时器或条件检查。
2.高性能
目标：高吞吐，低延迟（更重要）
微服务过微的问题：虽然将每个服务分开开发，但是独立性也导致了新来的服务都会使用一个微服务，导致微服务越来越多
