拆解一个复杂系统
从边界和输入输出入手，而不是从细节开始
帮我拆解 [系统名称]，例如 [具体例子]。按顺序做：1）先划边界，什么在里面、什么在外面；2）列出输入、输出和它要维持的目标；3）拆成 3–6 个子系统，说明各自职责和彼此接口；4）指出瓶颈或单点故障在哪；5）用一个具体场景走一遍流程，标出我容易忽略的环节。信息不足的地方直接说不确定，不要编。
使用建议
拿一个你熟悉的系统先让它拆一遍，再对照新系统，结构感来得更快。
适合什么场景
- 接手一个别人搭的系统，要在两小时内形成能开始排查的心智模型时
- 系统开始变慢或来了新需求，你说不清改动会牵动哪些部分时
不适合的场景
- 这是公司内部系统、模型没有任何可靠信息，它会一本正经编出架构和组件名时
- 系统小到十分钟能读完代码，或者你只需要某个确切的配置项时
示例
输入
系统：Kafka 集群，沿一条从生产者写入到消费者读取的主链路。
你会得到
边界应划在「Kafka 负责持久化与副本，不负责业务语义」。子系统拆成网络层、日志存储、控制器、副本同步、消费组协调五块，并说明彼此的接口。瓶颈通常落在单分区顺序追加与 ISR 同步；单点故障在旧架构是 controller（依赖 ZooKeeper）。走场景时要标出「acks=all 的延迟由最慢的 ISR 决定」这类容易忽略的环节。
常见误用
- 一上来就问细节（rebalance 协议怎么工作），没有边界和输入输出，细节无处安放，看完还是散的
- 把它的输出当真实架构图去汇报——里面可能有它按常见设计补出来的、你的系统里并不存在的组件
可以这样改
- 把顺序倒过来：先走一个具体场景，再让它反推需要哪些子系统，更容易发现缺件
- 加一句「如果要扛十倍流量，最先崩的是哪一环、为什么」，把静态拆解变成容量推理