读程序员的README笔记17_构建可演进的架构(下)
1.读程序员的README笔记19_读后总结与感想兼导读2.读程序员的README笔记01_学习如何学习3.读程序员的README笔记02_软件的熵与技术债4.读程序员的README笔记03_变更代码5.读程序员的README笔记04_防御式编程6.读程序员的README笔记05_日志、监控与配置7.读程序员的README笔记06_测试(上)8.读程序员的README笔记07_测试(下)9.读程序员的README笔记08_依赖管理10.读程序员的README笔记09_代码评审11.读程序员的README笔记10_软件交付(上)12.读程序员的README笔记11_软件交付(下)13.读程序员的README笔记12_On-Call14.读程序员的README笔记13_技术设计流程(上)15.读程序员的README笔记14_技术设计流程(下)16.读程序员的README笔记15_敏捷计划17.读程序员的README笔记16_构建可演进的架构(上)
18.读程序员的README笔记17_构建可演进的架构(下)
19.读程序员的README笔记18_职业生涯规划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. 图
2.3.2. 拥有共享数据库的应用程序可以发展到直接依赖对方的数据,应用程序应该作为它们所使用的底层数据的控制点
2.3.3. 隔离的数据库只有一个读取者和写入者
2.3.3.1. 其他所有流量都通过远程过程调用
2.3.3.2. 图
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
合集:
读程序员的README
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· [翻译] 为什么 Tracebit 用 C# 开发
· 腾讯ima接入deepseek-r1,借用别人脑子用用成真了~
· Deepseek官网太卡,教你白嫖阿里云的Deepseek-R1满血版
· DeepSeek崛起:程序员“饭碗”被抢,还是职业进化新起点?
· RFID实践——.NET IoT程序读取高频RFID卡/标签