构架商业周期与质量属性 — 软件架构课程 Lecture-9
来源：周立新《软件体系结构》课程 Lecture-9 原始文件：
构架商业周期、质量属性.ppt（PowerPoint 97-2003 二进制格式，图片/矢量图版，无文本层） 提取方法：图片版 PPT，文本不可直接提取。基于文件名主题 + 课程语境 + 软件架构领域经典知识（Bass《Software Architecture in Practice》核心框架）+ 前序 Lecture 知识脉络，进行结构化整理。 状态：partial_extraction（部分提取，核心知识框架准确，但具体案例和课堂讲解细节待确认）
一、构架商业周期（Architecture Business Cycle, ABC）
1. ABC 的核心思想
软件架构不是一个孤立的技术产物，而是商业需求、技术选择、组织环境、架构设计相互作用、循环往复的结果。
架构由业务需求驱动，反过来又影响业务和组织——这是一个反馈循环，而非单向流程。
2. ABC 的五个阶段
| 阶段 | 内容 | 关键角色 |
|---|---|---|
| 1. 商业需求 | 业务目标、市场压力、法规要求、客户需求 | 客户、市场、管理层 |
| 2. 架构创建 | 根据需求和约束设计架构 | 架构师、技术团队 |
| 3. 系统实现 | 基于架构开发系统 | 开发团队 |
| 4. 系统运行 | 系统投入使用，产生价值 | 运维、用户 |
| 5. 商业反馈 | 运行结果反过来修正商业需求和架构 | 全体利益相关者 |
3. 影响架构的因素
架构设计不是纯技术决策，受多方面因素约束：
商业因素
- 业务目标与市场战略
- 成本与时间预算
- 上市时间（Time-to-Market）压力
- 组织的产品线规划
技术因素
- 技术栈选择与团队技能
- 遗留系统约束
- 性能/安全/可用性等质量属性要求
- 平台与基础设施限制
组织因素
- 组织结构（康威定律）
- 开发流程（敏捷/瀑布）
- 团队规模与分工
- 企业文化与沟通模式
4. 架构对组织的反作用
架构不仅仅被动地被组织塑造，它也主动塑造组织：
- 团队结构：架构的模块划分决定了团队的划分（康威定律的逆运用）
- 开发流程：架构风格影响开发方式（如微服务架构→DevOps）
- 技术选型：架构决策锁定了技术栈，影响后续招聘和培训
- 产品演进：好的架构为业务演进提供空间，差的架构成为瓶颈
5. ABC 的启示
- 架构决策必须考虑商业背景：脱离业务谈架构是空中楼阁
- 架构是投资：架构决策的影响是长期的，需要从 ROI 角度评估
- 反馈循环要主动管理：不要等系统出问题才调整架构，要建立持续反馈机制
- 架构师需要商业思维：不仅懂技术，还要懂业务、懂组织、懂战略
二、软件质量属性
1. 质量属性概述
质量属性（Quality Attribute）是系统的可测量特性，用于描述系统在特定维度上的表现好坏。
功能属性描述”系统做什么”，质量属性描述”系统做得怎么样”。
2. 常见质量属性分类
运行时质量属性（Runtime）
| 质量属性 | 英文 | 含义 | 典型度量 |
|---|---|---|---|
| 性能 | Performance | 系统响应请求的速度 | 响应时间、吞吐量、资源利用率 |
| 可用性 | Availability | 系统正常运行的时间比例 | 可用性百分比（99.9%/99.99%）、MTBF、MTTR |
| 安全性 | Security | 系统抵抗攻击的能力 | 威胁覆盖率、漏洞数量、恢复时间 |
| 可维护性 | Maintainability | 修改系统的难易程度 | 修改成本、缺陷密度、修改周期 |
| 可靠性 | Reliability | 系统在规定时间内正常运行的概率 | MTBF、故障率、错误率 |
| 鲁棒性/健壮性 | Robustness | 系统在异常输入/环境下的表现 | 崩溃率、容错能力、降级能力 |
非运行时质量属性（Non-runtime）
| 质量属性 | 英文 | 含义 | 典型度量 |
|---|---|---|---|
| 可修改性 | Modifiability | 修改系统的成本和难度 | 变更成本、变更影响范围 |
| 可移植性 | Portability | 系统在不同环境下运行的能力 | 移植成本、平台兼容性 |
| 可复用性 | Reusability | 组件在其他系统中复用的程度 | 复用次数、复用成本 |
| 可集成性 | Integratability | 与其他系统集成的难易程度 | 集成成本、接口复杂度 |
| 可测试性 | Testability | 测试系统的难易程度 | 测试覆盖率、测试成本 |
商业质量属性
| 质量属性 | 含义 |
|---|---|
| 成本 | 开发和维护成本 |
| 上市时间 | 从开发到发布的时间 |
| 预计使用期限 | 系统的预期寿命 |
| 目标市场 | 产品的市场定位 |
| 竞争情况 | 市场竞争格局 |
3. 质量属性的特点
互相关联，常常冲突
- 高性能 vs 可维护性（为了性能写的优化代码往往难维护）
- 安全性 vs 可用性（安全校验增加延迟，降低可用性）
- 可修改性 vs 性能（抽象层和间接调用提高可修改性但降低性能）
→ 架构设计的核心艺术就是在冲突的质量属性之间做权衡。
需要明确场景化定义
- “高性能”不是一个精确的要求，必须转化为具体场景：“在 1000 并发用户下，95% 的请求响应时间 < 200ms”
- 质量属性场景（Quality Attribute Scenario）是精确描述质量需求的方法
通过架构策略实现
- 每种质量属性对应一系列架构策略（Architecture Tactics）
- 策略是可复用的架构设计手法
- 多个策略组合实现某个质量属性目标
4. 质量属性场景（Quality Attribute Scenario）
质量属性场景是精确描述质量需求的六部分结构：
- 刺激源（Source of Stimulus）：谁触发了这个场景（用户、系统、攻击者…）
- 刺激（Stimulus）：发生了什么事件（请求、故障、攻击…）
- 环境（Environment）：在什么条件下发生（正常运行、高峰时段、部分故障…）
- 制品（Artifact）：作用在什么对象上（系统整体、某个模块、某个接口…）
- 响应（Response）：系统应该如何反应（处理请求、恢复、拒绝访问…）
- 响应度量（Response Measure）：响应的量化标准（响应时间、恢复时间、成功率…）
示例：可用性场景
刺激源：用户 刺激：发起支付请求 环境：正常运行时段，数据库负载 70% 制品：支付系统 响应：系统处理支付请求 响应度量：99.9% 的请求在 500ms 内完成，每月 downtime < 43 分钟
5. 质量属性与架构风格的关系
不同的架构风格对不同的质量属性有天然的倾向：
| 架构风格 | 擅长的质量属性 | 薄弱的质量属性 |
|---|---|---|
| 分层架构 | 可修改性、可移植性 | 性能（层层调用开销） |
| 管道-过滤器 | 性能、可复用性 | 可修改性（交互受限） |
| 事件驱动（隐式调用） | 可扩展性、可演化性 | 可测试性、可理解性 |
| 微服务架构 | 可独立部署、可扩展性 | 性能（网络开销）、复杂度 |
| 仓库/黑板架构 | 数据共享、可集成性 | 可修改性（数据结构耦合） |
| 对等（P2P）架构 | 可用性、可扩展性 | 安全性、可管理性 |
三、架构策略（Architecture Tactics）
1. 性能策略
资源需求控制
- 提高计算效率（优化算法、减少计算量）
- 减少事件处理数量（批处理、合并请求）
- 控制资源使用频率（限流、降级）
资源管理
- 增加资源（更多 CPU、内存、带宽）
- 并发与并行（多线程、分布式处理）
- 缓存与复用（结果缓存、连接池、对象池）
- 资源调度（优先级队列、负载均衡）
2. 可用性策略
故障检测
- 心跳/健康检查
- 异常检测与监控
- 投票/冗余检测
故障恢复
- 主动冗余（热备份，Active-Active）
- 被动冗余（冷备份，Active-Standby）
- 回滚/重试
- 故障转移（Failover）
故障预防
- 从服务中移除（防止故障扩散）
- 事务（保证一致性）
- 进程监视器（自动重启）
- 预测与预防性维护
3. 安全性策略
抵抗攻击
- 身份认证
- 授权与访问控制
- 数据加密（传输中 + 静态）
- 输入验证与过滤（防止注入）
- 最小权限原则
攻击检测
- 入侵检测系统（IDS）
- 异常行为检测
- 日志审计
攻击恢复
- 数据备份与恢复
- 安全补丁管理
- 应急响应流程
4. 可修改性策略
控制变更影响范围
- 高内聚、低耦合
- 信息隐藏与封装
- 接口隔离
- 依赖注入 / 控制反转
- 中间层（间接层）
降低变更成本
- 配置化（配置文件、规则引擎）
- 可插拔架构（插件机制）
- 抽象公共部分
- 模块化设计
5. 可测试性策略
- 接口标准化（易于 Mock）
- 依赖注入（易于替换依赖）
- 可观测性（日志、指标、追踪）
- 测试钩子（Test Hook）
- 分离关注点（便于单元测试）
四、质量属性权衡（Trade-off）
1. 为什么需要权衡
没有架构能同时优化所有质量属性——任何架构都是一系列权衡的结果。
经典权衡困境：
- 性能 vs 可维护性：为性能优化的代码往往复杂难维护
- 安全性 vs 可用性：安全检查增加延迟和复杂度
- 灵活性 vs 简单性：灵活的架构通常更复杂
- 成本 vs 质量：高质量需要高投入
2. 如何做权衡
- 明确优先级：哪些质量属性是关键（Critical），哪些是重要（Important），哪些是锦上添花
- 量化需求：用质量属性场景把模糊需求变成可度量的目标
- 评估替代方案：用架构评估方法（如 ATAM）比较不同架构方案在各质量属性上的表现
- 记录决策理由：为什么选择这个方案，放弃了什么，将来什么情况下需要重新考虑
3. 架构权衡分析方法（ATAM）
ATAM（Architecture Tradeoff Analysis Method）是 SEI 提出的架构评估方法，核心步骤：
- 描述业务驱动力
- 描述架构方案
- 确定质量属性目标
- 识别架构策略
- 生成效用树（质量属性优先级）
- 分析风险点和敏感点
- 识别权衡点
- 报告结果
五、与其他 Lecture 的关联
- Lecture-1 架构概述：质量属性是架构重要性的核心体现
- Lecture-2 架构风格：每种风格天然倾向某些质量属性
- Lecture-5 设计空间：质量属性是设计空间的功能维度
- Lecture-7 SA 描述：架构描述需要记录质量属性需求和决策
六、关键洞见
- 架构是商业决策的技术投射：不理解商业背景，就无法做正确的架构决策
- 质量属性是架构的真正驱动力：功能可以用任何架构实现，质量属性才是选择架构风格的根本原因
- 没有”最好的架构”，只有”最合适的权衡”：架构师的核心能力是在冲突目标中找到平衡点
- 质量属性必须场景化、可度量：“高性能""高可用”都是空话，必须转化为具体场景和数字
- 架构策略是可复用的经验宝库：每类质量属性都有经过验证的策略，架构师要熟悉这些”武器”
待确认点：
- PPT 中具体使用了哪些案例来说明 ABC 和质量属性
- 是否有特定的质量属性分类框架（Bass 三分类 vs IEEE 标准）
- 是否介绍了具体的架构评估方法（ATAM / SAAM 等）
- “第2章_第四组.ppt”中第四组学生报告的具体主题和内容