《数据密集型系统应用》笔记（三）
[TOC]
编码与演化
这一章节讲述架构整洁之道
向后兼容
前后总是难以理解， 这里讲一个办法，当前版本想象成一个人，向后兼容指的是对你身后的版本，即过去的代码兼容，新代码兼容旧数据
向前兼容
有了刚才的说法， 只向面前朝向即未来的版本兼容， 旧代码兼容新数据
编码
序列化反序列化 encoding/serialization/marshalling 、 decoding/deserialization/unmarshalling 常用的命名，（tip 可以让你的代码”显得“老练）
编码格式
json xml binary pb thrift 使用数字id保持向后兼容和后续扩展
模式编码的好处
- 它们可以比各种“二进制JSON”变体更紧凑，因为它们可以省略编码数据中的字段名称。 更好的压缩效率， 这是可以理解的相当于表头只需要保存一次
- 模式是一种有价值的文档形式，因为模式是解码所必需的，所以可以确定它是最新的 （而手动维护的文档可能很容易偏离现实）。 更好的可维护性，这也是可以理解的。
- 保留模式数据库允许您在部署任何内容之前检查模式更改的向前和向后兼容性。
- 对于静态类型编程语言的用户来说，从模式生成代码的能力是有用的，因为它可以在编 译时进行类型检查。
数据库数据流
注意滚动升级过程中的数据向后兼容
服务数据流
例如rest rpc的数据编码；
服务需要来自另一个服务的某些功能或数据时，就会向另一个服务发出请求。这种构建应用 程序的方式传统上被称为面向服务的体系结构（service-oriented architecture，SOA），最 近被改进和更名为微服务架构； SOA是架构，http、rpc是协议
RPC的问题
-
结果不可预测 （单貌似这不是rpc的问题， 本身微服务的架构是不可避免的
-
引入超时 （ 本身引入了更多的复杂性， 但是远程调用似乎无可避免
-
重试引起幂等性问题 （ 这点非常赞同， 对于幂等性，是rpc调用过程中必须需要考虑到，无论是基于消息队列还是同步调用，保证Qos exactly once的成本是非常高昂的，业务的幂等性是很有必要的， 一个通常的做法是使用事务id保证幂等）
-
时延不稳定
-
无法内存交换，需要引入序列化（也是前面提到的挑战）
RPC的演进
- 并行
- 服务发现
- 性能和兼容性
