架构决定下限，代码决定上限。虽然代码影响很大，但是整体的稳定性，依然是架构占大部分决定因素。linux 网络栈足够复杂，但又有足够的扩展性，且非常的高性能，为什么？因为它流水线 + sk_buff。
核心：架构决定稳定性
架构决定下限，代码决定上限。
虽然代码影响很大，但是整体的稳定性，依然是架构占大部分决定因素。
linux 网络栈（sk_buff），足够复杂，但又有足够的扩展性，且非常的高性能。
它确很稳定，为什么？
因为他流水线 + sk_buff：
- 它的核心对象，是高内聚的、面向对象的；
- 它子模块是松耦合的，通过核心对象来协作。
我们的 iaas 流程呢？
没有核心对象，全是临时去数据库查，临时到数据库更新，临时到 hyper 获取环境信息。
修改也是修改很细微的变量，而不是一个从一而终的对象。
这种构成了各种千丝万缕的关系，且环节之间直接调用，相互耦合。
缺乏一个解耦式的流水线的设计。
即便不是 k8s 那种声明式的架构，即便是流程式的、面向过程的架构，也不至于这么乱呀。
最简单的解法
最简单的，主机是一个核心对象，从创建开始就确定了的，后续就不要再改了。
volume 是核心对象，和主机绑在一起。再加个网络核心对象，和主机绑定。
全流程从头到尾，都操作这三个核心对象，且通过责任链的方式，A 环节操作完了，B 环节。
这样每个环节是解耦的，他们不关心上下环节，只关心核心对象。
这种简单、稳定多了呀。
web 框架 gin，也是这样呀，大家都操作一个 context 对象，这样各个处理模块互不耦合，且扩展性好。
小结
- 架构决定下限，代码决定上限；
- 整体的稳定性，依然是架构占大部分决定因素；
- linux 网络栈稳定，因为它流水线 + sk_buff，核心对象高内聚，子模块松耦合；
- 我们的 iaas 流程没有核心对象，全是临时去数据库查、临时更新，构成千丝万缕的关系；
- 主机、volume、网络是核心对象，全流程操作这三个核心对象，通过责任链的方式，每个环节解耦。