拿快照来说，为啥我们支持快照的多链这么复杂？按道理虚拟机只需要一个卷，至于这个卷背后的链是完全不需要关心的。如果计算存储分离，快照局限于存储模块，计算只需要一个卷。
现象：快照的多链为什么这么复杂
拿快照来说，为啥我们支持快照的多链这么复杂？
按道理虚拟机只需要一个卷，至于这个卷背后的链是完全不需要关心的。
但是放到我们代码，复杂无比，即便是单链也异常复杂，多链简直就做不下去了。
如果分开，不过多复杂的快照链，只需要在快照模块处理。
但是我们现在的代码，各种功能和存储都在一起：
- 开关机要管理快照链（不是调接口，而是一行一行的命令呀）；
- 克隆要管理快照链；
- 迁移对快照链的操作更多了；
- 回滚快照、打快照，那更复杂了（快照的管理，一行一行的命令，元数据的修改，都在各种流程中交错）。简直了！
为什么这么难改
你可能会说，改呀，重构呀。
几十万行的屎山，牵一发动全身。不是一个人就能改的了的。
而且你改的过程中，别人还在持续扩展新功能，别人要怎么配合你的修改，都是很难的事。
这种推动，一定是自上而下的。不是说一人之力不能改，而是没人敢让你上。
得需要资源做 QA 大规模测试，还需要新扩展能力的配合，还需要领导有魄力，胆大心细。
执行人能做到心细，但是执行人胆大没用，别人怕出了问题你承担不了呀，得别人背锅。
需要决策人有魄力，自顶向下的推动。
但是如果老板或决策者离一线（售后、研发）远了，很可能不看重这些。
决策者大概率觉得，能跑就行，技术是工具，能满足客户需求即可。
但实际是，很多客户因为稳定性而流失，稳定性是因为屎山代码、架构问题、代码问题。
但是这些东西不能给财务数据带来改善，销售才能改善财务数据，所以继续怼销售提的需求，继续挖坑，继续流失客户。
根因：快照和计算绑定
就是因为我们的快照的处理、链的管理，都在计算里面。
因为我们主要用的 qcow2，qcow2 的快照性能高呀。
但是它有个问题，qcow2 的快照是和计算绑定的。
它为啥性能高，因为它需要计算层联动切换读写头。
如果要计算存储分离，就需要存储提供一种快照模式，不切换读写头，就能做快照。
lvm 是一种方式，bitmap，但是它做快照后写性能很低。
不考虑性能的因素下，计算、存储分离，极大降低快照开发的复杂性。
快照局限于存储模块，甚至是存储模块的快照子模块。计算只需要一个卷，不管其背后的链。
快照模块如何实现多链
A->B->C-> active
回滚到 A 后，A->active。
这个时候，要实现 B、C 的保留，且不被影响，也不影响别人，保留且独立。
- 如果是 qcow2 快照，那么天然是独立的，保留卷、保留链的数据关系即可；
- 如果是 lvm 这种，每个快照本身是独立的，保留即可，保留链关系元数据即可。
归根到底，链关系好处理，复杂性还是在存储端，性能和空间的取舍。
数据表的设计也简单，就是一个以原卷为根的一个树结构。
小结
- 边界：计算、存储、网络要分离；
- 按道理虚拟机只需要一个卷，至于这个卷背后的链是完全不需要关心的；
- 计算存储分离，极大降低快照开发的复杂性；
- 快照局限于存储模块，计算只需要一个卷，不管其背后的链；
- 几十万行的屎山，牵一发动全身，这种推动一定是自上而下的。