案例分析专题

5选3 · 90分钟 · 每题约30分钟
← 首页

答题总策略

选题三原则: 1. 选你熟悉的领域(优先选工作中接触过的技术方向)
2. 选问题明确、不会产生歧义的题(有些题看似简单但问题模糊)
3. 选整套题中有多个子问题你都比较有把握的
时间分配: 每题不超过30分钟。先通读5道题(5分钟),确定3道目标题,然后按"最有把握→较有把握→一般"的顺序答题。

一、软件架构风格 (几乎每年必考)

案例分析中最常出现「识别架构风格+对比优缺点+选择建议」的组合题。

风格类别具体风格核心特点适用场景
数据流 管道-过滤器 组件通过管道连接,数据逐步处理。每个过滤器独立、可替换 编译器、数据处理管道、ETL
批处理 数据成批处理,步骤间无交互 银行对账、报表生成
数据中心 仓库风格 中央数据结构+独立组件。组件间不直接通信 IDE、数据库系统、编程环境
黑板风格 不确定性求解,多专家协作。知识源通过黑板间接交互 语音识别、图像识别、AI推理
调用/返回 分层风格 每层只调用下层,不可跨层。上层依赖下层 OSI七层模型、Web应用
客户端/服务器 C/S两层,客户端请求服务端响应 传统企业应用
面向对象 封装、继承、多态,对象间通过消息通信 通用软件开发
独立组件 事件驱动 事件发布-订阅模式。组件松耦合、异步通信 GUI、消息系统、IoT
微服务 独立部署的小服务,各自拥有独立数据库,通过轻量协议通信 大型互联网应用
答题套路: 识别架构风格时,注意题目中的关键词 — "管道"/"数据流"→管道过滤器; "黑板"/"知识源"→黑板风格; "发布"/"订阅"/"事件"→事件驱动; "独立部署"/"去中心化数据"→微服务; "层"/"上层下层"→分层。

二、架构评估方法 ATAM (高频考点)

ATAM 四大阶段

阶段主要活动产出
1. 表述 描述ATAM方法;介绍业务驱动;展示架构 架构描述文档、业务目标
2. 调查与分析 识别架构方法;生成效用树;分析架构方法;确定风险/非风险/敏感点/权衡点 效用树、场景优先级
3. 测试 对高优先级场景进行深入分析;评估架构是否满足质量要求 分析结果、场景覆盖度
4. 报告 汇报ATAM评估结果 最终评估报告

效用树 (Utility Tree)

效用树是ATAM的核心工具,将质量属性 → 具体场景 → (重要度, 实现难度)。结构如下:

根节点: 系统效用 ├─ 性能 (质量属性) │ ├─ 场景: 在1000并发下,响应时间不超过2秒 → (H, M) │ └─ 场景: 数据加密/解密延迟不超过50ms → (M, H) ├─ 可用性 │ ├─ 场景: 单节点故障时系统自动切换,5秒内恢复 → (H, M) │ └─ 场景: 计划内维护不影响服务 → (M, L) ├─ 安全性 │ └─ 场景: SQL注入攻击被WAF拦截 → (H, L) └─ 可修改性 └─ 场景: 新增支付方式不超过3天 → (M, M) (H=高, M=中, L=低)
关键概念 — 回答分析题必用: 敏感点(Sensitivity Point): 架构决策的微小变化会对某质量属性产生显著影响。如"缓存策略对性能的敏感度"。
权衡点(Tradeoff Point): 架构决策对多个质量属性的影响是相互矛盾的。如"加密增强安全性但降低性能"。
风险(Risk): 可能导致问题的架构决策。
非风险(Non-Risk): 被验证为合理的架构决策。

三、质量属性及场景 (高频考点)

6大核心质量属性

