这是我参与「第三届青训营 -后端场」笔记创作活动的第3篇笔记，今天讲一下RPC及其框架设计。
本地调用与RPC
- 本地调用：基本的函数调用，基于单机内的编译器、系统层面进行
- RPC：需要进行函数映射、编码、传输等过程，完成过程如下：
- IDL接口描述
- 生成代码：IDL转化为静态库
- 编解码：数据的序列化与反序列化
- 通信协议：规范传输格式
- 网络传输：基于TCP、UDP等传输渠道
- RPC的优势
- 单一职责，有利于分工协作和运维开发
- 可扩展性强，资源使用率更优
- 故障隔离，服务整体可靠性更高
- RPC问题：
- 服务宕机
- 网络异常
- 请求异常
RPC框架
- 编解码层：负责编解码
- 协议层：负责序列化与反序列化
- 网络通信层：负责网络通信
编解码层
基于统一的IDL生产对应不同语言和平台的代码
- 数据格式
- 语言特定的：pickle等，这种编码形式好处是非常方便，可以用很少的额外代码实现内存对象的保存与恢复，这类编码通常与特定的编程语言深度绑定，其他语言很难读取这种数据。如果以这类编码存储或传输数据，那你就和这门语言绑死在一起了。安全和兼容性也是问题
- 文本格式：文本格式具有人类可读性，数字的编码多有歧义之处，比如XML和CSV不能区分数字和字符串，JSON虽然区分字符串和数字，但是不区分整数和浮点数，而且不能指定精度，处理大量数据时，这个问题更严重了；没有强制模型约束，实际操作中往往只能采用文档方式来进行约定，这可能会给调试带来一些不便。 由于JSON在一些语言中的序列化和反序列化需要采用反射机制，所以在性能比较差；
- 二进制编码：实现可以有很多种，TLV 编码 和 Varint 编码 如thrift protobuf
- 技术选型
- 通用性： 通用性有两个层面的意义： 第一、技术层面，序列化协议是否支持跨平台、跨语言。如果不支持，在技术层面上的通用性就大大降低了。 第二、流行程度，序列化和反序列化需要多方参与，很少人使用的协议往往意味着昂贵的学习成本；另一方面，流行度低的协议，往往缺乏稳定而成熟的跨语言、跨平台的公共包。
- 兼容性： 移动互联时代，业务系统需求的更新周期变得更快，新的需求不断涌现，而老的系统还是需要继续维护。如果序列化协议具有良好的可扩展性，支持自动增加新的业务字段，而不影响老的服务，这将大大提供系统的灵活度。
- 性能： 第一、空间开销（Verbosity）， 序列化需要在原有的数据上加上描述字段，以为反序列化解析之用。如果序列化过程引入的额外开销过高，可能会导致过大的网络，磁盘等各方面的压力。对于海量分布式存储系统，数据量往往以TB为单位，巨大的的额外空间开销意味着高昂的成本。 第二、时间开销（Complexity），复杂的序列化协议会导致较长的解析时间，这可能会使得序列化和反序列化阶段成为整个系统的瓶颈。
协议层
协议是双方确定的交流语义。
- 类型
- 特殊结束符：过于简单，对于一个协议单元必须要全部读入才能够进行处理，除此之外必须要防止用户传输的数据不能同结束符相同，否则就会出现紊乱 HTTP 协议头就是以回车(CR)加换行(LF)符号序列结尾。
- 变长协议：一般都是自定义协议，有 header 和 payload 组成，会以定长加不定长的部分组成，其中定长的部分需要描述不定长的内容长度，使用比较广泛
网络通信层
- Socker API：套接字编程中的客户端必须知道两个信息：服务器的 IP 地址，以及端口号。 socket函数创建一个套接字，bind 将一个套接字绑定到一个地址上。listen 监听进来的连接。
- 网络层对socket进行了封装
- 易用API
- 支持多协议
- 高性能
