Day31-07｜10.3.1 软件架构演化时期：在生命周期不同阶段采取不同治理策略

一、教材定位

软件架构的演化并不是从系统上线那一天才开始，也不是只有系统老化后才需要进行。架构从需求分析、概念设计、详细设计、实现、测试、部署、运行维护到退役，都会经历不同形式的变化。不同阶段的变化来源、信息完整度、变更成本和风险不同，因此架构治理方法也不能一成不变。

本节的核心是建立生命周期视角。早期架构定义影响后续大部分成本，设计阶段的边界和质量决策会决定实现难度；实现和测试阶段会暴露原有假设；上线运行阶段会产生真实负载、故障和用户反馈；维护阶段既要吸收新需求，也要偿还技术债务；退役阶段则要处理数据、接口和依赖的迁移。高级系统架构设计师需要在不同演化时期采取与风险相匹配的策略。

二、生命周期中的架构演化时期

可以将架构演化粗略划分为以下时期：需求和概念形成期、架构设计期、构建和验证期、部署与上线期、运行维护期、重构和迁移期、退役与替换期。这些时期并非严格线性，迭代开发中会反复循环，但它们代表不同的决策重点。

三、需求和概念形成期

1. 架构演化的特点

这一阶段变化频繁、信息不完整、成本相对较低，但错误目标可能在后期放大。业务人员可能不断调整范围，利益相关者对性能、安全、可用性和合规的理解也可能不同。架构师应把模糊需求转化为质量属性场景、业务边界和优先级。

2. 主要治理活动

识别利益相关者，明确系统边界和外部依赖，建立业务能力和关键流程，定义数据所有权和质量目标。对高风险假设建立原型或实验，例如峰值流量、第三方接口、数据迁移、设备协议和安全机制。

3. 常见风险

只关注功能列表而忽略质量属性；把未来规模和故障场景当成“以后再说”；使用技术名词替代架构决策；没有明确哪些需求是硬约束、哪些是可调整目标。需求形成期不一定要画出最终详细架构，但必须尽早识别不可逆决策和高风险不确定性。

四、架构设计期

1. 架构演化的特点

主要变化集中在分层、组件、数据、接口、部署和质量属性权衡。设计选择一旦进入实现，修改成本开始上升。架构师需要在完整性和灵活性之间平衡，避免过早细化全部实现，也不能把关键决策留到编码阶段。

2. 主要治理活动

建立候选方案，比较成本、风险和质量属性；明确架构原则、边界、接口、数据所有权和部署策略；记录关键决策和假设；制作垂直切片或技术原型验证最不确定部分。对安全、性能、可靠性和可运维性进行场景化评估。

3. 常见风险

设计只描述静态结构，不描述行为、异常和恢复；架构图与实际配置脱节；选择复杂技术却没有团队能力和运维条件；过度追求未来扩展导致当前系统难以交付。解决方法是以业务价值和风险优先级驱动设计，并让高风险决策尽早接受验证。

五、构建和验证期

1. 架构演化的特点

代码、配置和测试会暴露设计阶段没有发现的问题。接口契约可能不清，数据模型可能无法满足查询，性能可能达不到目标，组件边界可能导致调用链过长。架构定义开始接受真实实现的检验，部分设计需要调整。

2. 主要治理活动

建立架构合规检查、契约测试、依赖检查、性能基准、故障注入和安全测试。定期比较架构定义与实现，检查是否出现循环依赖、越权访问、共享数据绕过和临时适配器。对实现中发现的合理变化，要更新架构决策和模型，而不是只改代码。

3. 常见风险

开发为了快速通过测试而绕过边界；架构师只在项目初期参与，无法吸收实现反馈；测试只覆盖功能路径，未验证故障、恢复和长期运行。应建立架构师、开发、测试和运维的反馈机制，把问题前移。

六、部署与上线期

1. 架构演化的特点

测试环境与生产环境在拓扑、容量、权限、数据和依赖上可能不同。上线会引入真实流量、真实用户行为和真实外部服务，许多在测试阶段隐藏的问题会暴露。配置、证书、路由、资源限制和观测能力成为架构的一部分。

2. 主要治理活动

采用基础设施即代码、配置基线、自动化部署、灰度发布、分批切流、回滚和业务对账。上线前检查容量、依赖、监控、告警和应急预案；上线中观察技术和业务指标；上线后确认数据、消息和状态一致。

3. 常见风险

只验证服务能启动，不验证端到端业务；只准备代码回滚，没有数据和消息回滚；灰度指标只有 CPU 和错误率，没有业务成功率和数据差异；新旧版本协议不兼容。上线是架构演化的重要时期，必须把运行控制纳入设计。

七、运行维护期

1. 架构演化的特点

系统不断接收新需求、修复缺陷、升级依赖、扩大容量和适应用户变化。局部修改积累后可能形成架构衰退。真实运行数据提供了设计阶段无法获得的证据，也可能推翻原来的假设。

2. 主要治理活动

建立架构度量和技术债务清单，定期分析故障、变更失败、恢复时间、性能趋势、依赖和成本。对高频变化和高风险边界进行重构，及时更新文档、决策和运行手册。维护工作不能只处理眼前工单，还要识别重复问题背后的结构原因。