质量属性关注点典型场景实现策略
性能 响应时间、吞吐量、资源利用率 1000并发下响应<2s 缓存、CDN、异步、负载均衡、数据库索引、连接池
可用性 故障恢复时间、正常运行百分比 单节点故障5s内切换 冗余部署、心跳检测、故障转移、熔断、限流
安全性 认证、授权、保密性、完整性、不可否认 抵抗SQL注入/XSS/CSRF攻击 加密(TLS/AES)、WAF、OAuth/JWT、RBAC、审计日志
可修改性 变更成本、可扩展性 新增支付渠道不超过3天 接口抽象、依赖注入、设计模式(策略/适配器)、配置外部化
可测试性 可控性、可观察性 模块可在隔离环境中测试 依赖注入、Mock、接口隔离、日志、健康检查端点
易用性 学习成本、操作效率、错误防护 新用户5分钟内完成核心任务 统一交互规范、用户研究、A/B测试、引导设计
答题套路: 质量属性场景描述格式: 「在[特定条件]下,[刺激源]对系统[施加刺激],系统[响应],响应需满足[度量标准]」
例: "在正常负载下,用户发起查询请求,系统在2秒内返回结果列表"

四、设计模式速查 (案例分析高频)

常用设计模式

模式类型解决的问题关键点
策略模式行为型算法族在运行时可互换定义接口,各算法独立实现。如:多种支付方式、多种排序算法
观察者模式行为型一对多依赖,状态变化自动通知发布订阅、事件通知。如:消息推送、状态变更通知
工厂方法创建型延迟到子类决定实例化哪个类创建对象解耦。如:日志工厂创建不同Logger
抽象工厂创建型创建相关对象族保证产品族的兼容。如:UI主题控件族(Win/Mac)
适配器模式结构型接口不兼容的类协同工作包装转换。如:旧系统接口适配新系统
装饰器模式结构型动态给对象添加职责无侵入扩展。如:Java I/O流包装
代理模式结构型控制对象访问远程代理、保护代理、虚拟代理
模板方法行为型定义算法骨架,子类实现具体步骤好莱坞原则:"别调用我,我会调用你"
责任链行为型多个对象依次处理请求审批流程、过滤器链、拦截器
单例模式创建型类只有一个实例配置管理器、连接池、线程池
案例分析中回答设计模式题的套路:
1. 先识别问题场景(扩展性?耦合?变化点?)
2. 推荐合适的模式
3. 用一句话说明为什么这个模式合适
4. 画出简化的类图或说明参与角色

五、分布式系统核心 (高频考点)

CAP 定理

选择含义典型产品
CP (一致性+分区容错) 牺牲可用性,保证强一致性 ZooKeeper、etcd、HBase
AP (可用性+分区容错) 牺牲强一致性,保证高可用 Cassandra、Eureka、DynamoDB
CA (一致性+可用性) 无法容忍网络分区(不现实) 传统关系型数据库(单机)

BASE 理论

BA (Basically Available - 基本可用) + S (Soft State - 软状态) + E (Eventually Consistent - 最终一致性)

分布式事务方案

方案原理优点缺点
2PC 协调者+参与者,两阶段提交 强一致性 同步阻塞、单点故障、数据不一致风险
TCC Try-Confirm-Cancel 业务层控制、性能好 代码侵入大、需实现补偿
Saga 长事务拆为多个本地事务+补偿 高可用、适合长事务 需实现补偿逻辑
本地消息表 本地事务+消息表保证最终一致 实现简单 消息表和业务表耦合

服务治理关键组件

组件功能典型技术
服务注册与发现服务实例动态注册,客户端动态发现Nacos、Consul、Etcd、Eureka
负载均衡请求分发到多实例Ribbon、Nginx、Spring Cloud LoadBalancer
熔断器故障服务快速失败,防止级联故障Sentinel、Hystrix、Resilience4j
API网关统一入口、认证、限流、路由Spring Cloud Gateway、Kong、Zuul
配置中心配置统一管理、动态刷新Nacos、Apollo、Spring Cloud Config
链路追踪请求跨服务追踪SkyWalking、Jaeger、Zipkin

六、数据库架构设计 (常考)

分库分表策略

