读程序员的README笔记17_构建可演进的架构（下）.png

1. 可演进的API

1.1. 随着需求的变化，你需要改变你的API，即代码之间的共享接口

1.2. 改变API很容易，但很难做到正确

1.3. 保持API小巧

1.3.1. 小巧的API更易于理解和演进

1.3.2. 只添加即刻需要的API方法或字段

1.3.3. 带有许多字段的API方法应该有合理的默认值

1.3.3.1. 开发人员可以只专注于和自己相关的字段，因为它们会继承其他字段的默认值

1.3.3.2. 默认值可使大型API在感觉上很小巧

1.4. 公开定义良好的服务端API

1.4.1. 切记使用标准工具来定义服务端API

1.4.1.1. OpenAPI通常用于RESTful服务

1.4.1.2. non-REST服务则使用Protocol Buffers、Thrift或类似的接口定义语言(interface definition language，IDL)

1.4.1.3. 接口定义工具自带代码生成器，可以将服务的定义转换为客户端和服务端代码

1.4.1.4. 文档也可以被生成，测试工具可以使用IDL来生成stub数据和模拟数据

1.5. 保持API变更的兼容性

1.5.1. 向前兼容

1.5.1.1. 向前兼容的变更允许客户端在调用旧版的服务时使用新版的API

1.5.1.2. 一个正在运行1.0版API的网络服务，但可以接收来自使用1.1版API的客户端的调用，这就是向前兼容

1.5.2. 向后兼容

1.5.2.1. 向后兼容的变更：新版本的库或服务不需要改变旧的客户端代码

1.5.2.2. 如果针对1.0版API开发的代码在使用1.1版时能继续编译和运行，这种变更就被称为向后兼容

1.6. API版本化

1.6.1. 随着API的不断演进，你将需要决定如何处理多个版本的兼容性

1.6.2. 完全向后兼容和向前兼容的变更意味着API的所有的历史版本和未来版本都可以相互操作

1.6.3. 你会想变更你的API，使之与旧的客户端不兼容

1.6.3.1. 当客户端代码难以变更时，API的版本管理最有价值

1.6.4. 版本化你的API意味着你在做出改变时将引入一个新的版本

1.6.4.1. API版本化自有其代价

1.6.4.2. 旧的主版本服务需要被维护，修复的bug也需要回传到以前的版本

1.6.5. API版本通常由API网关或服务网格来管理

1.6.5.1. 管理版本所采用的方法要务实

1.6.6. 将文档与你的API一起保持版本化

2. 可持续的数据管理

2.1. API比持久化数据存续的时间更短

2.1.1. 一旦客户端和服务端API都升级了，就意味着工作完成了

2.2. 隔离数据库和使用明确的schema将使数据演进更易于管理

2.3. 数据库隔离

2.3.1. 共享的数据库很难演进，并且会导致丧失自主性

2.3.1.1. 图

11-共享数据库.png

2.3.2. 拥有共享数据库的应用程序可以发展到直接依赖对方的数据，应用程序应该作为它们所使用的底层数据的控制点

2.3.3. 隔离的数据库只有一个读取者和写入者

2.3.3.1. 其他所有流量都通过远程过程调用

2.3.3.2. 图

11-隔离数据库.png

2.3.4. 隔离数据库为你提供了共享数据库所不具备的灵活性和隔离性

2.4. 使用schema

2.4.1. 僵化的预定义数据列和类型，以及它们演进的重量级过程，会导致流行的无模式(schemaless)数据管理的出现

2.4.2. 无模式并不意味着“没有模式”（数据将无法使用）

2.4.3. 不要将无模式的数据隐藏在已经模式化的数据中

2.4.3.1. 隐藏无模式的数据是“自取灭亡”，你获得了显式schema的所有痛苦，却没有任何收益

2.4.4. 无模式数据有一种隐含的模式，可以在读取时被提供或推断出来

2.4.5. 采用无模式的方法会产生明显的数据完整性和复杂性问题

2.4.6. 强类型的面向schema的方法降低了应用程序的隐蔽性，因此也降低了其复杂性

2.4.7. 为你的数据定义明确的schema将使你的应用程序保持稳定，并使你的数据可用

2.4.7.1. 明确的schema会让你在编写数据时可以对其进行合理性检查

2.4.7.2. 使用显式schema解析数据通常会更快捷

2.4.7.3. 架构还可以帮助你检测到前后不兼容的变化

2.4.8. 数据有时被描述为“一次写入，多次读取”，使用schema可以使读取更容易

2.4.9. schema自动化迁移

2.4.9.1. 改变一个数据库的schema是危险的

2.4.9.2. 可以管理数据库迁移的工具

2.4.9.2.1. Liquibase

2.4.9.2.2. Flyway

2.4.9.2.3. Alembic

2.4.9.2.4. GitHub的gh-ost

2.4.9.2.5. Percona的pt-online-schema-change

2.4.9.2.6. Skeema

2.4.9.2.7. Square的Shift

2.4.9.3. 大多数迁移工具都支持回滚，也就是可以撤销迁移产生的变化

2.4.10. 保持schema的兼容性

2.4.10.1. 写入磁盘的数据也有和API一样的兼容性问题

2.4.10.2. 变更数据捕获(change data capture，CDC)是一种基于事件的架构，将插入、更新和删除操作转换为下游使用者的消息

2.4.10.3. 数据仓库管道和下游用户必须受到保护，以免遭受schema变更带来的不良影响

2.4.10.4. 兼容性检查应该尽早地进行，最好是在提交代码时通过检查数据库DDL语句来进行

2.4.10.5. 独立的数据产品，可能只是数据库视图，允许团队与数据的消费者保持兼容，而不必冻结其内部的数据库schema