Day31-08｜10.3.2 软件架构静态演化：调整结构而不丢失边界和约束

一、教材定位

软件架构静态演化，主要研究系统结构在生命周期中的变化，包括组件、连接器、接口、数据存储、部署节点、层次、分区和配置关系的增加、删除、替换、移动、拆分与合并。它强调“系统由什么构成、各部分如何连接”发生了怎样的改变，与动态演化中运行时行为和状态变化相区别。

静态演化并不意味着系统运行时没有影响。一个服务从单体中拆出、一个数据库从共享变为领域独占、一个同步连接器改为消息连接器，虽然首先是结构变化，却会改变性能、可用性、一致性、安全和运维。高级架构设计师需要从静态结构出发，分析其对动态行为和质量属性的影响。

二、静态架构的基本元素

1. 组件

组件可以是模块、服务、库、数据库、缓存、消息主题、设备或外部系统。定义组件时要说明职责、接口、数据所有权、生命周期、部署位置和质量要求。组件边界不清，会导致变化相互传播。

2. 连接器

连接器包括函数调用、进程调用、HTTP、RPC、消息队列、事件总线、数据库访问、文件传输和人工流程。连接器不仅表示“相连”，还包含同步/异步、可靠性、顺序、超时、认证、重试和容量等属性。

3. 配置和拓扑

配置规定组件如何组合、连接到哪些依赖、使用哪些参数和权限；拓扑规定组件部署在哪些节点、区域、网络和故障域。静态演化常常表现为拓扑扩展、服务迁移、主备调整和环境分层。

4. 约束

层次依赖、数据所有权、接口契约、禁止循环、资源上限和安全边界都是静态结构约束。结构改造必须说明哪些约束保持不变，哪些约束需要演化。

三、静态演化的主要形式

1. 组件新增与删除

新增组件用于承载新能力、隔离变化或提升质量属性。删除组件需要确认没有调用、消息、定时任务、报表和权限依赖。删除前应设置观察窗口和使用监控，避免遗漏隐式消费者。

2. 组件拆分与合并

拆分可以按业务能力、变化频率、团队边界、扩展需求和故障域进行。拆分后会引入网络、部署、数据和观测成本。合并可以降低调用和运维复杂度，但可能扩大故障影响和发布范围。选择不能只依据组件数量。

3. 连接器替换

从同步调用变为异步消息可以提高解耦和吞吐，但会改变时序、一致性和用户体验；从消息变为同步调用可以简化流程，却可能增加耦合和级联故障。连接器替换要重新定义超时、重试、幂等、顺序和补偿。

4. 接口和契约演化

接口新增、删除、版本化和语义调整都属于静态架构变化。要处理旧客户端、第三方、离线任务和测试脚本。接口目录、契约测试和监控应随结构变化更新。

5. 数据存储和所有权调整

共享数据库拆分、缓存引入、数据分区、主从调整和对象存储迁移，都会改变静态结构。必须明确数据的权威来源、读写路径、迁移方式和一致性策略。

6. 部署拓扑演化

单机变集群、单区域变多区域、虚拟机变容器、固定节点变弹性节点，都属于拓扑演化。需要重新评估网络、存储、证书、配置、监控、故障域和成本。

四、静态演化的影响分析

1. 依赖影响

识别直接调用者、间接消费者、数据读写者、消息订阅者和运维脚本。静态图中未画出的依赖尤其危险，可以通过代码扫描、配置搜索、运行链路、数据库权限和日志反查发现。

2. 质量属性影响

组件拆分可能提升独立发布和隔离，但增加网络延迟和故障模式；缓存可能提升性能，但引入一致性和失效问题；多区域部署提升可用性，但增加数据同步和运维成本。影响分析要根据质量场景量化，而不是只写“提高扩展性”。

3. 数据影响

结构变化可能改变数据读写顺序、事务边界和历史数据访问。迁移前要确定新旧数据谁是权威，如何双读、双写、回填和对账，如何处理迁移失败和回滚。

4. 组织影响

组件边界通常对应团队边界、权限和发布责任。拆分服务后，如果没有明确所有者和值班能力，结构上的独立并不等于可运维。架构静态演化需要同步调整文档、权限、流水线和责任矩阵。

五、静态演化中的兼容和过渡

1. 外观和适配器

通过外观统一旧组件接口，或用适配器转换新旧协议，减少一次性改动范围。适配器应只负责边界转换，不要把复杂业务规则永久堆积其中。

2. 绞杀式迁移

围绕稳定边界逐步用新组件替换旧组件，流量按功能或租户切换。每次替换都要验证功能、性能、数据和回滚，旧组件只有在没有流量和依赖后才能下线。

