架构师现场 · 栏目说明

架构文章最容易犯的毛病，是把结论当成过程：直接告诉你应该用某个方案，却不告诉你当时面对什么约束、否掉了哪些选项、付出了什么代价。

这个栏目记录的是现场。

每篇的结构

1. 背景：业务处在什么阶段，系统遇到了什么具体问题。
2. 约束：时间、预算、团队能力、存量系统、合规要求，哪些是不能动的。
3. 选项：当时认真考虑过的两到四个方案，包括被否掉的那个。
4. 决策：为什么选这个，关键判断依据是什么，谁拍的板。
5. 结果：上线后的真实表现，哪些符合预期，哪些判断错了。
6. 回看：如果重来一次，会怎么改。

主题范围

• 系统拆分与合并的时机判断
• 技术选型：数据库、消息队列、网关、可观测性栈
• 存量系统迁移与改造
• 多团队协作下的架构治理
• 组织约束如何影响技术决策
• 架构评审中真正有效的提问方式

写作原则

• 写约束，不写口号。脱离约束的架构建议没有参考价值。
• 写被否掉的方案。知道什么不可行，和知道什么可行同样重要。
• 写判断错的地方。只讲成功案例的复盘，价值有限。
• 区分「当时的判断」和「现在的结果」，不用后见之明美化过程。

适合谁看

正在做架构决策的工程师、技术负责人和架构师，以及需要参与架构评审的团队。