核心对象

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