完整的 RPC 请求流程
RPC 在 server 端定义 pb(Protobuf) 文件，由编译工具生成 stub 桩文件，相当于链接静态库的方法实现了函数映射。
client 进行调用时，通过 Protobuf 的序列化协议进行encoding，根据 RPC 协议约定数据头、元数据、消息体等，保证有 ID 能使请求和返回结构做到一一映射。然后基于成熟的网络库进行 TCP/UDP 传输。
面试题：
- 函数映射：静态代理，生成 stub 文件
- 对比建立 HTTP 请求连接，RPC 在编写代码时降低了复杂度
- stub 文件让远程调用看起来是本地调用
- 序列化：为了生成二进制数据
- HTTP/1 直接发送 JSON 明文
- gRPC 以 protobuf 作为序列化协议
- 网络传输
- 自定义 RPC 协议实现通信
- 使用成熟的网络库，实现多路复用、可靠传输
RPC 与 HTTP 有哪些区别
-
HTTP 是应用层协议
-
RPC 是远程过程调用，是调用方式
-
所谓的 RPC 协议，实际上是基于 TCP、UDP、甚至HTTP2改造后的自定义协议
编（解）码层
网络传输前，需要将结构体转换为二进制（序列化） 通信协议：基于 TCP，会有消息头和消息体，区别在于消息头
HTTP/1.1
- 序列化协议：JSON
- 额外空间开销大，没有类型，开发时通过反射统一解决
- 通信协议
- 灵活，可以自定义很多字段
- 缺点是包含很多为了适应浏览器的冗余字段，内部服务用不到
RPC
- 序列化协议：以gRPC为代表的 Protobuf，其他也类似
- 序列化后体积比 JSON 小，传输效率高
- 序列化、反序列化速度快，开发时不需要通过反射，性能消耗低
- IDL 描述语义比较清晰
- 通信协议
- 可定制化，自定义必要字段即可
- 可摒弃很多 HTTP Header 中的字段
