《互联网产品的服务端架构·规模化与架构演进》附录 C 架构演进评审清单

演进评审的作用不是给方案盖章，而是在资源投入之前，把「要不要做、做到什么程度、怎么退出」这三个问题问清楚。

本附录把卷四各章的判断点收成清单，供评审时逐条对照。清单不求全，但求每一条都能引出具体回答。

评审要回答什么

一场有效的架构评审，结束时应该能回答五个问题：

• 这个方案解决的是哪个已发生的问题，而不是假想的问题？
• 不做会怎样，做了会怎样，代价分别是什么？
• 哪些部分可逆，哪些不可逆，不可逆的部分验证过吗？
• 失败时的爆炸半径有多大，怎么止损？
• 谁负责、什么时候验收、什么条件下退出？

回答不了这五个问题，方案就还没到可以投入资源的程度。

评审不是技术选美。一个「技术上更先进」但回答不了上述问题的方案，不应该通过。

三种评审级别

不是所有变更都值得开大会。按影响面分级，让评审强度与风险匹配。

分级的依据是「不可逆程度」和「影响范围」，不是代码量。

一次改动如果同时满足「可回滚」和「影响单个服务」，轻量评审就够。反过来，即使代码只有几十行，只要涉及数据迁移或流量切换，就该走标准或更高级别。

评审前置材料

材料不全就不排会。这一条能省掉大量无效会议。

「不做」必须是一个正式备选。很多方案在「不做会怎样」这一问上就站不住，越早发现越好。

触发条件清单

以下情况出现时，应该主动升级评审级别，而不是按惯例走轻量流程。

• 引入新的存储或消息中间件。
• 跨团队修改数据所有权。
• 改变发布单元或部署拓扑。
• 涉及用户数据的迁移或合并。
• 需要停机或降级才能完成。
• 单次变更影响超过一个核心链路。
• 引入新的外部依赖或第三方服务。
• 组织架构调整伴随系统边界调整。

触发不等于否决，只是提高审视强度。

拆分评审清单

服务拆分是卷四讨论最多、也最容易做错的演进。评审时逐条确认。

• 拆分依据是业务边界还是技术分层？技术分层拆出来的服务通常很快会耦合回去。
• 拆分后的事务边界怎么处理？跨服务的一致性靠什么保证？
• 数据是否真的拆开？共享库的「拆分」只是部署拆分。
• 调用链变长后的超时与重试怎么设计？
• 团队是否能独立发布、独立回滚？
• 拆分后的运维成本（监控、告警、值班）谁承担？
• 有没有明确的「不拆」清单，防止拆过头？

最后一个问题常被忽略。拆分的对立面不是「不演进」，而是「保留合适的整体」。

单元化与多活评审清单

单元化和多活的代价远高于一般改造，评审要格外严格。

• 用户路由的依据是什么，路由信息存在哪，怎么保证一致？
• 跨单元的数据同步是同步还是异步，延迟预算是多少？
• 单元故障时，流量怎么切，切过去的数据是否完整？
• 回切路径是否独立验证过？回切不是切换的逆操作。
• 单元内的依赖是否闭环？有没有隐藏的全局依赖？
• 演练覆盖了哪些故障场景，未覆盖的怎么说明？
• 成本增加多少，是否在预算内？

多活最常见的失败，是把「能切过去」当成「能切回来」。评审必须要求回切演练的证据。

成本评审清单

成本优化的评审重点，是区分「结构性节省」与「透支未来」。

• 优化的是单位成本还是总额？总额下降可能只是业务量下降。
• 节省来自哪里：闲置回收、架构简化、采购议价，还是降低冗余？
• 降低冗余是否影响故障恢复能力？
• 优化后是否增加了运维复杂度，长期成本如何？
• 有没有可量化的前后对比，口径是否一致？
• 节省是否可持续，还是一次性收益？

「关掉一半机器」能立刻降成本，但如果没有容量规划，下一次高峰就会以故障的形式把成本还回来。

平台化评审清单

平台化的失败率很高，因为它同时挑战技术与组织。

• 平台解决的是重复建设的哪个具体问题？有没有使用方愿意第一批接入？
• 平台与业务团队的边界在哪？谁负责什么？
• 接入成本多大？业务团队要改多少代码、学多少东西？
• 平台自身的 SLO 是多少？平台挂了，业务怎么办？
• 有没有退出机制？业务能不能不用平台？
• 平台的使用率、满意度怎么度量？
• 平台的维护人力从哪来，是否可持续？

没有退出机制的平台，最后往往变成「不得不用的负担」。评审时要明确：平台是服务，不是权力。

组织变更评审清单

组织调整经常被当成管理问题，跳过技术评审。但组织边界会直接变成系统边界。

