【Day 13】多质量属性权衡：电商大促架构设计（性能 vs 可用性 vs 成本）
一、题目还原
某头部电商平台计划承接一年一度的"618"大促活动，活动期间预计峰值流量为日常的20倍：核心下单链路峰值QPS约100万，商品详情页峰值QPS约1000万，活动持续3天。平台现有系统为微服务架构（Spring Cloud + 注册中心 + API网关），数据库采用MySQL主从集群，缓存采用Redis集群，全文检索采用Elasticsearch。大促期间系统需满足以下要求：
(1) 性能 ：下单接口99%的请求响应时间不超过300ms，详情页首屏响应时间不超过200ms；
(2) 可用性 ：大促期间系统可用性不低于99.99%（全程停机时间不超过30秒），任何单点故障不得导致核心链路中断；
(3) 成本 ：技术部门预算有限，要求新增IT资源成本（服务器、带宽、云资源）较去年大促增幅不超过30% ；
(4) 大促峰值持续时间短（3天），平时资源利用率仅约15%，要求方案能兼顾"扛得住峰值"与"平时不浪费"。
架构团队提出了三个关键设计决策待评审：① 多级缓存 + 异步削峰 ；② 限流 + 降级 + 熔断 ；③ 弹性伸缩（按峰值容量预留 vs 动态扩容）。请从多质量属性权衡的角度回答以下问题。
【Q1】（8分） 请分别构造"性能""可用性""成本"三个质量属性场景（要求包含场景六元素：刺激源-刺激-环境-制品-响应-响应度量）。
【Q2】（9分） 针对上述三个设计决策，分析每个决策分别提升了哪些质量属性、牺牲了哪些质量属性，指出其中的权衡点（Tradeoff Point）与敏感点（Sensitive Point）。
【Q3】（8分） 结合"峰值短、平时闲"的流量特征，从成本角度比较"按峰值容量预购资源"与"弹性伸缩（弹性扩容/缩容）"两种方案，给出推荐方案并说明理由；若活动期间某核心服务出现性能瓶颈，请给出完整的处理策略（含战术名称）。
二、考点分析
| 项目 | 内容 |
|---|---|
| 核心考点 | 多质量属性权衡（性能/可用性/成本三角）+ 质量属性场景构造 + 敏感点/权衡点识别 + 弹性伸缩容量规划 |
| 所属章节 | 软件架构设计------质量属性与架构评估（场景六元素、ATAM敏感点/权衡点）；系统架构设计------成本效益 |
| 对应模板 | 模板二：质量属性与战术分析 （场景6元素 + 战术列表）＋ 模板四：方案评价（两方案对比 + 推荐理由） |
| 本题难度 | ★★★★★（大促/高并发场景是案例题最高频背景，"权衡"是架构师核心能力，每年必考） |
三、标准答案（采分点格式）
【Q1】三个质量属性场景构造（8分，每场景2~3分）
（1）性能场景（3分）：
- 刺激源：大量并发用户（消费者）；
- 刺激：大促开始瞬间集中发起下单请求（峰值100万QPS）；
- 环境：系统处于大促峰值负载状态；
- 制品：下单服务及订单处理链路；
- 响应：系统在限定时间内完成订单创建并返回下单成功结果；
- 响应度量：99%的请求响应时间 ≤ 300ms，且系统不因过载而拒绝服务。
（2）可用性场景（3分）：
- 刺激源：硬件/软件故障（如某机房断电、订单服务节点宕机）；
- 刺激：大促进行中订单服务集群部分节点发生故障；
- 环境：系统满负载运行、流量持续高位；
- 制品：订单服务集群及依赖的数据库、缓存；
- 响应：系统自动检测故障并将流量切换到健康节点，服务不中断；
- 响应度量：故障切换时间 < 10s，可用性 ≥ 99.99%（3天总停机 ≤ 30s），零数据丢失。
（2分，成本场景，注意成本也可场景化）：
- 刺激源：公司管理层/财务部门；
- 刺激：大促容量规划审批，要求支撑100万QPS峰值；
- 环境：平时资源利用率仅15%、预算增幅上限30%；
- 制品：基础设施资源池（计算/存储/带宽）；
- 响应：按需提供弹性资源，峰值期扩容、低谷期缩容，实际支出在预算内；
- 响应度量：大促期间资源成本增幅 ≤ 30%，平时资源利用率提升至 40% 以上。
【Q2】三个决策的质量属性权衡分析（9分，每决策3分）
（1）决策①：多级缓存 + 异步削峰（3分）
- 提升的质量属性 ：性能 ------本地缓存（Caffeine）+ Redis分布式缓存 + CDN 三级缓存大幅减少对数据库的访问，降低响应时间、提升吞吐量；引入消息队列（MQ）将下单请求异步化，实现削峰填谷，平滑流量尖峰（性能+可用性双受益：削峰后系统负载可控，不易被打垮）。
- 牺牲的质量属性 ：一致性（数据正确性） ------缓存与数据库数据可能短暂不一致（缓存穿透/击穿/雪崩风险）；异步化使下单结果非实时返回，用户需等待异步通知，响应体验延迟 、库存扣减改为最终一致；可修改性/复杂度 ------引入缓存与MQ增加系统复杂度和故障点；成本------缓存集群与MQ集群需要额外资源。
- 权衡点 ：缓存是典型的权衡点------提升性能、牺牲一致性、增加成本 ；MQ异步化------提升吞吐与可用性（削峰），牺牲强一致性与实时性。
（2）决策②：限流 + 降级 + 熔断（3分）
- 提升的质量属性 ：可用性------限流（令牌桶/漏桶）保护系统不被超预期流量打垮；降级主动关闭非核心功能（如评论、积分、推荐）保障核心下单链路；熔断（如Sentinel/Hystrix）在依赖故障时快速失败，防止故障级联扩散（服务雪崩）。
- 牺牲的质量属性 ：性能（用户体验） ------超限请求被直接拒绝或排队，部分用户看到"系统繁忙"；功能完整性------降级期间部分非核心功能不可用。
- 战术归类（采分点） ：限流 = 资源需求战术（管理事件率） ；降级 = 资源需求战术（管理事件率/减少计算开销） ；熔断 = 故障预防战术（防止级联故障，保护性停止）。
- 敏感点：限流阈值设置是敏感点------阈值过高则保护失效（可用性下降），阈值过低则误杀正常用户（性能体验下降），且对"峰值QPS预估"高度敏感。
（3）决策③：弹性伸缩（3分）
- 提升的质量属性 ：成本效率（成本） ------按需扩容缩容，平时只保留基础容量（约15%利用率），峰值自动扩容，避免资源闲置浪费；同时通过多副本横向扩展提升性能与可用性（副本即冗余）。
- 牺牲的质量属性 ：可用性（风险） ------扩容需要时间（冷启动/镜像拉取分钟级），若流量瞬时暴涨超出扩容速度，仍可能过载；弹性伸缩依赖云平台能力，本身引入新的故障点；成本可控性------峰值扩容按量计费，若峰值预估不准或流量异常，成本可能失控。
- 敏感点 ：扩容启动时间 是敏感点------扩容越快，越能应对流量尖峰，但对平台调度能力要求越高；容量预估准确性对成本与可用性双重敏感。
【Q3】容量方案对比与性能瓶颈处理策略（8分）
（1）两种方案对比（4分）：
| 维度 | 按峰值容量预购资源 | 弹性伸缩（按需扩缩容） |
|---|---|---|
| 资源准备 | 按100万QPS峰值一次性采购/预留（约需200台应用节点） | 平时约30台，峰值自动扩容至200台，峰值后自动缩容 |
| 成本 | 全年按峰值计费，资源长期闲置（利用率15%），成本高、浪费大 | 仅峰值期按量付费，平时成本低，总体成本可降低40%以上 |
| 可用性 | 容量充足，抗突发能力强，但存在"估错峰值"风险（备多了浪费、备少了仍会挂） | 需预留扩容时间窗口，对瞬时尖峰（分钟级暴涨）响应能力弱 |
| 运维复杂度 | 低（资源固定） | 高（需弹性策略、扩容预案、压测验证） |
（2）推荐方案（2分）： 推荐**"弹性伸缩为主 + 峰值预置为辅"的混合方案**：大促前通过压测确定容量基线，提前24小时预置扩容至峰值容量的70%80%（应对瞬时尖峰），剩余20%30%由弹性伸缩自动补齐；大促结束自动缩容。理由：① 兼顾成本（平时不浪费）与可用性（峰值有保障）；② 化解了"扩容时间窗"与"流量瞬时尖峰"的矛盾；③ 预算增幅控制在30%以内，满足约束(3)。
（3）性能瓶颈处理策略（2分，按战术分类作答）：
① 资源需求战术 ：开启/加大限流 （管理事件率）、降级 非核心功能（减少计算开销）、缓存预热 +缓存热点数据（减少计算开销）；
② 资源管理战术 ：对该服务水平扩容 （增加可用资源）、负载均衡多副本 分摊流量（维护多个副本）、引入并发/异步（引入并发）；
③ 资源仲裁战术 ：为高优先级请求（如下单支付）配置优先级队列/调度策略 ，保证核心请求优先处理；
④ 可用性战术 ：对瓶颈服务实施熔断保护，防止故障扩散；监控告警（异常检测）持续观察指标，动态调整阈值。
四、评分要点
必答采分点（拿满基础分）：
- Q1：三个场景均六元素齐全 （缺一个元素扣对应分）；性能/可用性场景的响应度量必须可量化（≤300ms、≥99.99%），成本场景要有预算约束数字；
- Q2：每个决策必须同时答出"提升什么、牺牲什么"，只答一面不给全分；"权衡点"定义（影响多个质量属性的决策点）与**"敏感点"定义**（对单一属性高度敏感）表述准确；决策②的战术归类（限流=资源需求战术等）必须用教材术语；
- Q3：两方案对比至少从成本、可用性、运维 三个维度；推荐方案要有明确理由；瓶颈处理策略必须出现战术名称（限流/降级/熔断/水平扩容至少4个）。
加分项（拉开差距）：
- 点出"大促场景 = 性能 vs 可用性 vs 成本三角权衡"的本质，说明架构师职责就是在冲突属性间做取舍；
- 提到削峰填谷、缓存三级架构（本地+分布式+CDN）、消息队列异步化等具体手段；
- 成本计算意识：能估算"200台 vs 30台"的容量差异或说出"弹性伸缩可降低40%以上成本"；
- 提及工具（Nginx/LVS、Redis、Kafka/RocketMQ、Sentinel/Hystrix、K8s HPA）；
- 将"限流算法"答出细节：令牌桶（允许突发）适合大促、漏桶（恒定速率）适合保护下游。
常见失分点：
- 场景六元素写不全或把"响应"与"响应度量"混为一谈；
- 只谈性能不谈牺牲（如只写"缓存提升性能"，不写"缓存与数据库一致性变差"）；
- 混淆权衡点 与敏感点（口诀：权衡点=跷跷板，影响多属性；敏感点=箭靶子，单属性受影响大）；
- 弹性伸缩方案只写优点不写"扩容时间窗"风险，显得不专业。
五、扩展知识点
1. 关联《质量属性与架构评估》（07）： 本题是"模板二"的完整演练------质量属性场景六元素（刺激源→刺激→环境→制品→响应→响应度量）+ 性能三大类战术（资源需求/资源管理/资源仲裁）全部命中；限流属"资源需求-管理事件率"，弹性伸缩属"资源管理-增加可用资源"，务必会默写分类。
2. 关联《ATAM效用树》： 大促场景的效用树可这样建------根（大促系统效用）→ 性能：下单RT<300ms（H,H）→ 方法：多级缓存 → 权衡点 ：缓存一致性；可用性：99.99%（H,H）→ 方法：冗余+熔断 → 敏感点 ：限流阈值；成本：增幅≤30%（H,M）→ 方法：弹性伸缩 → 风险点：扩容时间窗。ATAM第6步"识别敏感点、权衡点、风险点"正是本题Q2的原型。
3. 关联《易混淆对照表》： ① 性能 vs 可伸缩性------性能好≠可伸缩性好（本案例中"预购200台"性能够但不可伸缩，"弹性伸缩"才体现可伸缩性）；② 服务降级 vs 熔断------降级是主动 放弃非核心功能，熔断是被动 停止对失败依赖的调用（大促时两者配合使用）；③ CAP/BASE------异步削峰后库存扣减走最终一致性（BASE），与"下单强一致"链路（支付）分开设计。
4. 关联《必背公式速查卡》： ① 可用性公式 A = MTBF/(MTBF+MTTR)------99.99% = 年停机52.6分钟，3天窗口停机≤30秒，可据此倒推故障切换时间要求；② Amdahl定律 S = 1/((1-f)+f/k)------说明"只优化串行部分无法无限加速"，水平扩容对瓶颈服务的收益受限于非瓶颈部分，解释为什么扩容要"扩容瓶颈服务"而非全部服务。
5. 关联《答题模板》模板四（方案评价）： "方案一优点/缺点 → 方案二优点/缺点 → 推荐 → 从质量属性维度给理由"的框架，本题Q3就是标准应用；注意结合案例数字（100万QPS、15%利用率、30%预算增幅）作答，拒绝空泛。
6. 关联 Day09（性能战术·秒杀系统）与 Day08（可用性战术·双活数据中心）： 秒杀/大促类题目是"性能+可用性"双属性综合题，Day09讲透了缓存与限流细节，Day08讲透了故障检测与冗余切换；Day13在其之上增加成本维度，形成完整的"三角权衡"视角------复习时把三天内容合并为"高并发系统设计"专题。
六、今日金句
"架构设计的本质就是在相互冲突的质量属性之间做权衡------没有完美的架构，只有适合的取舍。大促场景下，用多级缓存和异步削峰换性能，用限流降级熔断保可用性，用弹性伸缩控成本，三者平衡才是合格的架构方案。"
（考试原话级表述：案例题中凡出现"多属性约束+预算限制"，结尾用此句收束，直接点明"权衡"主题，是阅卷人最想看到的架构师思维。）