3. 常见风险

紧急变更绕过评审；临时配置长期保留；监控和文档滞后；为了不影响业务而无限推迟架构治理。应按风险分级，采用轻量但可追溯的变更流程，并安排偿还技术债务的容量。

八、重构和迁移期

1. 架构演化的特点

重构和迁移通常由规模瓶颈、技术淘汰、合规要求、组织变化或长期债务触发。此时新旧架构会并存，数据和接口需要过渡，风险集中在兼容、切换、回滚和一致性。

2. 主要治理活动

定义现状、过渡和目标架构，分阶段建立边界，选择先行领域，使用适配器、双读、双写、影子流量、事件桥接和灰度切流。为每个阶段定义退出条件、数据对账、监控、回滚和人工接管。

3. 常见风险

目标架构设计得很漂亮但没有可执行迁移路径；双写长期存在导致差异；旧系统仍有未识别消费者；切换后没有历史数据和批任务验证。迁移必须以业务结果和可恢复性为中心。

九、退役与替换期

系统退役并不等于停止进程。必须盘点接口、定时任务、报表、数据、权限、审计、依赖和用户，确认替代系统已经承接功能和数据。数据要根据保留期限归档或销毁，敏感数据要满足合规要求。

退役应采用通知、冻结新功能、迁移存量、并行观察、停止写入、只读保留和最终下线等步骤。下线前验证没有流量、消息和后台任务依赖，保留可审计记录和必要的恢复方案。

十、架构演化的度量

不同阶段应使用不同指标。需求和设计期关注需求变更影响、关键假设数量、原型验证结果和质量场景覆盖；构建期关注架构违规、契约失败、测试覆盖和性能基准；上线期关注发布失败率、回滚时间、灰度差异和业务成功率；运行期关注故障率、恢复时间、技术债务、变更前置时间和成本；迁移期关注切流比例、数据差异、旧消费者数量和退出进度。

指标不是为了制造考核压力，而是帮助判断演化是否有效。指标变化要与业务和环境一起解释，避免为了达标而改变统计口径。

十一、案例分析：传统核心系统云化演化

某企业核心系统运行多年，单体部署、人工发布、共享数据库和固定服务器已经难以满足业务增长。项目决定直接迁移到云平台并拆分为多个服务，计划六个月完成。

架构师发现直接迁移存在较大风险，因此按时期治理。需求和设计期先确认上云目标、合规边界、容灾等级和成本预算；构建期建立自动化部署、配置管理、监控和契约测试；上线期先迁移非核心查询和批任务，采用双轨运行和灰度流量；运行期根据真实数据调整容量、缓存和故障隔离；核心交易迁移时使用数据同步、对账、可回滚切换和人工接管；旧系统退役前盘点报表、接口和定时任务，保留只读和审计窗口。

项目成效不以“所有服务都容器化”为唯一标准，而以核心业务成功率、恢复时间、发布频率、故障影响范围、成本和数据一致性评价。这样可以避免把技术迁移误认为架构演化已经成功。

十二、综合知识练习

题1

为什么不同生命周期阶段需要不同的架构治理重点？

参考答案：各阶段的信息完整度、变更成本、风险和可观测性不同。早期重点是目标和高风险假设，设计期重点是权衡和边界，构建期重点是实现一致性和验证，上线期重点是灰度与回滚，运行期重点是度量和债务，迁移期重点是兼容和数据一致。

题2

上线期为什么不能只验证代码能启动？

参考答案：生产环境还涉及配置、拓扑、真实流量、外部依赖、权限、证书、数据、消息和运维能力。必须验证端到端业务、技术指标、数据一致性、监控告警、灰度停止条件和回滚。

题3

迁移项目中如何判断架构演化已经完成？

参考答案：目标架构的结构、质量和业务目标达到要求，数据和接口迁移完成，旧消费者和临时适配器已退出，监控和运维手册更新，关键指标改善，且具备稳定运行、回滚和审计证据，不能只看新平台是否部署成功。

十三、论文写作素材

论文中可以这样描述生命周期治理：

“我根据软件生命周期建立分阶段架构治理机制：需求期明确利益相关者、业务边界和质量场景；设计期比较候选方案并验证高风险假设；构建期通过契约测试、依赖检查和性能基准保持实现与架构一致；上线期采用配置基线、灰度、监控和回滚；运行期依据故障、变更和容量数据管理技术债务；迁移期同时维护现状、过渡和目标架构，通过双轨、对账和逐步切流降低风险；退役期盘点接口、数据和任务，完成归档、通知和安全下线。”

十四、今日复盘

1. 架构从需求到退役都在演化，不同阶段的风险和治理重点不同。
2. 早期要验证目标和高风险假设，后期要依靠真实运行数据持续校正。
3. 上线和运行阶段必须把配置、监控、回滚、业务对账纳入架构。
4. 迁移阶段要管理现状、过渡和目标架构，控制兼容、数据和切换风险。
5. 退役要处理遗留依赖、数据保留、审计和后台任务。
6. 论文答题可用“阶段—变化—风险—治理—度量”结构展开。