维度策略说明
水平拆分 Range 分片按范围分片(如按时间、ID范围)。易实现,但可能热点不均
Hash 分片按哈希值分片。数据均匀分布,但扩容迁移困难
目录分片通过路由表查找。灵活,但需维护路由表
垂直拆分按业务将不同业务的表分到不同库。如:用户库、订单库、商品库

SQL vs NoSQL 选择

数据库类型特点适用场景典型产品
关系型(SQL)ACID、强Schema、Join查询金融、ERP、复杂关联查询MySQL、PostgreSQL
键值存储高性能KV读写缓存、Session、购物车Redis、Memcached
文档数据库Schema灵活、JSON文档内容管理、商品目录MongoDB、CouchDB
列族数据库列存储、高压缩比日志分析、时序数据HBase、Cassandra
图数据库节点+关系模型社交网络、推荐系统、知识图谱Neo4j、JanusGraph
搜索引擎全文检索、倒排索引搜索服务、日志分析Elasticsearch、Solr

缓存策略

策略说明适用场景
Cache Aside读:先查缓存,miss则查DB并写回缓存。写:更新DB后删缓存读多写少(最常用)
Read Through缓存层代理读DB。缓存miss时缓存组件自动加载缓存逻辑集中管理
Write Through写入时同步写缓存+DB数据一致性要求高
Write Behind写入时只写缓存,异步批量写DB写入频率高、允许短暂不一致
高频考点: 缓存穿透(布隆过滤器、空值缓存)、缓存击穿(互斥锁、永不过期+异步更新)、缓存雪崩(随机TTL、多级缓存、限流)。这"三缓"必背!

七、安全架构设计

认证 vs 授权

概念说明技术方案
认证验证"你是谁"用户名密码、短信验证、OAuth2.0、OIDC、SAML、生物识别
授权确定"你能做什么"RBAC(角色)、ABAC(属性)、ACL(访问控制列表)

OAuth 2.0 四种授权模式

模式适用场景关键参数
授权码模式有后端的Web应用(最安全)code → access_token (推荐)
密码模式高度信任的应用直接传用户名密码获取token
客户端凭证服务间通信client_id + client_secret
隐式模式纯前端SPA(已不推荐)直接返回token(有安全风险)

常见安全攻击及防御

攻击原理防御
SQL注入恶意SQL拼接参数化查询/预编译、ORM、输入校验
XSS注入恶意脚本输出编码、CSP、HttpOnly Cookie
CSRF伪造用户请求CSRF Token、SameSite Cookie、Referer校验
DDoS大量请求耗尽资源CDN、WAF、限流、黑名单、流量清洗
中间人攻击窃听/篡改通信HTTPS/TLS、证书校验、HSTS

八、案例分析答题通用模板

典型问题: "请分析该系统的架构风格,并说明理由"

答题步骤:

  1. 明确指出风格: 该系统采用了[XX架构风格]
  2. 结合题干描述: 从题目描述中找出2-3个关键特征作为证据
  3. 分析优势: 该风格为系统带来的好处(至少2点)
  4. 指出潜在问题: (可选)该风格可能带来的挑战

典型问题: "分析该系统需要关注哪些质量属性,并给出实现方案"

答题步骤:

  1. 列举关键质量属性: 从题目中提取(通常3-4个)
  2. 每个属性写场景: [条件]下,[刺激],系统[响应],[度量标准]
  3. 给出实现方案: 每个质量属性的具体实现策略
  4. 指出权衡: 不同质量属性之间可能的冲突及优先级

典型问题: "对比[技术A]和[技术B]的优缺点,并给出选择建议"

答题步骤:

  1. 列表对比: 从功能、性能、可用性、复杂度、生态等维度对比
  2. 结合业务: 结合题目中的具体场景分析
  3. 给出建议: 明确推荐哪个方案以及理由

典型问题: "请设计XX模块的架构方案"

答题步骤:

  1. 设计原则: 先阐述遵循的设计原则(开闭、单一职责等)
  2. 架构图/描述: 描述组件划分及关系
  3. 关键技术选型: 列出关键技术及选型理由
  4. 质量属性保障: 说明方案如何满足关键质量属性