/tags/%E8%AE%BE%E8%AE%A1/Recent content in 设计 on 文叨叨 | IaaS 排障手记Hugozh-cnSun, 24 May 2026 10:00:00 +0800/posts/long-running-vs-temp-adjust/Sun, 24 May 2026 10:00:00 +0800/posts/long-running-vs-temp-adjust/存量 VM 不切换，我们可以提供一个接口来调整虚拟机的 cpu_mode 来实现。这样长运行的逻辑简单，而调整和长运行逻辑分离，降低复杂性。/posts/architecture-determines-stability/Sat, 23 May 2026 10:00:00 +0800/posts/architecture-determines-stability/架构决定下限，代码决定上限。虽然代码影响很大，但是整体的稳定性，依然是架构占大部分决定因素。linux 网络栈足够复杂，但又有足够的扩展性，且非常的高性能，为什么？因为它流水线 + sk_buff。/posts/is-simple-the-only-criterion/Sun, 17 May 2026 10:00:00 +0800/posts/is-simple-the-only-criterion/很多时候讨论方案，'这个改起来简单'，然后就没有人说话了。简单没有错，问题是简单就是指这一次改动的简单呢？那运维的简单性、扩展的简单性、稳定的简单性、排查的简单性呢？/posts/boundary-compute-storage-network/Sat, 16 May 2026 10:00:00 +0800/posts/boundary-compute-storage-network/拿快照来说，为啥我们支持快照的多链这么复杂？按道理虚拟机只需要一个卷，至于这个卷背后的链是完全不需要关心的。如果计算存储分离，快照局限于存储模块，计算只需要一个卷。/posts/variable-vs-invariable/Sun, 10 May 2026 10:00:00 +0800/posts/variable-vs-invariable/设计模式一个基本点两个原则：一个基本点是找到变化、封装变化；两个原则是基于接口而不是基于实现、组合优于继承。核心是可变与不可变的隔离、解耦。/posts/simple-plus-combination/Sat, 09 May 2026 10:00:00 +0800/posts/simple-plus-combination/《UNIX编程艺术》里讲的：cmd + 管道 + 文本的设计理念，让单个命令足够简单清晰，而命令的编排又可以创造无限扩展的能力。单元简单，才容易组合。/posts/ha-fence-essential/Sun, 03 May 2026 10:00:00 +0800/posts/ha-fence-essential/稳定性相关的，要么不做，要么就要完善，要不然做了高可用，反而造成雪崩。高可用必备 fence，fence 就是 ipmi 强制关机，这是最稳妥的方式。/posts/state-machine-around-state/Sat, 02 May 2026 10:00:00 +0800/posts/state-machine-around-state/状态机的核心是围绕状态，而不是围绕具体流程。当前状态、输入、转移状态，就是围绕着三要素设计的。它可以把一个超长流程、超多条件判断的流程，解耦为一个个独立的状态。/posts/forward-easy-rollback-hard/Sun, 26 Apr 2026 10:00:00 +0800/posts/forward-easy-rollback-hard/当流程跨越了多个服务，一旦中途某一步失败，如何把已经扭转的状态干净地恢复原状，是软件架构里最重的活。优秀的架构师会尽量避免物理回滚，把流程设计为只能向前。/posts/oop-vs-procedural/Sat, 25 Apr 2026 10:00:00 +0800/posts/oop-vs-procedural/流程是易变的、脆弱的，对象是稳定的、高内聚的。面向对象的流程是分治，将易变的流程拆分成多个稳定的对象，对象之间面向接口协作，复杂性拆分成局部复杂性。/posts/decision-tree-vs-layer/Sun, 19 Apr 2026 10:00:00 +0800/posts/decision-tree-vs-layer/决策流程这个场景，适合树而不是层。树是前后依赖的，层是前后不依赖的、每一层是通用的。规则引擎天生就是规则流，前后有依赖，所以写规则配置就是树的方式。/posts/mq-advantage-over-direct-message/Sat, 18 Apr 2026 10:00:00 +0800/posts/mq-advantage-over-direct-message/mq 不仅是削峰填谷，也不仅是解耦服务，还有降低代码复杂性、增加稳定性的作用。中间件是一个稳定的、没有逻辑的、仅仅存储数据的。/posts/check-and-fix-separate/Sun, 12 Apr 2026 10:00:00 +0800/posts/check-and-fix-separate/check 有很多项，每个项都有修复。check 是一条线，修复是一条线。不要在 check 中发现某个项有问题就进行修复，而是要等 check 完再调用修复。/posts/bottom-single-top-combine/Sat, 11 Apr 2026 10:00:00 +0800/posts/bottom-single-top-combine/底层逻辑尤其要保证单一，一个能力只提供一种方法。想要更多，通过上层组合、上层封装来实现。千万不要把所有需求都放到底层原子能力上。/posts/hook-plugin-middleware/Sun, 05 Apr 2026 10:00:00 +0800/posts/hook-plugin-middleware/Hook 侧重现有流程上运行时的局部修改，插件侧重模块化功能扩展，Middleware 是流程中可以扩展的横切面。三者核心目标都是不侵入主程序的前提下实现扩展。/posts/coupling-key-is-change/Sun, 29 Mar 2026 10:00:00 +0800/posts/coupling-key-is-change/什么是耦合，怎么判断有没有耦合？可以从结果反推：A 变化了，B 要不要跟着变化。如果跟着变，那就是耦合了；如果没有跟着变，或者变动很小，那就是松耦合。/posts/patch-object-oriented/Sat, 21 Mar 2026 10:00:00 +0800/posts/patch-object-oriented/哪里遇到问题了，就找个地方加个开关、加个检查、加个条件判断来处理掉。这导致不够系统化，引入了局部的分支点，会造成多流程的耦合交叉，扩展容易遗漏。/posts/code-consistency-interface/Sat, 14 Mar 2026 10:00:00 +0800/posts/code-consistency-interface/不仅数据有一致性问题，代码的一致性问题更加遍地都是。判断主机是否运行应该面向 libvirt 接口，而不是面向实现中的文件、过程。/posts/interface-oriented/Sun, 08 Mar 2026 10:00:00 +0800/posts/interface-oriented/接口很多时候听起来很有道理，写的时候会质疑是不是为了接口而接口。一写二抄三重构，前面没有必要的时候不用接口，后面重复的时候可以引入接口。/posts/encapsulation-vs-independent/Sat, 07 Mar 2026 10:00:00 +0800/posts/encapsulation-vs-independent/封装仅仅是为了复用，但是独立有管理能力。封装调用了就得执行，独立有自己的一套管理规则，比如排队、限流、调整优先级、丢弃、转换等。/posts/bottom-default-value/Sun, 01 Mar 2026 10:00:00 +0800/posts/bottom-default-value/底层（被依赖者）最好有默认值，上层（依赖者）可以少硬编码。判断不是问题，问题是重复判断；硬编码本身是必须的，问题是重复的硬编码。