随笔 · 架构

做了五年后端，关于系统设计我学到的五件事

JJokerChou 2026.05.20 约 7 分钟

技术会过时，框架会换，但有些东西五年里一次次被验证。它们不是具体的"怎么写"，而是怎么想。下面五件，是真正塑造我做系统的方式的原则。

1先搞清楚"现在的问题是什么"，再谈方案

我见过太多"提前焦虑"：系统才日活几百，就按百万 QPS 设计，引入一堆中间件，结果维护成本把自己压垮。

💡 原则：架构跟随痛点演进，而非预测。当前不痛，就别为想象中的未来买单。等到真实瓶颈出现，再有的放矢地解决——那时你已有数据、有上下文，方案会准得多。

刚入行喜欢炫技：一个接口塞满设计模式、用最"高级"的并发模型。后来才懂，能让人一眼看懂的代码，故障率最低。

// 与其写一段"巧妙"的链式反射，不如：
if (order == null) return emptyResult();  // 一眼看懂

单体时代，调用失败≈写个 bug。分布式时代，网络、下游、数据库随时会抽风，失败是常态而非异常。

💡 把"它会失败"写进设计，而不是等告警响了再补。容错不是事后补救，是默认前提。

没有日志、没有指标、没有链路，系统就是个黑盒。出了事只能靠"猜"。

一次线上抖动，我靠 traceId 串起全链路 + P99 指标，10 分钟定位到一个被忽视的慢 SQL；而三个月前同样的问题，我们查了整整一下午。

技术问题的尽头，常常是人的问题。接口契约没对齐、需求理解有偏差、owner 不清，比代码 bug 更贵。

五年里换过语言、框架、公司，但这五条几乎没变：跟着痛点走、宁可简单、假设会失败、把系统照亮、把人理顺。技术会老，这些思维方式不会。与其追下一个新框架，不如先把这几件做扎实——它们会陪你走更远的路。