架构

一句话

你以为架构的问题是「该选什么技术、要不要上微服务」，这一章用数据把问题换了个问法：系统属于哪一类（大型机、套装软件、嵌入式、全新绿地）几乎不预测交付效能，能不能独立测试、能不能独立部署才预测。架构的产出不是一张拓扑图，而是一个可观测的组织事实——一个团队能不能不求人就把活从设计干到上线。这也是《Accelerate》全书里对「加人为什么不提速」给出的正面答案。

Glossary · 术语表

坐标

本章是 Part I「研究发现」的第 5 章：上承第 4 章（技术实践把持续交付拆成可测量的能力），下启第 6 章（把安全融入交付）。它回答的是第 4 章留下的那个尴尬问题——道理都懂，可我们的系统根本不允许我们那么干，怎么办。对应现实里，它正是「单体还是微服务」「要不要建平台团队」「加了人为什么反而更慢」这类争论的实证底本；今天 DORA 把它固化成了两条独立能力条目：松耦合架构 与 松耦合团队。

这章要解决什么

第 4 章的结论很硬：每天并回主干、可靠的自动化测试、随时可发的主干，这些能力驱动效能。但一个真实团队的日常常常长这样——改一行配置，要先申请那套全公司唯一的集成测试环境（排队 3 天），环境里另一个系统正好坏着（再等 2 天），测完还要等每月一次的发布窗口，窗口当晚 7 个团队一起上线，出事了先花两小时确认是谁的问题。在这种结构里，「每天部署一次」不是纪律问题，是物理上不可能。

所以本章的问题是：持续交付有没有前置条件？如果有，是不是「你得是家新公司、做的是新系统」？它直接决定了两类流行说法成不成立：「我们不适用论」（我们守的是跑了二十年的大型机核心 / 买来的套装软件 / 设备里的固件，那套东西是互联网公司玩的）和「上微服务就好了」（拆成服务，速度自然上来）。

不回答会怎样？两种浪费各走一边：前者用「行业特殊」把自己锁死在年度发布里；后者花两年把一个单体拆成 80 个服务，然后发现这 80 个服务还是必须一起测、一起发——付了分布式的全部代价，一次都没享受到独立发布的好处。本章要做的，就是把「架构好不好」从审美之争变成两条可打分、可与效能做统计检验的具体特征。

核心内容，讲透

一、最反直觉的发现：系统类型几乎不重要

研究把受访者做的系统分成许多类：全新绿地系统、面向用户的交互型系统、账目类记录型系统、自研软件、由另一家公司开发的定制软件、买来的套装商业软件（COTS）、跑在自建数据中心里的软件、装在用户设备上的软件、嵌入在硬件产品里的固件、以及大型机（mainframe）软件。然后问：哪一类更容易进高效能组？

答案是：基本上，哪一类都行。系统类型与交付效能之间没有出现显著差异——做大型机的团队照样可以是高效能团队。这一条直接反驳了当时流行的双模 IT（bimodal IT）主张：把「快的创新系统」与「慢的记录系统」分成两种速度分开管理。本书的数据说，慢不是记录型系统的宿命，而是架构与实践的结果。

但有两个例外，它们恰好指向同一个机制：低效能组更可能在做「由另一家公司开发的定制软件」（即外包），也更可能在做大型机系统。注意分寸——这不是说外包团队水平差、大型机技术不行，而是这两种情形通常伴随同一个特征：你需要的改动，控制权不在你手上。代码归另一家公司，或变更必须走另一套审批与排期，牵动的人就多了。本章真正在测的从来不是技术，而是牵动的人有多少。

二、两条判据：可测试性与可部署性

本章把架构操作化成了两个几乎是白话的问卷条目，任何团队都能当场自答：

• 「我们能在不需要集成环境的前提下，完成大部分测试。」
• 「我们能够、并且确实在独立于其所依赖的其他应用 / 服务的情况下，部署或发布我们的应用。」

注意第二条里那个容易被跳过的词——「并且确实在」（can and do）。架构上「理论上可以独立发」但实际上从来都是跟着大部队一起发，不算数。这是本章最锋利的一刀：它测的是既成事实，不是设计意图。很多号称已经微服务化的组织，正是死在这半句上。

这两条为什么这么灵？因为它们卡住了持续交付的两个瓶颈。可测试性决定反馈有多快：在自己机器上用测试替身跑完的检查是分钟级，必须排队进集成环境的检查是天级；反馈从分钟退化成天，团队就会本能地攒一批改动再测，批量变大，又回到第 4 章那条超线性上涨的冲突曲线。可部署性决定批量有多大：只要必须和别人一起发，你的部署批量就等于所有人的改动之和，一旦出事，第一件事不是修，而是先花时间确认是谁的问题。

三、架构的另一半是团队：能不能不求人就把活干完

架构与团队边界是同一件事的两面（这正是 Conway 定律的现代表述）。本章的「松耦合」判据，除了上面两条技术特征，还包括一组关于自主权的条目——一个团队能不能：

• 不必获得团队外部的许可，就对自己系统的设计做大幅修改；
• 不必与团队外做细粒度的沟通协调，就完成自己的工作；
• 不给其他团队制造大量额外工作，就完成自己的变更；
• 按需部署 / 发布自己的产品或服务，与它依赖的其他服务无关；
• 按需完成大部分测试，不需要一个集成测试环境；
• 在正常工作时间做部署，停机时间可忽略不计。

最后一条常被当成琐碎细节，其实是整组判据的试金石：只敢周六凌晨发布，正是因为既不能独立验证、又必须和别人一起发——白天出事牵连面太大。「敢不敢在周二下午三点上线」，是一个不用看架构图就能读到的耦合读数。

