09 · 架构品味:框架之外,什么在拉开差距
前八章给了你「可教」的部分——框架、模式、流程。但你很快会撞见一个扎心的事实:两个都把框架背得滚瓜烂熟的人,做出来的架构质量却天差地别。 差的那部分,叫品味。这一章讲清楚:品味是什么、为什么它决定了架构的「个性」,以及怎么靠对比真实案例把它一点点养出来。
框架能「教」,品味只能「养」
把前八章比作学写作:框架、模式、流程是「语法和词汇」——它们能保证你写出的句子没有语病。但**「语法全对」和「文章好看」是两回事**。
架构也一样。框架能把你从 0 分带到 70 分(不犯致命错误);但从 70 分到 90 分那一段,靠的是另一种东西:
品味——在框架给出的「好几个都合理的选项」里,选得又准、又美、又适合此时此地的判断力。
注意这个关键洞察:好框架不会给你唯一答案,它会收敛出几个都说得通的候选。 然后呢?选哪个?什么时候该打破常规?——框架到这里就沉默了,接管的是品味。
品味不是玄学,也不是天赋。它是**「见过足够多的好架构、也踩过足够多的烂架构」之后,内化下来的直觉**。好消息是:既然它来自「见多」,那它就可以靠刻意地看、刻意地对比来加速养成。这一章的后半,就教你怎么养。
框架 / 模式 / 流程 品味 / 判断力
─────────────── ───────────────
可以教、可以背 只能养、靠见识
让你「不犯大错」(70分) 让你「做得漂亮」(90分)
收敛出几个合理选项 在合理选项里选对、知道何时破例
有标准答案 没有标准答案,只有「更合适」真相一:同一个问题,没有唯一正确答案
新手最深的执念,是「这道题的标准答案是什么」。而品味的第一课,恰恰是接受:架构没有标准答案。
不信?看两个顶级专家当众唱反调:
- Martin Fowler 写过 《MonolithFirst》(先做单体):几乎所有成功的微服务,都是从一个「长大了的单体」拆出来的;一上来就微服务的,大多陷入泥潭。
- 紧接着,Stefan Tilkov 在同一个网站发表 《Don't start with a monolith》(别从单体开始):对某些注定要分布式的系统,先单体再拆反而是弯路。
两个世界级架构师,在同一个站点上,给出相反的建议——这不是谁错了,而是「答案取决于约束」的最佳证明。
再看两个都被写进教科书的成功者,选择却完全相反:
| Stack Overflow | Netflix | |
|---|---|---|
| 架构 | 单体 + 少量服务器 + 垂直扩展(Nick Craver 的架构剖析:一天 2 亿次请求,却只跑不到十几台 Web 服务器) | 全面微服务 + 全球分布式(几百个服务) |
| 为什么这么选 | 小团队、负载可预测、成本敏感、追求极致简单 | 超大组织、全球弹性、海量并发、团队需独立演进 |
| 结果 | 极其成功 | 极其成功 |
两个相反的选择,都对。 因为它们的约束截然不同。
💡 品味的第一课:架构的「个性」,来自约束的「个性」。
由此推出一条能救命的铁律:抄别人的架构,而不抄它的约束,是灾难。 你看到某大厂用了某套酷炫架构就照搬,却忽略了你和它「团队规模、流量、成本、合规」根本不在一个量级——这是新手最常见、也最致命的「跟风」。
真相二:品味的五个面向(每个都钉在一个真实案例上)
品味听起来很虚,但它其实有几个可以具体观察、刻意培养的面向。
面向 1 · 对「简单」的执着,对「复杂度」的痛感
Rich Hickey 有一个被奉为经典的演讲 《Simple Made Easy》,戳破了一个混淆:
简单(Simple)≠ 容易(Easy)。 简单是「一件事只缠绕一股」(客观的结构);容易是「就在手边、我很熟」(主观的方便)。人们常为了「容易」(用我熟的、能马上上手的),亲手制造了「复杂」(一团缠绕、日后还债)。
品味高的人追求 simple,哪怕它一开始不 easy。 他们看到一个方案,本能反应是「能不能更简单」,而不是「还能加点什么」。
这也是 DHH 在 《The Majestic Monolith》(宏伟的单体)里的态度:对绝大多数 Web 应用,小团队就该把单体做到极致、做得「宏伟」,而不是用「把方法调用换成网络调用」的微服务,凭空给自己制造分布式的苦难。
面向 2 · 不盲从潮流(破除「微服务=先进」的迷信)
这是本章最有冲击力的部分——一串**「打脸潮流」的真实反转**:
- Amazon Prime Video:把视频质量监控系统从「微服务 / Serverless」改回单体,成本直降 90%。(The New Stack 报道;连 AWS 自己的团队都这么干了)
- Segment:《Goodbye Microservices》 —— 把 140+ 个微服务合并回单体,从「平均每天半次宕机」变成「一个工程师几分钟就能部署」。
这些故事的教训不是「微服务错了」(Netflix 用得很好)。教训是:「跟风」错了。
💡 品味 = 能抵抗「显得先进」的诱惑。 当所有人都在喊某个词(前几年是微服务,这两年是各种 AI 架构),有品味的人不问「它潮不潮」,只问「它适合我这个约束吗?代价我付得起吗?」
面向 3 · 把「创新」省着用在刀刃上
Dan McKinley 提出过一个绝妙的比喻 《Choose Boring Technology》(选择无聊的技术):
每个公司只有有限的几枚「创新代币」。每用一个不成熟、不熟悉的新技术,就花掉一枚——因为你要替它踩所有没人踩过的坑。别把代币浪费在「换个时髦数据库」上,把它们省下来,花在你真正的核心竞争力上。
品味体现在:系统的绝大部分,刻意用无聊、成熟、可预测的技术;只在那一两个真正差异化的点上,才舍得花一枚代币去冒险。 通篇都是新潮技术的系统,不是先进,是没想清楚什么才值得冒险。
面向 4 · 知道「何时该破例」
最佳实践、设计原则、各种「军规」,本质是给「还没长出品味的人」的安全网——照着做,不至于摔死。
但有品味的人更进一步:他们懂得每条规则背后的「为什么」,于是也就知道「什么时候这个为什么不成立、该破例」。
- 「不要过早优化」是好规则;但你明知道这条读路径上线就会爆,提前留好缓存的口子——这是有依据的破例。
- 「数据库不要冗余」是好规则;但为了读性能主动反范式(见 05 数据与状态)——这也是破例。
⚠️ 危险的不是破例,是「没搞懂规则就破例」。 没搞懂就破 = 蛮干;搞懂了为什么、也算清了代价再破 = 品味。先成为规则的主人,再做规则的叛徒。
面向 5 · 审美:认得出「丑」,也认得出「流派」
成熟的架构师看一个设计,会像作家看到病句一样本能地「膈应」。常见的「丑」:
- 过度设计的丑:五个人的团队,十几个微服务,每天大半精力在排查「服务间为什么调不通」。
- 抽象泄漏的丑:号称封装好了,用的人却必须懂它内部才能用对。
- 不一致的丑:同一个系统三种命名风格、三种错误处理,像三个人各说各话。
- 「聪明过头」的丑:为炫技用了个谁都看不懂的精巧设计,半年后连作者都不敢动。
这种「膈应感」不是天生的,是看多了「干净的」,自然就认得出「脏的」。
但审美不止是「识别丑」——它还分流派。就像建筑有极简主义也有巴洛克,架构也有不同的审美主张。而当下最有影响力的几种,各大公司就是它们的代言人。看懂这些流派、再决定自己站哪儿,是品味养成的关键一跃。
真相三:大公司的架构审美 —— 以及你该选哪一种
看一家公司的架构,像看一个人的穿衣风格:背后是一整套价值观。下面这几家,代表了当下最有影响力的几种「架构审美」。它们没有高下,只有适配——每一种,都是那家公司独特约束的产物。
| 公司 | 审美内核 | 标志性事实 | 代价 / 适用前提 |
|---|---|---|---|
| Amazon | 服务自治,用接口划清边界 | 2002 年 Bezos「API 命令」:所有团队只能通过服务接口通信,「违者开除」(后来直接催生了 AWS) | 一整座分布式复杂度的山;连它自己都会在 Prime Video 那种场景务实回退到单体 |
| Netflix | 拥抱失败,为弹性而生 | Chaos Monkey / 混沌工程:主动在生产环境随机杀实例,信条是「避免失败的最好办法,是不断地失败」 | 极高的工程投入,只有「超大规模 + 高可用是生命线」才撑得起 |
| 工程严谨,为 planet-scale 统一基建 | 自研 Borg(Kubernetes 的前身)、Spanner、Bigtable——一切为超大规模一次性解决好 | 极重;非 Google 量级硬学,就是邯郸学步 | |
| Shopify | 单体的简单 + 模块的纪律 | 280 万行 Ruby 的「模块化单体」,靠模块边界而非拆服务来管理复杂度 | 要靠纪律守住边界;但它把「要不要拆」健康地推迟到了真有必要时 |
| 37signals / Basecamp | 极致克制,少即是多,敢逆潮流 | Majestic Monolith + 2023 年高调「下云」自建机房,预计五年省 $10M+ | 需要反潮流的定力;为小团队的效率与成本极致优化 |
| Stack Overflow | 性能极客,用最少的机器做最多的事 | 一天 2 亿次请求,却只跑不到十几台 Web 服务器:垂直扩展 + 单体 + 疯狂缓存 | 鄙视「用加机器解决一切」;要求对性能的极致较真 |
看出门道了吗?右边三家(Shopify / 37signals / Stack Overflow)和左边两家(Amazon / Netflix),审美几乎相反——前者拥抱简单、单体、克制,后者拥抱分布式、服务化、为极端规模主动冗余。但它们全都极其成功。 因为审美是约束的产物:Netflix 要扛的是全球弹性,Basecamp 要的是小团队的幸福。
那么,你该选哪种审美?
这是你最该关心的问题,答案很明确:
绝大多数个人开发者和小团队,应该向 37signals / Stack Overflow / Shopify 这一端靠拢,而不是 Google / Netflix。
原因很简单:你的约束,长得像 Basecamp,不像 Netflix。 人少、要快、预算有限、负载远没到「全球弹性」的程度。Google / Netflix 那套审美,是为它们的超大规模和超大组织长出来的;你硬套,就是穿一件不合身的华服——又贵、又累、还不好看。
所以,给个人 / 小团队的「默认审美」,记住这五条:
- 单体优先(模块化单体)。除非组织真的大到互相阻塞,否则别碰微服务——记住 Prime Video 和 Segment 都「回来」了。
- 选无聊技术。 把有限的「创新代币」省下来,只花在你真正的差异化上。
- 对复杂度有洁癖。 每加一个组件 / 服务 / 抽象层,先问「不加会死吗」。
- 垂直扩展优先。 在很长一段时间里,「加配置」比「加机器 + 搞分布式」更便宜、更简单(Stack Overflow 就是活证据)。
- 「简单」永远压过「显得先进」。
💡 审美要「向下兼容」:先掌握最简单的那一档,只在被逼到墙角时才升级。
大多数项目的悲剧,正是用 Netflix 的审美,去做 Basecamp 体量的事。等你的约束真的变了(团队几百人、流量全球、组织开始互相踩脚),你自然会向 Amazon / Netflix 那端移动——而且到那时,你已经有足够的品味,知道该怎么移、移多少。
一句话:先学会 Basecamp 的克制,才有资格谈 Netflix 的复杂。
怎么把品味练出来(可操作的五件事)
品味来自「见多识广 + 刻意反思」。下面五件事,从今天就能做:
- 大量读真实架构。 先把本仓库 21 个模板 当地图读透,再去读一手工程博客——这几个源值得长期订阅:
- 刻意对比同类系统。 挑两个做同类事的产品,逼自己列出它们架构的不同,然后回答那个最关键的问题:「这个差异,来自它俩什么约束的不同?」 —— 这正是本仓库模板的正确用法。
- 给每个决策做「事后复盘」。 三个月后回看当初的取舍:对吗?哪个假设错了?代价如我所料吗?(这就是 08 ADR 的价值——它让复盘有据可查。)
- 培养对复杂度的「痛感」。 每次想加一个组件 / 服务 / 抽象层,先逼自己回答:「不加它,会死吗?」 答不上「会死」,就先别加。
- 专门读「反转 / 打脸」故事。 像本章这些「微服务回单体」的案例,是校准你「潮流免疫力」的最好疫苗——它们让你对「人人都说好的东西」多一分健康的怀疑。
一个立刻能做的练习: 打开 社交信息流模板,然后想:Twitter 和一个只有几万人的小众兴趣社区,Feed 架构会一样吗? 如果不一样,差异来自哪个约束?(提示:规模、热点分布、实时性要求……)能把这个说清楚,你就在用品味思考了。
本章小结
- 框架让你不犯大错(70 分),品味让你做得漂亮(90 分)。 框架可教,品味只能靠「见多 + 反思」养。
- 架构没有标准答案。 Fowler 和 Tilkov 公开唱反调、Stack Overflow 和 Netflix 反向选择都成功——架构的个性来自约束的个性,抄架构不抄约束是灾难。
- 品味的五个面向:① 执着于简单、对复杂度有痛感(Rich Hickey、DHH);② 不盲从潮流(Prime Video、Segment 的微服务回归);③ 把创新代币省着花(Choose Boring Technology);④ 搞懂规则后才知道何时破例;⑤ 能一眼认出「丑」。
- 架构审美分流派,而你该选「克制」那一端。 Amazon / Netflix(分布式、为极端规模冗余)与 37signals / Stack Overflow / Shopify(单体、极致克制)审美相反却都成功;个人和小团队默认向后者靠拢——单体优先、无聊技术、对复杂度有洁癖。先学会 Basecamp 的克制,才有资格谈 Netflix 的复杂。
- 练法:多读真实架构、刻意对比同类系统、给决策做事后复盘、对复杂度保持痛感、专读反转故事。
这是整套教程的最后一章,也是真正的起点。
还记得 01 章 说的吗:写代码正在消失,判断力越来越值钱。而判断力的最顶层,就是这一章讲的品味——它没有终点,会随你见过的每一个系统一起生长。
所以,合上教程,去读、去对比、去复盘吧。框架我们已经交给你了;品味,要你自己用一个个真实的系统去喂养。
👉 从这里出发:挑一个 模板 开始拆,或者用 architecture-copilot 让 AI 陪你把下一个项目的架构,认认真真讨论一遍。