架构的终极使命，是让所有故事都不发生

Mon, 29 Jun 2026 12:30:00 +0800

一场选型会的典型剧本

会议室里，PPT 翻到第 17 页，架构图已经画到了第四层。

微服务拆分方案、事件驱动总线、CQRS + Event Sourcing、Service Mesh 全栈治理——每多一个组件，在场的人就多兴奋一分。技术负责人激情四射，仿佛不是在搭系统，而是在指挥一场交响乐。

三年后回头看，活下来的系统往往是最无聊的那套：单体应用、关系型数据库、同步调用。

这不是段子。这是过去十年里，反复上演的一幕。

80% 的系统，死在过度设计

先厘清一个事实：绝大多数项目不是死于性能瓶颈，而是死于复杂度失控。

过度设计的典型症状：

症状	表面原因	真实原因
新人入职三个月还不能独立提交代码	业务复杂	架构自嗨，分层过多
一次发布要改六个服务	微服务拆分	边界划分失败，拆了等于没拆
排查一个问题要跳五个中间件	可观测性	引入的组件比业务逻辑还多
系统跑了一年没人敢动	核心链路复杂	只有创始人能解释的设计

业务根本不需要这些。

日活不到十万的系统，用 Kafka 做消息总线，相当于用高铁送外卖。数据量不到千万级就上 ClickHouse，相当于买个仓库只放一双鞋。

不是说这些技术不好，是业务阶段不配。

无聊架构的三条铁律

铁律一：新人第一天就能看懂

真正的高手搭出来的架构，有一个朴素的标准——新人入职第一天就能看懂代码结构。

没有炫技的分层，没有自创的中间件，没有只有创始人能解释的部署拓扑。请求从哪进来，数据存到哪，业务逻辑在哪，一目了然。

反观那些"高大上"的架构：

一个用户注册请求，经过 API Gateway → 用户服务 → 事件总线 → 通知服务 → 邮件 Worker → 审计日志 Collector，六跳。
出了问题？你得先搞懂哪一跳出了问题，然后再搞懂为什么那一跳会出问题。

有句话说得好：代码是写给人看的，顺便让机器执行。架构也一样。

铁律二：无聊意味着可预测

无聊不是贬义词，在工程领域它是最高赞美。

可预测意味着：

输入 A，一定得到输出 B
出了问题，能在五分钟内定位
凌晨三点，不会被告警叫醒

那些"有趣"的架构呢？异步事件满天飞，数据最终一致但不保证顺序，重试机制叠了三层还是偶尔丢消息。每次出问题都像在破案，而且是那种没有监控录像的悬案。

凌晨三点的告警，是对架构最真实的审判。

铁律三：最好的架构是隐形的

一个好的架构不会出现在技术分享会上，不会成为晋升答辩的亮点，不会写进年终总结的"技术突破"那一栏。

但它让团队三年没出过 P0 事故。

“有趣"架构	“无聊"架构
技术分享会的主角	从不上台
晋升答辩的核心亮点	写不出技术突破
出了问题全员排查	出了问题五分钟修复
核心人离职后无人敢动	任何人接手都能跑
三年后开始还技术债	三年后还是那套代码

三个血泪教训

教训一：微服务拆得太早

某创业团队，日活三千，拆了十二个微服务。每个服务独立部署、独立数据库、独立监控。听起来很规范。

结果呢？

一次下单操作要调用四个服务，延迟从 200ms 变成 1.2s
数据库事务变成了分布式事务，Saga 模式写了一千行补偿代码
团队只有六个人，每人要维护两三个服务，精力严重分散

六个人用十二个微服务，不是架构先进，是给自己找活干。

后来全部合并回单体，用模块化分包的方式组织代码。上线速度快了三倍，Bug 少了七成。

教训二：消息队列滥用

一个内部管理系统，日操作量不到一万。架构师引入了 Kafka 做事件驱动。

“解耦！异步！削峰！“选型会上说得很美。

实际上呢？系统从来没有遇到过需要削的峰，从来没有超过 QPS 500 的并发。Kafka 的三个 Broker 常年 CPU 使用率 2%，消息积压为零。

但引入的代价是实实在在的：

消息丢失了要排查 Consumer Group 的 Offset
消息重复了要做幂等处理
消息顺序乱了要加排序逻辑

为了解决一个不存在的问题，引入了三个真实的问题。

教训三：中台化陷阱

某公司花一年搭数据中台，接了八条业务线。理想很丰满：统一口径、统一指标、统一服务。

现实很骨感：

每条业务线的指标定义都不一样，统一不了
中台团队响应速度跟不上业务节奏，业务线开始绕过中台自己搞
中台变成了"瓶颈台”，所有人的请求都排队等它处理

一年后，中台团队从 30 人缩到 5 人，维护一个谁都不用的统一报表系统。

什么时候该用"有趣"的架构？

当然，不是说永远不要用复杂架构。关键判断标准很简单：

当你不用它就真的扛不住的时候。

场景	该用什么	不该用什么
日活 < 10万	单体 + 关系型数据库	微服务 + 分布式数据库
日活 10万-500万	模块化单体或粗粒度服务	细粒度微服务 + Service Mesh
日活 > 500万	微服务 + 消息队列 + 分库分表	继续单体硬扛
峰值 QPS < 1000	同步调用	事件驱动 + 异步补偿
数据量 < 1亿条	MySQL / PostgreSQL	ClickHouse / TiDB

架构的复杂度应该跟着业务的复杂度长，而不是跟着技术人的野心长。

一个反直觉的真相

技术人最容易犯的错误，是把架构当成了作品。

作品要表达自我，要展示能力，要让同行觉得"这哥们水平真高”。但架构不是艺术品，它是基础设施。基础设施的最高境界是——你根本意识不到它的存在。

你每天走在平坦的马路上，不会觉得路面设计有多厉害。但如果路上每隔十米就有一个减速带、一个环岛、一个立交桥，你会疯掉。

架构也是如此。好的架构就是那条平坦的马路，让你把全部注意力放在目的地上，而不是路上。

把精力留给真正值得兴奋的地方

选无聊的架构，不是因为技术人不应该有追求。而是因为技术人最大的追求，应该是解决真正的业务问题。

用户的留存率为什么在下降？
新功能上线两周了，使用率不到 10%？
竞品的某个功能为什么做得比你好？

这些问题，比 CQRS 怎么实现、Service Mesh 怎么配置、分布式事务怎么补偿——重要一万倍。

架构的终极使命，不是让技术人兴奋，而是让所有故事都不发生。没有故障、没有事故、没有凌晨三点的夺命连环 call。

然后你终于可以安心地想一些真正重要的事。

技术管理 on 文艺技术笔记