什么是演进式架构
演进式架构主张把结构变更做成持续的增量过程，而不是几年一次的重构项目：先明确哪些架构特征必须被守护，再用适应度函数在流水线里持续验证，让架构能够随业务一起改变。判断一项设计是否合格，标准是它能否被小步修改，而不是它今天是否「正确」。
基本信息
| 概念出处 | 《演进式架构》（Ford、Parsons、Kua，2017） |
|---|---|
| 三要素 | 增量变更、受保护的变化维度、引导性约束 |
| 常用手段 | 绞杀者迁移、抽象分支、契约测试、适应度函数 |
| 组织前提 | 团队边界与目标架构同步调整 |
落地要点
- 明确受保护维度：列出必须可测量、可守护的特征，如接口兼容性与 P99 延迟
- 约束先行：动结构之前先把适应度函数加上，避免改完才发现漂移
- 保持撤销能力：每个增量都能独立回退，回退通道在真实发布链路里演练过
- 节奏对齐：结构改进穿插进业务迭代排期，不做「冻结三个月做大重构」
- 双跑校验：新旧路径并行跑一段时间，比对差异收敛后再切换流量
- 组织配套：架构边界变化同步调整团队归属与接口责任
增量改造模式
| 模式 | 适用场景 | 关键点 |
|---|---|---|
| 绞杀者迁移 | 整体替换旧系统 | 路由分流与双跑校验 |
| 抽象分支 | 大范围重构难以一次完成 | 主干隐藏差异、控制分支寿命 |
| 并行运行 | 需要比对新旧实现结果 | 影子流量与差异报告 |
| 扩展-收缩 | 数据与接口结构替换 | 兼容期双写，稳定后清理旧路径 |
一次增量改造的检查清单
一次增量改造的检查清单
# 改造前
- 受保护维度是否已写成可执行的适应度函数
- 回退步骤是否演练过，回退耗时是否可接受
# 改造中
- 新旧路径双跑，差异率是否在阈值内收敛
- 分支/开关的存活时间是否有明确截止日
# 改造后
- 旧路径是否已下线并清理（代码、配置、数据表）
- 适应度函数是否更新，是否仍有历史豁免待回收演进的前提是测试与部署能力：没有自动化验证与快速回滚，结构变更的风险不可控，所谓演进会退化成一次次豪赌。
计划性大重构最大的风险是期间业务与重构互相干扰：需求变更会不断打断重构，重构又会拖慢交付，两头都受损。