架构演进模式

• 与"源码分支"（feature branch）的本质区别
• 抽象层（seam）的引入与迁移
• 新旧实现共存与切换

Branch by Abstraction（BbA）是一种在共享主干上进行大重构/迁移的演进模式，核心是"用抽象层代替源码分支"。它不创建长期 feature branch，而是先在旧实现外层引入一个抽象接口（seam），把调用方改为通过抽象访问，然后在新实现上实现同一抽象，让新旧实现并存，最后逐步把调用方迁移到新实现并删除旧实现。其关键价值是：演进过程始终可集成、可测试、可回滚，团队在主干上通过"抽象"这一替代分支来并行推进，避免长期合并（merge）地狱。典型场景是数据库迁移、框架替换、服务拆分。

BbA 与 feature branch 的本质区别在于"分支的载体"：feature branch 把分叉放在版本控制，合并时冲突集中爆发；BbA 把分叉放在抽象层，冲突被逐步消化。它依赖"抽象边界"的稳定设计，配合演进看板与门禁管理，是"无分支演进"理念的落地。其难点是抽象层设计的正确性与迁移节奏的把控。

• 模块化单体的定义与模块边界
• 与单体/微服务的对比
• 作为中间形态的价值与迁移路径

Modular Monolith（模块化单体）是把单体应用内部按清晰职责划分为多个模块（module），每个模块有独立边界、可独立编译部署，但整体仍作为一个分布式单元部署（一个进程/一个应用）。它保留了单体的部署简单、事务一致、运维成本低的优点，同时获得模块化的可维护性、可替换性。作为微服务化中间形态，它让团队先"在单体内部把边界切对"，再按需把模块热拆成独立服务，避免直接微服务化带来的分布式复杂度。它用 ArchUnit 等守护模块边界，本质是"先内聚、再拆分"的演进策略。

模块化单体的价值在于"把拆分的决策推迟到真正需要时"：它解决了"过早拆分"的分布式陷阱，同时为后续拆分预留了清晰的边界。它比"大泥球单体"更健康，比微服务更简单，是演进式架构推荐的中间态。关键挑战是严格执行模块边界（禁止跨模块直接依赖内部实现），否则会退化为大泥球。

• 演进看板的四个阶段
• 适应度函数门禁的作用
• 并行演进的冲突管理

并行架构演进的关键是"节奏管理与冲突隔离"。演进看板（Evolution Board）把每个演进主题（initiative）分为候选、计划、进行、验证四个阶段：候选阶段评估可行性并暂缓；计划阶段制定方案与门禁；进行阶段改造代码；验证阶段通过适应度函数确认目标达成并回滚或关闭。每个演进主题都绑定一组适应度函数作为门禁，确保演进不破坏既有约束。避免相互干扰的主要手段是：控制同时"进行"的演进数量（限制在制品 WIP）、按模块/服务隔离演进范围、在共享主干上通过抽象（Branch by Abstraction）与特性开关隔离变更、用契约测试保证跨服务兼容。通过将演进拆小、限流、可验证，多演进可并行推进而不互相践踏。

并行演进失败的根本原因是"无节奏、无边界、无门禁"。看板提供了节奏与可见性（透明化在制品），适应度函数门禁提供了安全的"完成标准"，二者结合形成"演进治理"闭环。核心原则是"少而稳"：限制并行演进数量，让每个演进小而可验证，避免一次大改引发的冲突。这是演进式架构从"单点演进"走向"规模化演进"的治理手段。

• 三组分类的补充维度（有损/无损）
• 分类选择的方法
• 演进中的动态调整

除原子/整体、触发/持续、静态/动态外，Neal Ford 还引入"有损/无损"（lossless/lossy）维度：无损适应度函数基于完整精准的数据（如全量依赖图、精确度量），结果精确但成本高；有损适应度函数基于采样/近似数据（如抽样监控、模糊匹配），成本低但可能漏报。选择时按"被守护属性的精度需求 × 成本"权衡：精确结果必须用无损（如许可证、安全基线），成本敏感或属性本身模糊（如性能趋势、健康分）可用有损。演进中随着约束的收紧与架构成熟，应动态调整：早期用宽松的软门禁/报告，随约束明确逐步收紧为无损硬门禁，并随新约束出现新增函数、随过时约束淘汰旧函数。适应度函数是"活的"，需随架构演化持续维护。