还要注意：这套判据里没有一条要求你把系统拆成几十个服务，它们全都在问同一件事——办成一件事要牵动多少人。所以本章反对的不是单体，而是把「必须一起动」制度化的一切安排：唯一的集成环境、统一的发布列车、跨系统的联合验收、必须走别人排期才能做的变更。

四、为什么这件事决定了「加人到底有没有用」

本章最有杀伤力的一张数据，是把每位开发者每天的部署次数放在纵轴、团队开发者人数放在横轴：

• 高效能组：随人数增加而上升——加人换来了更多产出；
• 中等组：大致持平——加人只是等比例加产出；
• 低效能组：随人数增加而下降——加人反而拖慢了每个人。

这解释了《人月神话》那条老结论在今天的作用机制：紧耦合系统里，沟通路径数量随人数近似平方级增长（n 个人两两之间是 n(n-1)/2 条路径，白话说——人翻一倍，要对齐的关系接近翻四倍）。松耦合把这张全连通的网切成若干小组，组内高带宽、组间只走接口，新增的人于是被吸收进某个小组，而不是摊进全局协调网。这条曲线也是最实用的自检工具：团队从 20 人涨到 60 人而交付速度没变快，那不是招错了人，是架构到顶了。

五、架构师该盯什么：工程师与结果，而不是工具与技术

本章有一节专门写给架构师和技术管理者，结论扎人：架构师应该关注工程师与结果，而不是工具与技术。一件工具再先进，如果用它的人讨厌它、或者它并没带来我们真正在意的那些结果（能独立测、能独立发），它就是无关变量。与之配套的发现是：能自己选择工具的团队，持续交付做得更好，进而交付效能也更好——工具趁不趁手，只有天天用它的人有第一手信息。

这条最常被误读成「随便用什么都行」，所以要补上分寸：它反对的是由远离一线的中央小组统一指定，不是反对一切标准。务实的平衡点通常是：基础设施与安全基线统一（否则每个团队都在重造运维），语言与框架尽量留给团队；任何标准都以「它是否让团队更能独立测、独立发」来评判。

实现手段上，本章点到的都是常规牌：用限界上下文与 API 把大领域切成松耦合的小单元，用测试替身与虚拟化让服务能被隔离测试。共同点是——都在减少「必须凑齐才能干活」的场合。

关键权衡与选型

本章的两条判据是目标，不是方案。达成它的手段有好几种，代价各不相同；选错的典型后果，就是那个大家都听过的「拆了两年，发布还是一个月一次」。

表 1 · 四种常见形态：谁真正拿到了独立测 / 独立发

表 2 · 症状 → 根因 → 该动哪里（把两条判据落成体检表）

表 3 · 工具与技术选择：中央统一 vs 团队自选

一条排序建议：先做可测试性，再做可部署性。能独立测但暂时还一起发，你至少拿到了分钟级反馈；反过来，能独立发却测不了，等于把没验证过的东西更快地推向生产——这不是提速，是加速踩雷。

为什么重要 / 落到真实系统

这一章是「微服务之争」里最值得反复引用的一段实证，因为它把标准从形式（拆了几个服务）挪到了结果（能不能独立测、独立发）。今天 DORA 把它固化成两条能力——松耦合架构与松耦合团队——供团队自评；它也是「平台工程」的底层理由：平台的价值不在统一了技术，而在让业务团队少求人。

面试高频题「你会把这个单体拆成微服务吗」，本章给的是反问模板：现在哪一步必须凑齐所有系统才能做？发布要牵动几个团队？拆完这两条会变好还是变坏？——说得出「拆完仍然要一起发，所以先不拆，先去掉集成测试的依赖」的人，比背得出微服务优点列表的人深一层。

易错点与争议

• 把本章读成「微服务万岁」。全章没有一条判据要求你拆服务。它要的是可独立测试与可独立部署——模块化良好的单体同样能拿分，而拆成 200 个服务却必须一起发的，一分都拿不到。
• 忽略「并且确实在」这半句。问卷问的是 can and do：设计上能独立发、实际却总跟着大部队发，不算数。这是本章防自欺的关键措辞。
• 把「系统类型不重要」读成「技术选择不重要」。结论是系统所属类别不预测效能，不是说用什么数据库、怎么设计都无所谓——只是这些选择要按「是否增强独立测 / 独立发」评判，而不是按时髦程度。
• 把外包与大型机的那条例外读成鄙视链。数据指向的机制是控制权与协调成本，不是从业者的水平；同样受制于外部排期的自研团队，一样会掉进低效能组。至于「团队自选工具」也不等于无政府：反对的是远离一线的中央指定，不是反对一切标准。
• 拆分的代价被系统性低估。本章对此处理得诚实但不详尽：解耦会把复杂度从「代码里」搬到「网络里」——分布式事务、版本兼容、可观测性、故障定位都是新增的长期成本。Segment 与 Uber 的公开复盘，正是这笔账的实价。
• 方法论上的老问题（全书通病）：结论来自自愿参与的行业问卷、指标为受访者自报，作者用潜变量建模与推断性预测分析支撑方向性主张，强于单纯相关，但仍不是随机对照实验。尤其「架构 → 效能」的方向，反向因果（高效能团队更有余力去改架构）在现实中几乎必然同时存在。
• 时代局限：成书于 2018 年，服务网格、平台工程、单体仓与 monorepo 工具链、以及后来「模块化单体」的回潮都还没充分展开。但两条判据本身经受住了这些变化——它们问的是结果，而不是形式。

要点