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