有损/无损维度补全了"花多大力气度量"的权衡，避免"为精确而过度设计"。演进中的调整核心是"适应度函数本身也要演进"——新约束出现时加函数，约束收紧时提高阈值，风险收敛时降级或删除。这使适应度函数成为架构演进的"传感器网络"，而非一次性的静态清单。

• 两种变更的定义与区别
• 引导式与演进式的适用场景
• 与适应度函数的关系

在《Building Evolutionary Architectures》中，Neal Ford 区分了两种架构变更方式：引导式变更（Guided Change）是"有明确目标、由架构师计划好的结构性变革"，如一次目标明确的数据库迁移、技术栈替换，方向明确、需集中管理；演进式变更（Evolutionary Change）是"小步、持续、由团队在日常迭代中自然发生的增量改进"，如持续重构、依赖小版本升级，方向由适应性决定。二者并非互斥，而是互补：引导式负责"大目标牵引"，演进式负责"小步积累"。两者都依赖适应度函数作为"护栏"——引导式变更用门禁验证目标，演进式变更用门禁防止退化。

关键洞察是"架构不是要么全计划、要么全随机，而是引导与演进的结合"。引导式提供方向与边界，演进式提供微观的适应性。过度引导会僵化，过度演进会失焦。适应度函数是连接二者的桥梁，让"引导式"有据可依、让"演进式"有界可守。

• 四种拆分策略的含义
• 各策略的适用场景
• 拆分边界的评估

微服务拆分有四种代表性策略：By Business Capability（按业务能力拆分）依赖业务能力矩阵，围绕业务能力划分服务边界，服务对齐业务而非技术；By Subdomain（按子域拆分）基于领域驱动设计（DDD）的限界上下文，用领域子域划分服务，强调领域模型的一致性；By Strangler Fig（绞杀者）用渐进的方式在旧系统旁构建新服务，逐步替换旧功能，非线性迁移；By Self-Contained Service（自包含服务）按"请求-响应"的完整调用链划分，使一个服务自包含完整业务流程，减少跨服务调用。选择时需结合业务能力、领域模型、变更频率、数据所有权与团队结构综合判断，无单一最优策略。

四种策略差异在于"拆分的依据"：业务能力侧重业务组织，子域侧重领域模型，绞杀者侧重渐进替换，自包含侧重调用链自治。实际拆分常混合使用，并以"高内聚、低耦合、独立演进"为边界评估标准。核心是"边界由高内聚的职责+独立的数据所有权决定"，而非按技术层次（controller/service/repository）拆分。

• 适应度函数的定义
• 对性能/安全/可修改性的度量
• 客观度量的意义

演进式架构中的适应度函数（Fitness Function）是对某项架构属性进行客观、可量化、可自动化的度量机制，用于回答"架构是否仍符合约束"。对性能，可用延迟/吞吐量阈值、包体积预算、资源占用指标度量；对安全，可用可接受的漏洞级别、许可证黑名单、安全基线度量；对可修改性，可用环复杂度、耦合度、依赖方向、模块边界度量。其核心是"客观"——不依赖主观评审，而是由自动化测试、静态分析、监控给出确定性的通过/失败。这样架构约束从"口头约定"变为"可执行、可复现、可门禁"的工程事实，从而让架构在演进的每个阶段都可被验证。

客观度量的意义在于"把架构治理从艺术变成科学"：主观评审无法规模化、无法持续，而适应度函数可反复执行、可入门禁、可量化趋势。性能、安全、可修改性正是架构最关键的三个非功能属性，把三者分别映射为可度量的函数，就构成了架构的"持续验证体系"。这使演进式架构区别于"重文档、轻验证"的传统架构实践。

• 绞杀者模式的渐进替换
• Facade 的角色与作用
• Anti-Corruption Layer 的隔离作用

绞杀者模式（Strangler Fig）通过渐进替换旧系统：在旧系统外围构建一个 Facade（门面，统一入口），把外部调用路由到新实现或旧实现，随着新功能逐步实现，调用逐渐从旧实现切到新实现，当旧部分被完全替换后移除 Facade。在迁移过程中，若新旧系统之间存在领域模型、数据格式或协议的差异，就用 Anti-Corruption Layer（防腐层）隔离：它在新旧系统之间翻译数据模型、转换协议、屏蔽旧系统的内部复杂性，防止旧系统的"腐化"污染新系统。Facade 负责"路由与切换"，防腐层负责"翻译与隔离"，二者配合实现"接口不变、实现渐进替换"的平滑迁移。