• 调整后的团队是否与系统边界对齐？
• 跨团队接口是否需要重新定义？
• 原有的 on-call 与值班安排如何过渡？
• 知识是否集中在个别人身上，调整后如何分散？
• 短期内的发布节奏会不会受影响？
• 有没有明确的责任交接清单与时间点？

康威定律不会因为没开会就失效。组织怎么分，系统迟早会怎么长。

可逆性与爆炸半径

每个方案都应该标注两个维度：能不能退，退不回来会波及多大。

「不可逆 + 大半径」是最危险的一类。数据模型变更、流量切换、账号体系合并，都属于这一类。

对这类方案，评审的核心不是「方案对不对」，而是「怎么把不可逆拆成多个可逆的小步」。

决策记录模板

评审的产出应该是一份可追溯的决策记录，而不是会议纪要。

决策记录的价值在半年后：当有人问「当初为什么这么设计」，能翻到当时的约束与取舍。

评审会议怎么开

会议本身也有成本，开法不对就是浪费。

• 材料提前 48 小时发出，会上不逐页念。
• 方案作者用 10 分钟讲问题与取舍，不讲实现细节。
• 大部分时间用于提问与质疑，而不是汇报。
• 每个质疑都要落到「会不会改变决策」，否则记录下来即可。
• 会议结束前明确：通过、有条件通过、退回补充、否决。
• 有条件通过的，条件要具体到可验收。

「有条件通过」是最常见的结论，也是最容易变成「无条件下通过」的。条件必须写进决策记录并有人跟踪。

评审中的高频提问

评审会上反复出现的质疑，大体可以归为六类。提前准备，能显著提高评审效率。

这六类问题回答不了，方案通常还没想清楚。

其中「什么时候能退出」最容易被跳过。很多架构方案在引入时很有说服力，但没人想过怎么退出，最后变成谁也不敢动的历史包袱。评审时要求写明退出条件，是在为未来留一条路。

提问也有讲究。好的提问指向决策：「如果跨服务事务失败率到 1%，方案还成立吗？」坏的提问指向细节：「你这个类的命名为什么是单数？」前者改变决策，后者消磨时间。

主持人有责任把讨论拉回决策相关的问题。记录人可以单独记下细节质疑，会后处理。

一次被否的评审

「回声」曾提过一个「把订单服务拆成六个微服务」的方案。评审会上被退回。

退回的理由不是技术不可行，而是三个问题没答上来：

• 拆分后跨服务的下单事务怎么保证？方案里写的是「用消息最终一致」，但没说消息丢了怎么办。
• 团队只有四个人，拆成六个服务后，谁负责 on-call？方案里没提。
• 拆分能带来什么业务收益？方案里只有技术收益，如「解耦」「可独立部署」。

三个月后，团队重新提了一个方案：先拆出库存与支付两个边界最清晰的部分，订单主流程保持单体，并明确每个新服务的负责人。这次通过了。

被否不是失败。被否后能提出更小、更具体的方案，才是评审真正起作用的证据。

评审后的跟踪

评审通过不等于事情结束。三个跟踪点：

• 阶段计划的每个里程碑是否有验收标准？
• 退出条件是否被记录并在复查时重新评估？
• 评审中被搁置的质疑是否有人跟进？

建议每季度复查一次重大决策：当时的约束是否还成立，方案是否还合适，有没有到了退出条件。

架构演进最怕的不是走错，而是走错了没人回头。

常见误区

• 把评审当审批。 评审是找问题，不是盖章。
• 材料越厚越好。 三十页 PPT 不如一页说清问题与取舍。
• 只评审技术，不评审组织。 谁维护、谁值班、谁负责，同样是架构问题。
• 通过即结束。 没有跟踪的评审，等于没评审。
• 回避「不做」。 不把「不做」当选项，方案就永远显得必要。
• 用先进代替合适。 适合当前规模与团队的设计，才是好设计。

总清单

评审开始前，对照这十条快速自检：

1. 问题有数据支撑，不是感觉。
2. 至少有两个备选方案，含「不做」。
3. 取舍写清楚了，包括放弃了什么。
4. 可逆性与爆炸半径已标注。
5. 不可逆的部分拆成了可验证的小步。
6. 回退方案有人独立确认过。
7. 影响范围覆盖了所有下游。
8. 负责人、验收标准、退出条件都明确。
9. 组织与人力约束已纳入考虑。
10. 决策记录会进入可检索的地方。

十条都能回答，评审可以开得很快；有两条以上答不上来，先补材料再开会。

清单的意义不在于逐条打勾，而在于让「没想到」变成「想到了但决定接受」。前者是风险，后者是取舍。