兼容性
兼容性这块儿，个人理解:向前兼容是旧版本服务可以读取新版本服务写的新数据，向后兼容则是新版本服务可以读取旧版本服务写的老数据。实质上是数据模式变化（比如新插入一列）和服务变化（服务做了升级，业务逻辑有新的处理）。任何编码格式都要解决其中一种或者两种的兼容性问题。
数据编码格式
数据表现形式
- 数据存储在内存。就有对象，结构体，列表，数组等。同时对访问和操作做了优化
- 数据在文件或网络中传输。就有字节序列
内存---->字节序列====序列化或者编码
字节序列---->内存====反序列化或解码
数据交互格式
主要分为语言自身的格式以及标准化编码和基于模式的二进制编码
-
语言自身格式
这个容易理解，很多开发语言都有内置的编解码工具，比如java有 Serializable 。这种编码格式用起来方便，但是缺点多，不能跨语言传输，效率低，安全问题等等
-
标准化编码
Json和XML以及CSV。传输过程中是序列化为二进制
-
基于模式的二进制编码
书中提到了Thrift，PB，AVRO这三个。简而言之，前两个模式是固定，也就是说提前预置好的编解码格式，不能在运行中兼容其他模式，只能满足向后兼容，也就是说数据模式不变，服务来回更新。Thrift提供了两种编码方式，差别在于CompactProtocol对于字节进行了压缩，将高位的0全部干掉。PB用的方式和Thrift的CompactProtocol一样，节省空间。AVRO比较特殊，它提供了读和写两种模式。这两种模式是互相解耦的可以按照自己需要的模式进行读和写。因此它是支持向前向后兼容。向前兼容其实就是新模式作为写，旧模式作为读；向后兼容则是新模式作为读，旧模式作为写。
数据流模式
-
基于数据库的数据流
数据库的数据模式向前向后兼容都支持。这种支持方式主要是靠服务来保证的。同时由于线上环境进行模式迁移（比如相同表之间结构的变化）成本较高，可以认为模式是不变。另外数据库进行归档存储时候模式也会存储，这个很好理解，任何一个数据库都不会只要数据不要格式进行归档
-
基于服务的数据流
web服务这里面主要有提到了 RestFull Soap rpc 这三个。restfull主要是Http的一种理念，后两者是实际传输的模式
-
基于消息传递的数据流
消息代理，作者罗列了一大堆特点，其实说的就是MQ。
Actor框架，实质就是消息代理和单个Actor节点的融合