绞杀者模式的价值在于"以增量替换做到可回滚、可验证"。Facade 让新旧实现切换对调用方透明，防腐层让新旧系统边界清晰、模型不污染。迁移节奏由"功能覆盖度"与"切流验证"驱动，配合门禁确认每个替换步骤达标。这是大型遗留系统现代化最稳妥的演进路径。

• 分布式单体的定义
• 反模式特征（共享库、强耦合调用、分布式事务）
• 诊断方法

分布式单体（Distributed Monolith）是"名义上微服务、实则强耦合"的反模式：它被拆成多个服务，但服务间高度耦合、共享数据库、同步调用链复杂、共享库与全局配置，导致它既没有微服务的独立演进能力，又背负了分布式的成本（网络、运维、一致性）。典型特征包括：多个服务共享同一数据库表、服务间大量同步远程调用串成致命调用链、频繁的分布式事务、共享代码库、单点部署依赖。诊断方法：用依赖图分析服务间调用密度与环、检查是否共享数据库、统计同步调用链长度、检测是否存在"改一个服务必须同步改多个服务"的耦合。诊断目标是识别"拆分不彻底"的边界，指导重新梳理。

分布式单体的本质是"拆错了边界"——拆分的依据是技术而非业务/领域，导致服务之间仍强耦合。它比传统单体更糟，因为叠加了分布式复杂度。诊断的关键是"识别隐性耦合"：共享数据、跨服务事务、同步调用链。修复方向是重新划定高内聚的边界，用防腐层/异步事件解耦，逐步收敛为真正的微服务。

• 规模、团队、业务三类驱动力
• 驱动力如何触发演进
• 演进与驱动力匹配

架构演进的驱动力主要来自三类：规模、团队与业务。规模方面，当数据量、流量、并发、代码量增长到现有架构无法支撑时（如单体数据库瓶颈、性能劣化），驱动拆分或优化；团队方面，当团队规模扩大、协作成本上升、交付需独立部署时，驱动模块化或微服务化以提升自治；业务方面，当业务需求、组织架构（如康威定律）、市场变化要求快速迭代、独立发布时，驱动架构调整。这三者往往是架构演进的"信号"：当某类指标突破阈值（如 CI 时长、发布频率、故障范围），就触发对应的架构演进。演进应与驱动力匹配，避免"为了技术而演进"。

架构演进不是"赶时髦"，而是被具体驱动力触发。康威定律决定了组织结构与架构互相影响，团队规模变化会自然推动架构调整。判断演进时机应"以驱动力为依据"而非"以技术潮流为依据"：当规模、团队、业务确实构成瓶颈时才演进，否则维持现状更优。核心是"演进服务于业务与组织目标"。

• 数据迁移四阶段
• 各阶段的验收标准
• 各阶段的回滚条件

数据层迁移常用"双写、对账、切流、清理"四阶段。双写阶段：新旧数据源同时写入，验收标准是双写成功率高、无异常、不影响性能，回滚条件是直接关闭新写入口、停新回旧；对账阶段：定期比对新旧数据的一致性，验收标准是一致率达标（如接近 100%）且无系统性差异，回滚条件是发现不可修复差异时停止对账、维持双写并回滚；切流阶段：逐步把读/写流量从旧源切到新源，验收标准是流量切换后正确率、延迟、错误率均达标，回滚条件是切流比例可随时回调、支持灰度回退；清理阶段：删除旧数据源与冗余代码，验收标准是稳定运行期无回归、新源可独立支撑，回滚条件则因数据已删，需靠备份与重建能力兜底。每阶段都需明确"可回滚的边界"，保证迁移可逆。

数据迁移风险最高，因为数据是"不可轻易重来"的资产。四阶段的核心是"逐步降风险、保持可逆"：双写与对账保证数据一致，切流保证流量可控，清理才真正收尾。每个阶段的验收标准都要"可量化"（一致率、成功率、延迟），回滚条件都要"可执行"（何时回、怎么回）。整体遵循"小步、可验证、可回滚"的演进原则。

• 三类耦合的识别方法
• 依赖分析工具
• 拆分顺序的确定

