系统核心抽象
- S：在学习和实践“系统核心抽象”时，需要建立统一的概念和问题边界。
- C：相关概念、实现机制和工程取舍容易混在一起，导致只记住结论而无法判断适用条件。
- Q：“系统核心抽象”要解决什么问题？它的核心抽象、工作机制和边界分别是什么？
- A：本文围绕“系统核心抽象”整理核心概念、关键机制和工程实践，并明确其适用边界。
系统的核心抽象是什么？这个抽象组织了什么结构？它把什么复杂问题转化成了什么更可控的问题？
- 第一问：核心抽象是什么？这个系统希望你用什么东西来理解世界
- 第二问：这个抽象提供了什么结构？抽象不是空的概念，它会带来结构，可以推理出其提供的能力。
- 第三问：它把问题 Y 转换成了问题 Z？最关键的工程思维：好的抽象会把一个难问题，转换成一个更结构化、更可控的问题。
用某个抽象承载复杂性，并把复杂性放到一个可管理的位置。
| 系统 | 核心抽象 | 把什么问题转成什么问题 |
|---|---|---|
| Redis | 内存中的数据结构服务器 | 把高性能状态访问问题，转成操作合适数据结构的问题 |
| MySQL | 关系模型 + 事务 + 索引 | 把业务数据一致性问题，转成表、约束、事务、查询优化问题 |
| MongoDB | 文档 / 聚合根 | 把对象聚合读写问题，转成文档建模和访问路径设计问题 |
| Kafka | 分布式日志 / 事件流 | 把系统间状态同步问题，转成追加、排序、复制、消费日志的问题 |
| etcd | 一致性的 KV 状态机 | 把分布式协调问题，转成对小规模关键状态的线性一致读写问题 |
| Docker | 镜像 + 容器 | 把环境一致性问题，转成打包、分发、运行隔离的问题 |
| Kubernetes | 声明式资源 + 控制器 | 把运维操作问题，转成声明期望状态与持续调谐的问题 |
系统学习框架
工程学习的关键，是看清一个系统用什么抽象承载复杂性，又把问题转换成了什么形式。
- 它解决的原始复杂问题是什么？
- 它提出的核心抽象是什么？
- 这个抽象内部有什么结构？
- 这个结构天然支持哪些能力？
- 它把问题 Y 转换成了什么问题 Z？
- 它把复杂性藏在哪里了？
- 它暴露给使用者的 trade-off 是什么？
- 它最适合和最不适合的场景是什么？
注意点6，抽象不是消灭复杂性，而是重新分配复杂性。 它让我不用操心什么？又让我必须操心什么？
评论