设计数据密集型应用-第四章-编码和应用演进 (涉及的问题和方案)

对于参与过大量应用开发的同学， 大部分都体验过产品迭代，产品迭代中涉及到连个问题向前兼容(Forward Compatible) 和向后兼容(Backward Compatible)；

当前大部分的互联网产品设计开发过程中都涉及两部分，一个是服务器端开发，一个是客户端开发，并且都存在更新，我们将以此为例来解释上面提到的两个概念:

• 向前兼容(Forward Compatible), 旧代码兼容读取和处理新代码写入的数据
• 向后兼容（Backward Compatible） , 新代码兼容读取原代码写入的数据;

基于现有的架构模式（服务端-客户端/服务端），两者之间的数据交互需要规定具体协议并对数据进行一定的编码，即本文标题所提到编码；

当前比较普遍的数据编码方式JSON（在debug阶段,用的比较多），XML, Protocol Buffer (用的比较多)和Thrift（基本没用过），各有各的特点。

这里想重点分享一下Protocol Buffer和Thrift (都属于字节编码型, 都需要将schema和程序一块进行编译) 对于数据压缩(compact)， 向前兼容(forward compatible)和向后兼容(backward compatible)的不同方案，希望能对大家有些新的启发;

Protocol Buffer （最初由Google开发）， 使用过的同学应该清楚，在schema 定义阶段，需要为每个字段(field) 分配一个不重叠的整数(tag)，如

message Person{
    required string user_name = 1;
    optional int64 favorite_number = 2;
    repeated string interest = 3;
}

我们这里先用这个整数(field_tag)来标识对应的字段， 在编码阶段也通过编码这个整数(field_tag)来表示(有助于节省字节), 借助书中的一张图来解释Protocol Buffer 的编码过程, 其中数据内容为

{
    "userName": "Martin",
    "favriteNumber": 1337,
    "interest": ["daydreaming", "hacking"]
}

简单总结为，通过8比特来区分字段(field_tag)和字段类型, 1个字节来表示字段长度（整形无需字段长度，但涉及大数问题）;

对比与Thrift (最早由Facebook开发并开源), schema定义方式为

struct Person{
    1: required string userName,
    2: optional int64 favoriteNumber,
    3: optional list<string> interest
}

其字段的编码方式是通过一个字节来表示字段类型，二个字节来区分字段，四个字节来表示字段长度, 具体见引用书中的一张图

关于向前和向后兼容问题，从编码方式上来看，Protocol Buffer 和Thrift 都是通过连续的编码，将整形标识作为字段表示，并通过字段类型表示来解析字段；

• 这种方式下，新schema 如果进行新字段添加，原有字段名修改，可向后兼容（backward compatible）原代码(如果你定义字段为optinal, 如果为required会产生兼容问题); 而且旧代码通过field_tag进行读取新数据并不会产生任何不兼容

• 新schema进行字段类型变更, 新代码解析旧数据时会产生不兼容的情况，旧代码读取新数据也会产生不兼容的问题; 向前和向后兼容都不可行;

• 新schema进行删除字段 （如果字段为required），旧代码读新数据时会产生问题, 新代码读旧数据时可兼容，但是涉及到后期新添字段可能导致旧数据被误解析；

书中还提到另一种编码方式Apache Avro, 这种方式在编解码过程不对字段类型进行规定，而是依据所提供的schema(内含tag_field和field_type )进行编码和解码;