微服务拆分前的耦合预检是识别"当前边界是否真的低耦合"的关键。共享表：通过数据库 schema 分析、外键依赖图、查询分析识别哪些表被多个模块/服务共享，共享表往往意味着数据边界不清（涉及"共享数据"耦合）；隐式远程调用：通过代码分析、调用图、日志追踪识别跨模块的同步方法调用、隐藏的 RPC/HTTP 调用，这类调用会形成运行时耦合；事件依赖：通过事件流、消息订阅关系分析识别模块间通过事件（如消息队列）的异步耦合。识别可用依赖分析工具（ArchUnit、Dependency-Cruiser、SchemaSpy、代码调用图）。拆分顺序上，先拆"耦合最弱、边界最清晰、变更频率独立"的模块，把高耦合、共享数据多的模块留待边界整理后再拆，避免一开始就拆出分布式单体。

耦合预检的价值在于"先看清边界再拆"，避免拆错边界。共享表、隐式调用、事件依赖三类耦合决定了数据与调用是否真正内聚。拆分顺序应遵循"低耦合优先、高内聚优先"：先拆边界清晰、独立变更的，后拆强耦合的，并通过预检结果决定是否先做数据解耦/防腐层。核心是"用数据而非感觉决定拆分"。

• 过早拆分的定义
• 分布式复杂度的代价
• 与模块化单体的对比

过早拆分（premature decomposition）指在业务与边界尚未清晰、团队规模不足时，就贸然拆成微服务。其代价包括：分布式复杂度的陡增（网络延迟、容错、分布式事务、一致性、运维成本）；服务边界错误导致后续反复拆分/合并；数据一致性难题（跨服务事务）；开发与调试效率下降（跨服务排障）；运维成本上升（多服务部署、监控、日志聚合）。这些代价在业务规模不足时往往"入不敷出"，反而拖慢交付。相比之下，先把单体做成模块化单体，待规模与边界明确后再按需拆分，是更稳妥的演进路径。

过早拆分的本质是"用分布式复杂度换取并不真正需要的独立演进"。微服务的收益（独立部署、独立扩展）在业务足够大、团队足够多时才兑现，过早拆分只会放大成本。判断标准是"收益是否大于成本"：当单体成为明确瓶颈（如团队协作、性能、发布）时才拆分，否则维护模块化单体更优。

• 过早合并的定义
• 与过早拆分的对比
• 合并时机的判断

过早合并（premature consolidation）指在服务边界尚不需合并或团队仍需要独立演进时，就过早把多个服务合并为一个服务。其反向代价包括：失去独立部署与独立扩展的能力；放大变更的影响范围（一个服务变更影响面变大）；团队协作冲突加剧（合并后多人改同一代码库）；独立演进与故障隔离能力下降。过早合并与过早拆分是"两个极端"：拆分过头会背负分布式复杂度，合并过头会失去模块化收益。正确做法是"以边界与团队需求为准"：当多个服务高内聚、变更同频、独立部署收益低时再合并，否则维持自治。

过早合并的代价与过早拆分对称，根源同样是"不按实际需求演进"。合并的价值在于降低运维与部署复杂度，但只有当"独立演进的需求消失"时才该合并。判断标准是"边界是否仍合理、独立部署是否仍有收益"。两者都强调"演进要服务于真实需求，而非教条"。

• 增量重构与绞杀者的区别
• 各模式的适用场景
• 演进模式的选择

增量重构（Incremental Refactoring）是"在不改变外部行为的前提下，小步持续改善内部结构"的演进方式，适用于系统仍稳定、边界清晰、可小步改造的场景，其特点是风险低、可持续、覆盖范围广。绞杀者（Strangler Fig）是"在旧系统旁边渐进构建新系统，逐步替换旧功能"的迁移方式，适用于遗留系统无法小步重构、需要整体替换或引入新技术栈的场景，其特点是新旧并行、可灰度、可回滚。选择时看"系统的可维护程度与替换需求"：若系统可逐步改善，用增量重构；若系统结构已坏、难以小步改造或需技术栈迁移，用绞杀者。二者也可结合，绞杀建设新系统的同时对新系统内部做增量重构。

这两种模式代表了"从内部改善"与"从外部替换"两条演进路径。增量重构适合"边开飞机边换引擎"（系统稳定期），绞杀者适合"旧引擎已坏"（需整体替换期）。选择的核心是"评估系统当前结构与改造风险"，并坚持"小步、可验证、可回滚"的共同原则。

• 兼容性风险（接口、数据、契约）
• 回滚机制的设计
• 风险控制手段

