迷路大概有两种，一种认识到自己迷路了，一种是迷路了还不知道。
在写删除部分逻辑的测试代码以前，我大概就是后一种。
编写删除代码在一定程度上比创建的部分还麻烦——得益于老同志奇技淫巧的 Cascade 框架，删除逻辑不是类似于你自己心里计划的那样先删什么，再删什么，最后删什么。而是通过前面说的集连框架，系统会自动分析依赖关系，形成一个树形结构自动逐个剪枝。
这种手法似乎有一个很厉害的名字叫做依赖反转——以我贫瘠的设计模式知识，这是我能想到的最接近的词汇了，通过这种手法，理论上讲上层资源在删除时不需要过分考虑底层细节及其依赖关系。
然而实际应用中，有一个问题却很棘手，就是扩展资源。
考虑你有一个已有资源叫做 L2Network，现在你打算发展一个新的资源，比如叫 L2VxlanNetwork（以下可能简称为 Vxlan），而且由于这种资源的特殊性，它还有一个父资源叫做 L2NetworkPool（以下可能简称为 Pool），现在请问如何优雅的撰写你的 Cascade 代码，需要做到能自动级联删除底层资源 VM、L3Network、Router 等，并在上层资源变化如 Zone 被删除时相应自动删除掉。
除了删除，还要考虑 Attach、Detach 操作，这两个操作总会在 Pool 上被执行，我们目前不允许它在 L2VxlanNetwork 上执行。
另外由于代码的设计原因，每一个 L2VxlanNetwork 底层其实会对应一个 L2Network，同样每一个 L2VxlanNetworkPool 也会在底层对应一个 L2Network，理论上来讲如果是删除底层的 L2Network，那么其对应的 Pool 或 Vxlan 也会被删掉。
Attach 和 Detach 类似，但除了数据库操作，显然还有额外的数据平面动作，因此又有些不同，这两个操作只在 Pool 上做是有效的，在 Vxlan 上做没有意义。
面对这一坨逻辑和已有的框架，如何能既让我写的开心，又不让后面维护代码的人不是特别苦逼？
..
我的想法是先站在一个没有这个框架和大量关于 Vxlan 的先验知识的角度上审视这个问题。
Vxlan 无疑很像一个 L2Network，而 Pool 则像是批量管理 Vxlan 的抽象。
因此应该这样设计，从底层上利用 Vxlan 和 L2Network 逻辑接近的优势，尽量复用代码，关于 Cascade，新添加 Vxlan 资源，使其依赖 Pool，Pool 向上依赖 Zone。Vxlan 在 Cascade 中利用 L2Network 的删除、Detach 逻辑，而非自己实现。
..
下面我们通过一个 Story 检验一下这个逻辑是否可行。
下面我写了很多内容然后删掉了，
因为我发现不可行。简单的说会形成回环。
但是机智的我感觉还有一种方案。明天再试。
..
世间最惨的莫过于你忽然发现自己走在迷宫里而不自知，想办法以为走出来了，却是还在迷宫里而不自知。
但是最终你还是知道了。
..
本来打算今天凌晨写的博客算今天的，晚上就不写了，没想到自己整理思路又 bb 出一篇毫无营养无病呻吟的博客，而且写开头时没有猜到结尾。
早上自我灌输了一万遍今天早睡，结果还是快凌晨才回家。嗯，沉迷工作。
Leave a Reply