Question

唯变所适 ——以弗所的赫拉克利特，为柏拉图所引（公元前 360 年）

应用程序不可避免地随时间而变化。新产品的推出，对需求的深入理解，或者商业环境的变化，总会伴随着 功能（feature） 的增增改改。 第一章 介绍了 可演化性(evolvability) 的概念：应该尽力构建能灵活适应变化的系统（参阅 可演化性：拥抱变化 ）。

在大多数情况下，修改应用程序的功能也意味着需要更改其存储的数据：可能需要使用新的字段或记录类型，或者以新方式展示现有数据。

我们在 第二章 讨论的数据模型有不同的方法来应对这种变化。关系数据库通常假定数据库中的所有数据都遵循一个模式：尽管可以更改该模式（通过模式迁移，即 ALTER 语句），但是在任何时间点都有且仅有一个正确的模式。相比之下， 读时模式（schema-on-read） （或 无模式（schemaless） ）数据库不会强制一个模式，因此数据库可以包含在不同时间写入的新老数据格式的混合（参阅 文档模型中的模式灵活性 ）。

当数据 格式（format） 或 模式（schema） 发生变化时，通常需要对应用程序代码进行相应的更改（例如，为记录添加新字段，然后修改程序开始读写该字段）。但在大型应用程序中，代码变更通常不会立即完成：

• 对于 服务端（server-side） 应用程序，可能需要执行 滚动升级 （rolling upgrade） （也称为 阶段发布（staged rollout） ），一次将新版本部署到少数几个节点，检查新版本是否运行正常，然后逐渐部完所有的节点。这样无需中断服务即可部署新版本，为频繁发布提供了可行性，从而带来更好的可演化性。
• 对于 客户端（client-side） 应用程序，升不升级就要看用户的心情了。用户可能相当长一段时间里都不会去升级软件。

这意味着，新旧版本的代码，以及新旧数据格式可能会在系统中同时共处。系统想要继续顺利运行，就需要保持 双向兼容性 ：

向后兼容 (backward compatibility)

​ 新代码可以读旧数据。

向前兼容 (forward compatibility)

​ 旧代码可以读新数据。

向后兼容性通常并不难实现：新代码的作者当然知道由旧代码使用的数据格式，因此可以显示地处理它（最简单的办法是，保留旧代码即可读取旧数据）。

向前兼容性可能会更棘手，因为旧版的程序需要忽略新版数据格式中新增的部分。

本章中将介绍几种编码数据的格式，包括 JSON，XML，Protocol Buffers，Thrift 和 Avro。尤其将关注这些格式如何应对模式变化，以及它们如何对新旧代码数据需要共存的系统提供支持。然后将讨论如何使用这些格式进行数据存储和通信：在 Web 服务中， 具象状态传输（REST） 和 远程过程调用（RPC） ，以及 消息传递系统 （如 Actor 和消息队列）。