春与秋其代序

在很多系统里，“兜底”被视为一种美德： 接口失败了，兜底 下游超时了，兜底 数据不一致了，兜底 状态异常了，兜底 看起来系统非常“健壮”。...

几乎每一次真正难解的线上问题，都会走到一个相同的死胡同： 这句话一旦出现，排查就会变得异常艰难。 因为它意味着一件事： 一、一个真实到令人不安的场景 你在排查一个偶发问题....

在后端世界，有一种东西特别昂贵， 但很少有人意识到它的成本： 一、一个被无数次验证的现象 几乎每一次严重线上事故， 复盘时都会听到类似的话： “这块逻辑我们一直这么用” “...

几乎所有团队都会说： 但这是一个非常危险的错觉。 真实情况是： 系统复杂度并不是线性增长的，而是长期被压缩、突然释放的。...

后端圈子里，有一类设计特别容易获得掌声： 架构图画得很漂亮 抽象层次分得很清 接口命名非常“规范” 模块边界看起来很干净......

很多系统真正走向失败的那一天，并不是： 服务挂了 数据丢了 用户进不来 而是某一天，你意识到： 但奇怪的是，它还在跑。...

一个奇怪但真实的现象 很多团队都会遇到这种情况： 老系统跑得很稳 代码结构看起来也不算乱 单元测试有一些 接口文档也齐全 但新同事一上手，就必写 bug。...

一个你一定听过、但从没人敢拆穿的说法 在系统设计评审会上，我们经常会听到这些话： “这个先预留一下，后面再决定” “现在先写死，等业务清晰了再抽象” “先用配置，未来再升级...

一个残酷事实：绝大多数系统不是死于事故，而是死于日常 我们总喜欢复盘事故： 双 11 扛不住 大促雪崩 Redis 打满 数据库锁死 但如果你认真看一家公司 3～5 年的系...

一个反直觉结论：大多数性能优化，都是无效劳动 很多系统的性能优化流程是这样的： 压测 找慢 SQL 加索引 加缓存 扩机器 看起来非常专业，但结果往往是： 初期有提升 一段...

很多开发调性能时会问： 这些当然重要，但它们不是最可怕的。 真正危险的是那些 你看不见、监控也不会主动告诉你、只有在特定场景下才出现的“时间偷窃者”。...

凌晨 2:14，我正在为一个无关紧要的线上优化写代码，突然手机 滴—— 地震了一下。 「紧急：审批系统某区域出现大量处理失败，请立即查看。」...

为什么很多系统越做越大，数据越不可信？ 典型表现： 同一个字段在不同服务意义不同 接口传参随意扩展，没有版本管理 上游改了数据格式。...

一个被反复踩坑的真实问题：业务状态越加越乱 在绝大多数后端项目里，你一定见过这样的状态定义： 随着业务扩大，状态从 5 个 → 20 个 → 40 个。...

为什么你的系统看起来没问题，但一上高峰就卡？ 我参与过无数线上事故，发现一个共同点： 线程抢锁 线程抢 CPU 队列抢容量 请求抢 Redis 写入抢 DB 锁 消费者抢同...

先讲一个真实事故 几年前，一家公司做年终活动，优惠券服务压力暴涨。 它是这样设计的： 下单 → 调用“优惠券服务”扣券 若优惠券服务失败 → 返回错误 看似没问题......

为什么异常管理是大型系统的“底层能力”？ 大多数后端开发者对异常的理解是： try-catch 记录日志 抛业务异常 但对大型系统来说，这远远不够......

为什么系统越优化越慢？ 在我参与过的十几个企业项目中，几乎每一个系统都经历过这样的阶段： 用户量稍微增加 → RT 飙升 新功能上线 → 出现“性能雪崩”...

为什么“批处理”和“请求合并”是高性能系统的隐形神器？ 高并发场景下，许多请求其实是重复的 大量热点 key 的请求被重复访问 如果能合并成一条请求，系统压力可减少 90%...

为什么动态分片是分布式系统的“终极技能”？ 绝大多数系统一开始都不会考虑分片 当数据量上涨后，才发现： 库表扩容、热点分布不均、租户倾斜、读写压力不均衡...