3. 双读和双写

适合数据存储或查询结构迁移。双读需要比较结果和处理差异，双写需要处理部分成功、顺序、重试和补偿。双写不是天然可靠，必须有对账、重放和退出计划。

4. 影子流量

将真实请求复制到新组件但不影响用户结果，用于比较性能、错误和输出差异。影子执行要隔离副作用，避免新组件重复扣款、发消息或修改生产数据。

5. 版本共存

接口、消息和数据库变化需要允许旧新版本并存。部署顺序通常遵循先扩展能力、再迁移消费者和数据、最后收缩旧结构，避免滚动发布期间出现不兼容。

六、静态架构治理

1. 架构目录和依赖图

维护组件、接口、数据、部署节点、所有者和依赖关系的目录。依赖图要能查询谁调用谁、谁读写什么数据、谁订阅什么消息以及哪个故障域共享资源。

2. 规则和门禁

将层次依赖、禁止直接访问、接口版本、数据权限和部署约束转化为自动检查。新代码、新配置和新基础设施进入流水线前执行门禁，减少靠人工记忆维持结构。

3. 版本和决策记录

静态架构图、接口契约、数据模型、部署拓扑和架构决策都要版本化。结构变化要说明原因、影响、迁移、回滚和验证指标，避免“图先于系统”或“系统先于文档”长期存在。

4. 运行反馈

通过调用链、资源、变更和故障数据验证静态结构是否符合实际。未被调用的组件、频繁超时的连接器、共享资源热点和跨层访问，都是结构需要重新评估的信号。

七、案例分析：共享数据库拆分

某管理系统包含用户、订单、库存和报表四个模块，所有模块直接访问同一数据库。随着业务增长，订单发布经常需要等待报表脚本完成，库存高峰查询影响用户登录。项目决定将订单和库存拆分为独立服务和数据库。

静态演化方案不能只增加两个数据库。首先建立现状目录，识别表的读写者、事务边界、报表、存储过程、定时任务和数据同步；其次定义订单和库存的数据所有权，以及用户和报表的合法访问方式；再次建立领域接口和事件，逐步将新代码从直接访问切换到接口；对历史数据采用回填、双读和对账；对报表使用只读副本或数据服务，避免跨领域直接读写。

发布过程中先增加新结构和适配层，再迁移消费者，最后撤销旧权限。监控直接数据库访问、数据差异、跨服务延迟、库存一致率和发布失败率。只有当旧访问没有流量、数据对账稳定、回滚方案验证完成后，才能删除共享表访问路径。

八、综合知识练习

题1

静态架构演化为什么会影响动态质量属性？

参考答案：组件、连接器、数据和拓扑的改变会改变调用时延、事务边界、故障传播、资源使用、部署和恢复方式，因此静态结构变化会直接影响性能、可用性、一致性和安全性。

题2

组件拆分时应重点分析哪些成本？

参考答案：网络调用和延迟、分布式事务、消息可靠性、幂等与补偿、部署监控、数据迁移、团队运维、故障定位和基础设施成本，不能只看代码模块是否独立。

题3

共享数据库拆分为什么需要先梳理读写者？

参考答案：未知读写者会在迁移后继续绕过新服务，造成数据不一致和隐性依赖。梳理读写者可以明确数据所有权、迁移范围、兼容策略和旧权限退出条件。

九、论文写作素材

论文中可以这样描述静态架构演化：

“针对系统组件耦合、共享数据库和部署相互阻塞的问题，我先建立组件、连接器、数据、部署和责任人目录，通过代码、配置和运行链路识别隐性依赖。演化时按照业务边界拆分组件，明确数据所有权，使用接口和事件替代跨模块直接访问；迁移阶段采用适配器、双读校验、影子流量和灰度切换，保持新旧结构兼容。对每次结构变化重新评估性能、可用性、一致性和运维成本，并通过架构规则、契约测试、权限门禁和运行监控防止旧依赖回流，最终以数据差异、发布周期、故障影响范围和恢复时间验证效果。”

十、今日复盘

静态演化关注组件、连接器、接口、数据、配置和部署拓扑的变化。
静态结构变化会传导到性能、可用性、一致性、安全和运维。
组件拆分和连接器替换必须分析依赖、事务、消息、补偿和观测成本。
大型结构迁移应采用适配器、灰度、双读、双写和版本共存。
目录、自动化门禁、架构决策和运行反馈是静态治理的基础。
案例答题要写清现状依赖、目标边界、过渡步骤、验证指标和退出条件。