基于架构的软件设计方法

原创于 2026-07-16 08:24:53 发布 · 224 阅读

本内容遵循CC 4.0 BY-SA版权协议

一、项目概述与个人职责

2020年4月，我所在的公司启动了基础架构管理平台项目的研发工作。随着公司业务的高速增长，超过五千台服务器以及大量Kafka、Redis、Zookeeper等中间件实例的维护工作投入了巨大的人力成本，但由于缺乏规范化的维护体系支撑，线上事故频发。该项目旨在为基础架构团队提供基础设施标准化、中间件集中化管理、负载均衡管理和任务管理平台四大核心功能，实现基础架构工作的降本增效与可靠性提升。

项目历时15个月，团队共计12人。我作为该项目的架构设计师，主要负责架构设计、架构评估与架构演化的全流程管理工作。

二、ABSD方法的实施阶段与主要工作

基于架构的软件设计（Architecture-Based Software Design，ABSD）方法是由构成体系结构的商业、质量和功能需求的组合驱动的，是一个自顶向下、递归细化的软件开发方法。ABSD方法有三个基础：功能的分解（使用基于模块的内聚和耦合技术）、选择体系结构风格（实现质量和商业需求）、以及软件模板的使用。

ABSD模型将整个基于体系结构的软件过程划分为六个子过程：体系结构需求、设计、文档化、复审、实现和演化。

（一）体系结构需求阶段

该阶段需要明确用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。主要活动包括：

需求获取：提取系统相关的功能需求和质量属性，目标是为商业、用户及开发人员目标服务。需求获取来自三个方面：系统的质量目标、系统的商业目标、系统开发人员的商业目标。
标识构件：首先生成类图，然后对类进行分组（通过继承、聚合或合成关系），最后将类打包成构件。
架构需求评审：组织由用户、系统分析师、架构师、设计实现人员等组成的小组，审查需求是否真实反映用户要求、构件合并是否合理等。

（二）体系结构设计阶段

该阶段是一个迭代过程，利用架构需求生成并调整架构决策。主要活动包括：

提出架构模型：选择合适的架构风格，产生理想化的体系结构模型。
构件映射：将已标识的构件映射到软件体系结构中。
分析构件交互：分析构件之间的相互作用。
设计评审：由外部专家参与，保证架构设计的客观性与质量。

（三）体系结构文档化阶段

文档是在系统演化的每一个阶段，系统设计与开发人员的通信媒介。主要活动是对架构设计进行分析与整理，生成两份核心文档：体系结构规格说明和测试体系结构需求的质量设计说明书。

（四）体系结构复审阶段

在一个主版本的软件架构分析之后，需要安排一次由外部人员（客户代表和领域专家）参加的架构复审。复审的目的是标识潜在的风险，及早发现体系结构设计中的缺陷和错误。需要评价架构是否满足需求、质量属性需求是否在架构中得以体现、层次是否清晰、构件划分是否合理等。

（五）体系结构实现阶段

实现以文档化说明书为基础。主要活动包括：架构分析与设计、构件实现、构件组装（基于架构关系）和系统测试（包括功能测试、交互兼容性测试和性能测试）。

（六）体系结构演化阶段

该阶段主要解决用户在系统开发过程中发生的需求变更问题。演化流程包括：归类需求变化、拟定架构演化计划、修改构件、更新构件交互关系、重新组装与测试、技术评审、输出新的架构版本。

三、ABSD方法在本项目中的具体应用

（一）架构需求阶段：多维度需求捕获与构件识别

在需求获取环节，我采用了多种需求获取技术的组合——用户访谈、原型设计和联合需求计划（JRP）等方法，全面捕获了功能需求与非功能需求。功能需求方面，明确了基础设施标准化、中间件集中化管理、负载均衡管理和任务管理四大模块的具体功能；非功能需求方面，将高可用性、可扩展性和安全性作为核心质量属性。

在标识构件环节，我首先确定了系统的基本结构，对基本结构进行分组，经过调整后打包为构件。例如，将基础设施模块分解为“服务器管理构件”“网络设备管理构件”“系统模板构件”；将中间件模块分解为“Kafka管理构件”“Redis管理构件”“Zookeeper管理构件”等。最后，组织了由用户代表、分析师和开发人员参加的架构需求评审，确保需求的准确性和构件划分的合理性。

（二）架构设计阶段：风格选择与构件映射

基于需求分析结果，我选择了微服务架构风格，理由是各业务模块（基础设施、中间件、负载均衡、任务管理）功能边界清晰、相对独立，适合采用微服务实现高内聚、低耦合。

在构件映射环节，我将需求阶段识别的各个构件逐一映射到微服务架构中。例如，“Kafka管理构件”被设计为独立的“中间件管理服务”，“负载均衡管理构件”被设计为独立的“负载均衡服务”。同时，我使用UML 4+1视图进行架构建模，从逻辑视图、进程视图、物理视图、开发视图和场景视图五个维度全面描述系统架构。在设计评审环节，邀请了外部架构专家参与，重点评审了服务间通信机制（采用RabbitMQ消息队列实现异步通信）、数据一致性方案和故障隔离策略。

（三）架构文档化阶段：规范输出与质量保障

我组织团队生成了两份核心文档：体系结构规格说明详细描述了各微服务的接口定义、通信协议、部署拓扑和配置规范；质量设计说明书针对高可用性需求定义了熔断策略、重试机制和降级方案，针对安全性需求定义了认证授权和审计日志方案。这些文档成为后续开发、测试和维护的基础依据。

（四）架构复审阶段：风险识别与缺陷发现

在完成主版本架构设计后，我组织了由客户代表和领域专家参加的架构复审。复审的重点包括：架构是否满足高并发场景下的性能需求、质量属性是否在设计中得到充分体现、微服务划分的粒度是否合理、构件之间的依赖关系是否清晰。通过复审，我们识别出“负载均衡配置变更可能导致服务中断”的风险，并提前设计了配置灰度发布方案。

（五）架构实现阶段：构件开发与系统组装

在实现阶段，团队按照架构规格说明进行构件开发。每个微服务作为一个独立构件进行编码实现，然后基于架构定义的交互关系进行构件组装。测试工作覆盖了构件级单元测试、服务间交互兼容性测试和全链路性能测试。

（六）架构演化阶段：需求变更的持续应对

项目开发过程中，业务部门不断提出新的需求——如新增中间件类型支持、扩展负载均衡策略等。我按照ABSD的演化流程处理每一次变更：首先归类需求变化并评估影响范围，然后拟定架构演化计划，确定需要修改或新增的构件，更新构件间的交互关系，完成重新组装与测试后，组织技术评审并发布新的架构版本。这一机制保证了系统在持续迭代中始终保持架构的清晰性和一致性。