DDIA

本次看的是第4章, 编码与演化.

概览

系统兼容性: 向后兼容(backward compatibility) 新代码可以读旧数据, 向前兼容(forward compatibility) 旧代码可以读新数据.
向后兼容不难, 向前兼容更麻烦. 在我们的应用开发中经常要考虑兼容性的问题.

网络传输编码格式分为3类, JSON, XML和二进制变体. 二进制变体有Protocol Buffers, Thrift, Avro等.

传输服务分为具象状态传输(REST), 远程过程调用(RPC), 消息传递系统(Actor和消息队列).

JSON, XML和二进制变体

XML最繁琐和复杂, JSON相对更简短且Web内置支持, 二进制变体最短.

有一些二进制版本JSON & XML的出现, 如JSON(MessagePack, BSON, BJSON, UBJSON, BISON, Smile), XML(WBXML, Fast Infoset). 这些格式比JSON和XML更短, 在很多领域被用到, 但是应用没有JSON和XML广泛.

另外一些二进制更短, Apache Thrift和Protocol Buffers(prototbuf)是基于相同原理的二进制编码库. Protocol Buffers最初是google开发, Thrift最初是Facebook开发, 都已开源.

长度对比

JSON, 81字节

{
    "userName": "Martin",
    "favoriteNumber": 1337,
    "interests": ["daydreaming", "hacking"]
}

MessagePack, 66字节

Protocol Buffers, 33字节

模式演变, 如何保持兼容性

Protocol Buffers没有保存字段的名字, 只存了一个标识(示例中的1,2,3)和数据类型(string, int等).

实现向前兼容性: 可以添加新的字段, 只要新的字段是新的标识号码. 如果旧的代码试图读取新的数据, 包含新的字段, 由于新的标识号码它无法识别, 它可以简单的忽略该字段.

实现向后兼容性: 只要每个字段都有唯一的标识号码, 新的代码总是可以读取旧数据, 但是 要求新加的字段不能设置为必填字段, 必须是可选字段或者带默认值.

数组的表示: Protocol Buffers没有数组类型, 而是靠连续的相同标识来表示. 如图中的连续2个标识3表示为一个数组. 缺点就是不支持嵌套数组.

特殊的Avro

Avro的字节序列中没有数据类型和标识号码. 需要额外一个模式文件(JSON格式). 也就是说字节序列本身的可读性不是很好, 需要由一个说明文件来说明才能完全读懂. 好处是带来了一定的自由度, 且减少了编码长度. 模式文件可以以新的版本表的方式, 只存一个模式ID, 达到共用的效果.

参考https://www.cnblogs.com/wqbin/p/11228188.html

REST和RPC

REST vs SOAP

REST是动态的, 是基于HTTP标准的, 适合对外开放.
SOAP是用于制作网络API请求的基于XML的协议.

1. 依赖代码生成和IDE.
2. 表面上标准化的, 但是不同厂商的实现之间的互操作性往往会造成问题. 例如Java和.NET之间调用web service还是有些问题.

REST似乎是公共API的主要风格。 RPC框架的主要重点在于同一组织拥有的服务之间的请求，通常在同一数据中心内

RPC

传统RPC: Enterprise JavaBeans（EJB）和Java的远程方法调用（RMI）仅限于Java。分布式组件对象模型（DCOM）仅限于Microsoft平台。公共对象请求代理体系结构（CORBA）过于复杂，不提供前向或后向兼容性
新式RPC: Thrift和Avro带有RPC支持，gRPC是使用Protocol Buffers的RPC实现，Finagle也使用Thrift，Rest.li使用JSON over HTTP

非直接调用

REST和RPC都是直接调用的类型, 还有非直接调用, 一般有2种, 消息队列和Actor框架.