架构演进的两大风险是兼容与回滚。兼容风险包括：接口兼容（API 变更破坏调用方）、数据兼容（数据格式/模型变更导致迁移失败）、契约兼容（服务间契约被破坏）。管理手段包括：保持向后兼容（增加而非删除、字段可空缺省）、用版本化接口（v1/v2）、契约测试守护服务间兼容、双写/灰度保证数据兼容。回滚风险指演进失败后能否快速回到稳定状态。管理手段包括：按演进阶段设计回滚点（如双写阶段回滚停新写、切流阶段回流比例、清理阶段留备份）、用特性开关/灰度发布让变更可逆、演进前备份数据与配置、定义明确的回滚触发条件与责任人。核心是"演进可逆"，让失败代价可控。

兼容与回滚是"演进安全网"的两面：兼容性控制"向前不破坏"，回滚控制"向后可恢复"。二者都要求设计阶段就预留"可逆边界"（抽象、开关、灰度、备份），而非演进出问题才补救。关键原则是"演进小步、可验证、可回滚"，让每次演进风险都可控、可量化。

• ADR（架构决策记录）的价值
• 记录的内容与时机
• 复盘与演进闭环

架构决策记录（ADR）把"为什么做此决策、有何取舍、备选方案"以轻量文档形式沉淀下来。记录时机是在决策做出时（而非事后），内容包括：决策背景、决策本身、备选方案与取舍、后果与影响。ADR 的价值在于：保留决策上下文（避免后人"只看到结果、不知为何"）、支持复盘（可回溯决策合理性）、降低返工（同一问题不重复决策）。复盘则是定期回顾决策的执行效果：对比预期收益与实际结果、识别决策失误与成功模式、更新过时的决策。复盘与 ADR 形成"决策-执行-验证-修订"的闭环，让架构演进有据可依、可学习、可持续。

架构决策容易"今日定、明日忘"，ADR 让决策变得可追溯、可审查、可演化。复盘把"经验"转化为"组织资产"，避免重复踩坑。对演进式架构而言，ADR 与复盘是"治理的元层"——它们管理的是"演进这个行为本身"。核心是"决策透明、复盘及时、文档轻量"。

• 依赖治理的目标
• 模块边界的守护手段
• 演进中的边界治理

演进中的依赖治理目标是"防止模块边界在演进中悄悄腐化"，即维护"高内聚、低耦合"的模块结构。守护手段包括：用依赖规则工具（ArchUnit、Dependency-Cruiser、JDepend）把"允许/禁止依赖"固化为可执行规则，作为门禁拦截越界依赖；用冻结规则（freezing）渐进收敛存量违规；用依赖图分析监控依赖随演进的变化趋势；用模块边界测试（如"模块不得依赖其他模块内部实现"）守护封装。演进中治理的核心是"持续而非一次"：每次演进都重新检查依赖是否越界，新增依赖时强制走规则，让边界成为"活的约束"而非初期的一次性检查。

边界腐化是演进中最常见的隐性退化：重构、加功能时顺手越界，长期累积让模块边界形同虚设。依赖治理的价值在于"把边界守护变成自动化门禁"，让每一次演进都受约束。它强调"渐进式"与"持续式"结合：渐进收敛存量违规、持续守护新增依赖，配合看板管理演进节奏。

• 拆分与维持现状的成本维度
• 长期成本的估算方法
• 决策的量化依据

架构演进的成本决策应"量化对比"而非"凭感觉"。估算拆分（或演进）的成本维度包括：一次性成本（开发、迁移、重构、新基础设施）；长期成本（分布式运维、团队协作、独立部署、技术债）；收益（性能提升、交付加速、独立扩展、风险降低）。维持现状的成本维度包括：当前技术债累积、协作摩擦、性能瓶颈、扩展受限、人才流失风险。估算方法：用净现值（NPV）/投资回报（ROI）对两类方案做长期（如 3-5 年）对比，把"人力成本、故障成本、交付延迟成本"货币化，并考虑折现与不确定性。决策依据是"演进带来的长期收益是否覆盖其成本"，而非"技术潮流"或"个人偏好"。

架构决策常被"感觉"主导：觉得新架构更先进就拆，觉得老系统稳定就维持。量化对比的价值在于把"隐性成本"显性化，让"维持现状"与"拆分演进"在同一标尺下比较。关键难点是"成本货币化"（把技术债、故障、交付延迟折算成金额）与"不确定性处理"（演进可能失败）。核心原则是"用长期价值而非短期冲动做决策"。