架构师和高级开发到底差在哪？47 份 ADR、3 次翻车之后我的答案
2021 年 11 月 17 号凌晨两点半，我被电话叫起来。睡在公司三楼的沙发上，手机屏幕亮着，值班同学说订单库的 P99 从 90ms 爬到 1800ms，HikariCP 连接池打满。数据库是 32C64G 的 MySQL 8.0，订单主表 800 多万行。
问题修起来只花了 40 分钟——把 maximumPoolSize 从默认的 10 调到 20，加了两个索引，重启。真正让我难受的是第二天的复盘：这个连接池配置，三个月前有人在评审会上提过。但没人记得当时为什么没改，会议纪要没写，微信群翻了两小时，最后只翻出来一句「当时说先这样吧」。
那之后我开始写 ADR（Architecture Decision Record）。三年多，47 份，换了两家公司。今天想聊的不是 ADR 怎么写——网上模板一搜一大把——而是我从这堆文档里看出来的事：架构师和高级开发的差别，其实不在技术深度上。
一、架构师的产出不是架构图，是「可以被反驳的决策」
大部分人对架构师的理解是「高级开发 + Visio」。画一张微服务架构图，方框、箭头、颜色分区，交付。
问题是，图回答不了「为什么」。为什么是 4 个服务不是 7 个？为什么选 Kafka 而不是 RabbitMQ？为什么订单和库存要分库？
回答不了的东西，半年后就没人敢动了。新人进来看到那张图，第一反应不是理解，是害怕——谁知道拆掉会炸什么。
ADR 这个概念最早是 Michael Nygard 2011 年 11 月在那篇《Documenting Architecture Decisions》里提的，模板朴素得有点寒酸：标题、状态、背景、决策、后果。文件放在仓库 docs/adr/ 目录下，命名成 0001-use-postgresql.md 这样递增，只增不改，改主意就写一份新的，把旧的 Status 标成 Superseded by 0007。
我们在团队里加了两栏，一栏叫「谁拍的板」，一栏叫「失效条件」。第二栏最折磨人。比如我们第 12 号 ADR 的失效条件写的是：「当单日订单量稳定超过 200 万单，或者库存表超过 5000 万行时，重新评估分库分表方案。」写这个的时候你得在纸面上承认自己不知道未来，而且要给出一个能被别人拿来打你脸的数字。
我见过的大部分架构师（包括前几年的我），宁愿花三天画一张漂亮的图，也不愿意花两小时写清楚一个决策。因为画图有即时反馈，写决策记录只有延迟的、可能永远不会到来的反馈。
二、第二层差别：谁定义约束
技术选型的自由度，是被约束框死的。
我带的第二个团队，9 个人，负责一条交易链路。当时产品给的 SLA 是：下单接口 P99 小于 300ms，日均订单 40 万，大促峰值按 8 倍算。这条线一划，很多东西就不用吵了——不可能上强一致分布式事务，跨服务扣减必须走消息最终一致；同步调用链不能超过 3 跳；Redis 单实例的写入量要卡在 8 万 QPS 以内，留 20% 余量。
这些数字不是我拍脑袋来的，是把产品、运维、DBA 拉到会议室，一项一项吵出来的。吵这个过程很烦，但吵完一次，后面半年都省事。
高级开发关注的是「这个接口怎么写才不慢」。架构师要先回答「这个接口慢到什么程度算事故」。
我自己的经验是，一个项目开工前如果没有一份写死的、带数字的约束清单，那它进入上半年之后一定会变成「什么都想优化，什么都优化不完」。清单至少要有这几项：峰值 QPS 和 P99 目标、数据增长速率（每天多少行、保留多久）、可接受的最大停机时间、团队人数和迭代节奏、每月云成本上限。最后一项经常被忽略，但它是杀伤力最大的约束。
三、康威定律不是段子，是你每天早上要面对的现实
Melvin Conway 1968 年在《How Do Committees Invent?》里写的那句话被引用烂了，但我第一次真切感受到它，是 2022 年春天。
当时我们有 9 个人，业务上拆成了 4 个微服务：交易、库存、支付、通知。看起来挺合理。结果三个月后，发布节奏变成了这样——支付服务一天发 3 次，库存服务两周发一次，因为库存小组只有 2 个人，而且是兼职维护通知服务。
合并代码的时候，库存的同学要同时开三个仓库，改一个库存字段要改三处。我们在 Kafka 里加了 12 个分区来做解耦，实际上有 9 个分区常年空转。
最后不是技术方案解决了问题，是组织调整：把通知并回交易组，库存组补到 3 个人，服务从 4 个合并回 3 个。改完以后，跨团队评审会议从每周 2 小时降到每两周 1 小时。
服务拆分粒度应该跟着团队规模走，这句话听起来像废话，但真正做的时候，90% 的人是先定技术方案，再回头看看谁来做。顺序反了。
我的土办法：画架构图之前，先在纸上写清楚每条主链路上有几个团队、每个团队几个人、他们几点下班。技术方案要适配这个现实，不是反过来。
四、我见过的三种「假架构师」
第一种是「PPT 架构师」。做过最多三个线上系统，但能讲清楚所有中台概念，架构图永远有四层配色。问他「你这个方案上线后谁来值班」，他愣住。
第二种是「技术选型架构师」。对每个新框架都熟，每次开会都能提出至少一个新组件。他们的架构图里组件数量一直在涨，从来没减过。我见过一个日均 20 万请求的系统里塞了 Elasticsearch、ClickHouse、Flink，实际用到的功能不到 10%。
第三种最难识别，「老黄牛架构师」。代码写得漂亮，线上问题解决得快，团队离不开他。但从来不写决策记录，不做技术规划。他休假两周，团队就停在原地。这种人其实是被架构师这个 Title 困住的高级开发，而且他自己往往不觉得。
这三种我或多或少都沾过。第二种沾得最多，大概有两年时间，我判断一个方案好不好的标准是「用了多少新技术」。
五、如果明天就要开始，我会按这个顺序做
-
先在主仓库建 docs/adr/ 目录，把最近三个月做过的技术决策倒着补一遍。不用多，先写 5 份。模板用 Nygard 那版，加「失效条件」一栏。文件名用 0001-xxx.md，四位数字，英文短横线。
-
画 C4 模型，但只画 Context 和 Container 两层。Simon Brown 的 C4 有四层，我实测下来，Component 和 Code 两层画完基本没人看，只在交接或者审计的时候翻一翻。工具用 Structurizr DSL，文本描述，能进 Git，比拖拽工具强太多。
-
加自动化边界校验。Java 项目用 ArchUnit，TNG Technology Consulting 开源的那个。我们写了 23 条规则，最有用的是「domain 包不能依赖 infrastructure 包」和「任何两个业务模块之间不允许直接引用对方的 entity」。CI 里跑，失败了直接卡合并。这一条比任何架构评审会都管用。
-
每季度做一次架构复盘，两小时，只回答三个问题：哪些约束变了？哪些 ADR 该标 Superseded？哪些服务可以合并？
-
最后，把架构决策和团队的排班、值班表放在同一个文档里。听起来很奇怪，但我发现这两件事放在一起看的时候，很多「优雅」的方案会立刻现原形。
六、我也可能错的地方
ADR 这东西在快速试错的小团队里可能是纯负担。8 人以下、业务还没跑通、一周改三次方向的团队，写 ADR 就是浪费时间——你要的就是快，就是不停地推翻重来。我见过一个 5 人创业团队硬上 ADR，结果 30 份文档里 22 份的状态是 Superseded，大家后来干脆不看了。
还有一点我不太确定：AI 辅助写代码之后，架构决策的颗粒度是不是应该变粗。以前「用不用 ORM」是个要吵半天的决策，现在可能半天就换完了。我还没想清楚这个问题，最近在观察，暂时没有结论。
但有一件事我比较确定。判断一个人能不能当架构师，别看他画过多少张图，看他离开一个团队半年后，那个团队还能不能解释清楚当初为什么这么设计。如果能，他留下了东西。如果不能，他可能只是在那儿待过。