09 · 架构品味:框架之外,什么在拉开差距
前八章讲的是可教的部分:框架、模式、流程。但你很快会撞见一个扎心的事实:两个都把框架背得滚瓜烂熟的人,做出来的架构质量却天差地别。差的那部分,叫品味。这一章讲清楚品味是什么,为什么它会决定架构个性,以及怎么靠对比真实案例把它一点点养出来。
框架能教,品味只能养
把前八章比作学写作,框架、模式、流程就像语法和词汇。它们能保证句子没有语病,但语法全对和文章好看是两回事。
架构也一样。框架能把你从 0 分带到 70 分,让你不犯致命错误;但从 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 说的是就在手边、我很熟。很多人为了马上上手,选择自己熟悉的东西,结果制造了日后要还债的复杂度。
品味高的人追求 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 / Basecamp、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 的复杂。
怎么把品味练出来,可操作的五件事
品味来自见多识广和刻意反思。下面五件事,从今天就能做:
- 大量读真实架构。 先把本仓库 26 个模板 当地图读透,再去读一手工程博客。这几个源值得长期订阅:
- 刻意对比同类系统。 挑两个做同类事的产品,逼自己列出它们架构的不同,然后回答那个最关键的问题:这个差异,来自它俩什么约束的不同?这正是本仓库模板的正确用法。
- 给每个决策做事后复盘。 三个月后回看当初的取舍:对吗?哪个假设错了?代价如我所料吗?这就是 08 ADR 的价值,它让复盘有据可查。
- 培养对复杂度的痛感。 每次想加一个组件 / 服务 / 抽象层,先逼自己回答:不加它,会死吗?答不上会死,就先别加。
- 专门读反转故事。 像本章这些微服务回单体的案例,是校准你潮流免疫力的最好疫苗。它们让你对人人都说好的东西多一分健康的怀疑。
一个立刻能做的练习: 打开 社交信息流模板,然后想:Twitter 和一个只有几万人的小众兴趣社区,Feed 架构会一样吗?如果不一样,差异来自哪个约束?提示可以从规模、热点分布、实时性要求这些角度入手。能把这个说清楚,你就在用品味思考了。
🎯 随堂检验
- A跟着学 Netflix,大厂的架构一定更先进
- B个人/小团队默认向克制靠拢:单体优先、无聊技术、对复杂度有痛感——先问约束是否真需要那套
- C折中:先上 5 个微服务,剩下以后再说
本章小结
- 框架帮你从 0 到 70 分,品味决定 70 到 90 分。框架可教,品味只能靠见多和反思养。
- 架构没有标准答案。Fowler 和 Tilkov 公开唱反调、Stack Overflow 和 Netflix 反向选择都成功,说明架构的个性来自约束的个性,抄架构不抄约束是灾难。
- 品味的五个面向:执着于简单、对复杂度有痛感;不盲从潮流;把创新代币省着花;搞懂规则后才知道何时破例;能一眼认出丑。
- 架构审美分流派,而你该选克制那一端。Amazon / Netflix 强调分布式和极端规模冗余,37signals / Stack Overflow / Shopify 强调单体和极致克制,两边审美相反却都成功。个人和小团队默认向后者靠拢:单体优先、无聊技术、对复杂度有洁癖。先学会 Basecamp 的克制,才有资格谈 Netflix 的复杂。
- 练法:多读真实架构、刻意对比同类系统、给决策做事后复盘、对复杂度保持痛感、专读反转故事。
这是整套教程的最后一章,也是真正的起点。
还记得 01 章 说的吗:写代码正在消失,判断力越来越值钱。而判断力的最顶层,就是这一章讲的品味。它没有终点,会随你见过的每一个系统一起生长。
所以,合上教程,去读、去对比、去复盘吧。框架我们已经交给你了;品味,要你自己用一个个真实的系统去喂养。
👉 从这里出发:挑一个 模板 开始拆,或者用 architecture-copilot 让 AI 陪你把下一个项目的架构,认认真真讨论一遍。
💬 评论