| 缩写 | 全称 | 中文 | 一句话解释 |
|---|---|---|---|
| ATAM | Architecture Tradeoff Analysis Method | 架构权衡分析方法 | 评估架构方案、识别权衡点的方法 |
| SAAM | Scenario-based Architecture Analysis Method | 基于场景的架构分析方法 | 通过场景评估架构满足质量属性程度 |
| ADD | Attribute-Driven Design | 属性驱动设计 | 以质量属性驱动架构设计的方法 |
| CAP | Consistency / Availability / Partition tolerance | CAP定理 | 分布式系统最多同时满足三者之二 |
| BASE | Basically Available, Soft state, Eventually consistent | BASE理论 | AP系统的理论基础 |
| ACID | Atomicity / Consistency / Isolation / Durability | 事务四大特性 | 关系数据库事务保证 |
| DDD | Domain-Driven Design | 领域驱动设计 | 以业务领域为核心的软件设计方法 |
| CQRS | Command Query Responsibility Segregation | 命令查询职责分离 | 读写分离的架构模式 |
| SOA | Service-Oriented Architecture | 面向服务架构 | 企业级服务化的架构风格 |
| ESB | Enterprise Service Bus | 企业服务总线 | SOA中的消息路由中介 |
| RBAC | Role-Based Access Control | 基于角色的访问控制 | 按角色授权管理权限 |
| OAuth | Open Authorization | 开放授权协议 | 第三方授权标准协议 |
| TLS | Transport Layer Security | 传输层安全 | 网络通信加密协议(前身SSL) |
| CI/CD | Continuous Integration / Continuous Deployment | 持续集成/持续部署 | 自动化构建、测试、部署的DevOps实践 |
| 2PC | Two-Phase Commit | 两阶段提交 | 分布式事务的强一致性协议 |
| TCC | Try-Confirm-Cancel | TCC事务 | 补偿型分布式事务方案 |
| API | Application Programming Interface | 应用程序接口 | 系统间通信的协议约定 |
| SLA | Service Level Agreement | 服务等级协议 | 服务质量的量化承诺(如99.9%) |
| 场景 | 推荐的架构风格 | 简短理由 |
|---|---|---|
| 数据处理流水线 | 管道-过滤器 | 数据经过多个独立处理步骤 |
| 规则评估、专家系统 | 黑板风格 | 不确定性问题,多知识源协作 |
| 大型Web应用 | 分层架构 | 关注点分离,各层独立演进 |
| 高并发、需求多变 | 微服务 | 独立部署、独立扩展、技术异构 |
| 异步解耦、实时推送 | 事件驱动 | 发布/订阅,组件松耦合 |
| 企业级系统集成 | SOA/ESB | 异构系统互操作、统一路由 |
| 数据共享平台 | 仓库风格 | 中央数据源+独立处理组件 |
| GUI应用 | 事件驱动/MVC | 用户交互事件响应 |
定义: 系统在给定时间内完成请求响应的能力
指标: 响应时间、吞吐量、并发数、资源利用率
战术: 引入缓存、增加计算资源、减少等待时间(异步)、优化算法、减少通信开销、资源池化
关键组件: CDN(静态加速)、Redis(热点缓存)、消息队列(削峰填谷)、数据库索引、连接池
定义: 系统正常运行、可提供服务的时间比例
指标: 正常运行时间百分比 (99.9%=年宕机8.76h, 99.99%=年宕机52.6min)
战术: 故障检测(心跳/Ping)、故障恢复(重试/切换/回滚)、故障预防(冗余/事务/主动预警)
关键组件: 主从切换(Sentinel/Keepalived)、负载均衡、熔断降级、多活容灾、限流
定义: 保护信息不受非授权访问、使用、泄露、篡改或销毁
CIA三要素: 保密性(Confidentiality)、完整性(Integrity)、可用性(Availability)
战术: 抵抗攻击(加密/认证/授权)、检测攻击(入侵检测/审计)、恢复(备份/冗余)
关键组件: HTTPS/TLS、OAuth2.0/JWT、WAF、RBAC、SQL参数化查询、CSRF Token
定义: 系统接受变更的容易程度
指标: 修改成本、修改范围(影响模块数)、修改时间
战术: 模块化/封装、接口抽象、配置外部化、依赖注入、设计模式
关键模式: 策略模式(算法可换)、适配器模式(接口兼容)、开闭原则(对扩展开放,对修改关闭)
定义: 发现系统缺陷的难易程度
战术: 接口隔离、依赖注入(方便Mock)、日志/监控暴露内部状态、健康检查端点
定义: 用户使用系统的容易程度
战术: 用户建模(支持用户认知模型)、系统主动提供反馈(进度条/提示)、统一交互规范
| 模型 | 说明 | 实现难度 |
|---|---|---|
| 强一致性 | 写入后所有读都能看到最新值 | 高 (Paxos/Raft) |
| 最终一致性 | 写入后经过一段时间所有读能看到最新值 | 低 (异步复制) |
| 因果一致性 | 有因果关系的操作按序可见 | 中 |
| 读写一致性 | 自己写的自己能立即读到 | 低 (主库读) |
| 算法 | 理解难度 | 典型实现 | 特点 |
|---|---|---|---|
| Paxos | 难 | Chubby | 理论完备,实现复杂 |
| Raft | 中 | etcd、Consul | 易懂,工程化好。Leader选举+日志复制 |
| ZAB | 中 | ZooKeeper | 原子广播协议,强一致性 |
| 问题 | 现象 | 解决方案 |
|---|---|---|
| 缓存穿透 | 查询不存在的数据,每次都穿透到DB | ①布隆过滤器 ②空值缓存(设短TTL) |
| 缓存击穿 | 热点key过期瞬间,大量请求打到DB | ①互斥锁/分布式锁 ②永不过期+异步更新 ③逻辑过期 |
| 缓存雪崩 | 大量key同时过期,DB瞬间压力过大 | ①TTL加随机值 ②多级缓存 ③限流熔断 ④集群高可用 |
| 模式 | 口诀 | 一句话 |
|---|---|---|
| 策略模式 | 算法族,可替换 | 定义一系列算法,运行时选择使用哪个 |
| 观察者 | 一对多,自动通知 | 被观察者变化时,观察者自动收到通知 |
| 工厂方法 | 创建延后到子类 | 让子类决定实例化哪个对象 |
| 适配器 | 接口不配,包装兼容 | 把不兼容的接口转换成兼容的接口 |
| 装饰器 | 功能增强,不改变原类 | 动态添加职责,比继承更灵活 |
| 代理 | 控制访问,代表它人 | 为目标对象提供代理,控制对它的访问 |
| 模板方法 | 骨架固定,步骤可变 | 定义算法骨架,子类填充具体步骤 |
| 责任链 | 依次处理,直到有人管 | 请求沿链传递,直到某个处理器处理它 |
| 单例 | 全局唯一,只一个实例 | 确保类只有一个实例,并提供全局访问点 |
| 门面 | 简化接口,统一入口 | 提供统一接口,隐藏子系统复杂性 |
| 视图 | 关注点 | 受众 | 表示 |
|---|---|---|---|
| 逻辑视图 | 功能需求 - 系统提供给用户的功能 | 用户、分析师 | 类图、对象图 |
| 进程视图 | 非功能 - 并发、性能、可扩展性 | 系统集成者 | 活动图、时序图 |
| 开发视图 | 模块组织 - 从程序员视角 | 开发人员 | 组件图、包图 |
| 物理视图 | 拓扑、通信 - 部署到物理节点 | 运维人员 | 部署图 |
| +1 场景视图 | 用例 - 串联其他4个视图 | 所有干系人 | 用例图 |
| 概念 | 数据 |
|---|---|
| 案例分析题数/选做 | 5道大题,任选3道 |
| 案例分析时间 | 90分钟,每题约30分钟 |
| 论文写作时间 | 120分钟 |
| 论文字数要求 | 2000-2500字(摘要300-400) |
| 合格分数线 | 三科都 ≥ 45分(满分75) |
| 99.9%可用性 | 年宕机约8.76小时 |
| 99.99%可用性 | 年宕机约52.6分钟 |
| 99.999%(5个9) | 年宕机约5.26分钟 |
| 2PC参与者数 | ≥2 (协调者+参与者) |
| 缓存常见TTL | 热点数据5-30分钟,静态数据1-24小时 |