系统架构设计师 · 论文备考手册

微服务的核心优势

• 技术异构性 — 每个服务可选择最适合自身的技术栈，便于尝试新技术 (技术选型自由)
• 弹性 — 单个服务故障不影响整体，内置可用性方案与功能降级 (故障隔离)
• 可扩展性 — 针对单个服务独立扩展，而非整体扩展 (按需扩容)
• 简化部署 — 服务独立部署，修改一行代码不需重新部署整个系统 (降低部署风险)
• 与组织结构匹配 — 康威定律的应用，团队规模与服务粒度匹配 (两个披萨团队)
• 可组合性 — 开放接口，可用不同方式构建应用 (API 复用)
• 对可替代性的优化 — 可轻易重写或删除不再使用的服务 (降低改造成本)

常见微服务设计模式

微服务面临的挑战

• 分布式系统复杂度 — 服务间通过网络通信，性能、可靠性、数据一致性都受影响
• 运维成本激增 — 服务数量增多导致部署、配置、监控、日志收集成本呈指数级增长
• 部署自动化要求高 — 必须建立 CI/CD 流水线，依赖容器与编排工具
• DevOps 与组织结构变革 — 全功能团队、开发承担运维责任
• 服务依赖测试与管理 — 服务数量多时，接口契约测试、依赖关系展示成挑战
• 数据一致性难题 — 受 CAP 约束，从强一致性转向最终一致性

微服务 vs SOA 的本质差异

DDD 战略设计

• 限界上下文（Bounded Context） — 明确模型适用的边界，每个上下文有独立的领域模型，常对应一个微服务
• 统一语言（Ubiquitous Language） — 业务专家、设计人员、开发人员共用一套术语，消除沟通歧义
• 上下文映射（Context Mapping） — 描述限界上下文之间的关系：共享内核、客户/供应商、防腐层、开放主机服务等
• 子域划分 — 核心域（业务竞争力所在）、支撑子域、通用子域

DDD 战术设计

DDD 分层架构

• 用户接口层 — 展示信息、解析用户命令，对应 UI/API 控制器
• 应用层 — 协调任务、委派工作给领域对象，不含业务规则
• 领域层 — 业务的核心，包含领域模型与领域逻辑
• 基础设施层 — 为上层提供通用技术能力（持久化、消息、第三方集成）

核心架构组成

• 数据平面（Data Plane） — 由一组以 Sidecar 形式部署的智能代理组成，处理服务间的所有网络通信
• 控制平面（Control Plane） — 管理和配置代理来路由流量，负责策略和遥测数据收集
• Sidecar 模式 — 应用容器与代理容器部署在同一 Pod 中，应用无感知
• 典型实现 — Istio + Envoy、Linkerd、Consul Connect 等

提供的核心能力

解决了微服务的什么痛点

• 把服务治理逻辑从业务代码中剥离，业务代码只关注业务
• 跨语言的服务治理一致性（不再需要每种语言都写一套 SDK）
• 治理策略可动态调整，无需修改代码或重启服务
• 运维与开发关注点分离

中台的分类

• 业务中台 — 将企业核心业务能力（用户、订单、商品、营销、支付等）下沉，为前台多业务线提供统一服务
• 数据中台 — 打通各业务系统数据孤岛，统一采集、清洗、建模、服务，提供数据资产复用
• 技术中台 — 沉淀公共技术能力（消息、缓存、注册中心、网关、监控）
• AI 中台 — 统一管理算法模型、训练资源、推理服务
• 组织中台 — 配套中台架构的组织调整与人才复用

中台架构的关键设计要点

• 能力抽象 — 从多个业务中提炼共性能力，避免过早抽象与过度抽象
• 服务化封装 — 通过 API 网关对外暴露能力，明确契约
• 数据资产化 — 建立统一指标体系、主数据管理、标签体系
• 赋能前台 — 提供低代码/无代码工具、配置化能力，加快前台业务搭建
• 组织保障 — 中台团队的考核机制需与前台业务成功度挂钩

为什么要演化

• 单体的瓶颈 — 代码库过大难维护、部署风险高、技术栈固化、团队协作困难
• 业务增长 — 用户量、数据量、功能复杂度都超过单体可承载范围
• 团队扩张 — 大团队在单体上协作效率下降
• 技术升级 — 需要拥抱云原生、容器化、新型数据库等

演化的典型路径

• 第一阶段：单体应用 — 所有功能在一个进程内，简单高效
• 第二阶段：模块化单体 — 单体内部按业务划分模块，但仍是同一进程
• 第三阶段：垂直拆分 — 按业务线拆分为多个独立单体（每个仍是单体）
• 第四阶段：SOA / 服务化 — 抽象公共服务，引入服务总线
• 第五阶段：微服务 — 细粒度拆分，独立部署、独立数据库
• 第六阶段：云原生 / 服务网格 — 容器化、Service Mesh、Serverless

关键演化策略

• 绞杀者模式（Strangler Fig） — 在单体外围逐步建立新服务，逐步"绞杀"老系统
• 分支抽象（Branch by Abstraction） — 在代码中引入抽象层，逐步替换实现
• 事件拦截器 — 通过消息事件解耦新旧系统
• 数据库拆分 — 共享数据库 → 视图隔离 → 数据库逐步迁移
• API 网关引入 — 在前端隔离老系统，便于后端逐步替换
• 防腐层 — 在新旧系统之间建立翻译层，防止老系统的概念污染新系统

演化中的关键挑战

三代数据架构演进

• 第一代：数据仓库（Data Warehouse） — 结构化数据为主，Schema-on-Write，强一致性，但难处理半结构化/非结构化数据，扩展成本高
• 第二代：数据湖（Data Lake） — 任意格式存储，Schema-on-Read，灵活但易成"数据沼泽"，缺乏数据质量与事务保障
• 第三代：湖仓一体（Lakehouse） — 在数据湖之上引入表格式（如 Delta Lake、Iceberg、Hudi），提供 ACID、时间旅行、Schema 演化等仓库能力

湖仓一体的核心特征

• 事务支持（ACID） — 解决湖中并发读写一致性问题
• Schema 强制与演化 — 既保数据质量又允许灵活变更
• BI 直查能力 — 直接在数据湖上跑 SQL 分析，无需 ETL 到仓库
• 开放格式 — Parquet / ORC 等开放格式，避免厂商锁定
• 计算存储分离 — 计算引擎与存储独立扩展
• 支持多样化工作负载 — BI、流处理、ML、SQL 都在一份数据上运行

关键技术组件

CAP 理论与权衡

• 一致性（Consistency） — 所有节点同一时刻看到相同数据
• 可用性（Availability） — 每个请求都能在合理时间内得到响应
• 分区容忍性（Partition Tolerance） — 网络分区时系统仍能继续运作
• 权衡定律 — 三者不可兼得，分布式系统必选 P，在 C 和 A 之间取舍
• BASE 理论 — 基本可用（Basically Available）、软状态（Soft State）、最终一致性（Eventual Consistency），是对 ACID 的弱化

数据分片策略

数据复制与一致性协议

• 主从复制 — 一主多从，读写分离，主挂时需故障切换
• 多主复制 — 多个主节点都可写，需冲突解决
• Paxos / Raft — 强一致性共识算法，多数派提交
• Gossip 协议 — 去中心化的最终一致性传播
• Quorum 机制 — N/W/R 配置，W+R>N 保证读最新数据

分布式事务方案

• 2PC（两阶段提交） — 准备阶段 + 提交阶段，强一致但阻塞、协调者单点
• 3PC — 三阶段提交，引入超时机制缓解阻塞
• TCC（Try-Confirm-Cancel） — 业务层补偿，灵活但实现复杂
• Saga 模式 — 长事务拆为多个本地事务 + 补偿动作
• 基于消息的最终一致性 — 借助可靠消息队列实现

为什么需要向量数据库

• 非结构化数据的语义检索 — 文本、图像、音频通过 Embedding 转为向量后才能做语义匹配
• 大模型上下文窗口有限 — 通过外部向量检索补充知识，突破上下文长度限制
• 传统数据库不支持高维相似度检索 — B+ 树、哈希索引在高维空间失效（维度灾难）
• 实时性要求 — 毫秒级返回 Top-K 最相似结果

关键技术：近似最近邻（ANN）算法

向量距离度量

• 欧氏距离（L2） — 几何距离，适合大小敏感场景
• 余弦相似度 — 夹角余弦，适合方向比大小重要的场景（文本最常用）
• 内积（IP） — 不归一化的相似度，推荐系统常用
• 汉明距离 — 比特位差异，二值向量用

向量数据库的架构特点

• 存储引擎 — 列式存储 + 内存索引，向量大块存盘，索引常驻内存
• 混合检索 — 向量检索 + 标量过滤（如时间、类别）结合
• 水平扩展 — 向量分片、副本，支持亿级向量
• 动态索引 — 支持实时插入与索引更新
• 典型实现 — Milvus、Pinecone、Weaviate、Qdrant、Chroma、PG-Vector

Lambda 架构

• 批处理层（Batch Layer） — 处理全量历史数据，生成批视图，准确但延迟高（Hadoop / Spark）
• 速度层（Speed Layer） — 实时处理新数据，生成实时视图，低延迟但近似（Storm / Spark Streaming / Flink）
• 服务层（Serving Layer） — 合并批视图与实时视图，对外提供查询
• 优势 — 强容错性、准确性高、能处理超大规模历史数据
• 劣势 — 两套代码维护、运维复杂、开发成本高

Kappa 架构

• 核心思想 — 用流处理统一处理一切，全量计算通过"回放"消息队列实现
• 关键组件 — 消息中间件（Kafka）+ 流处理引擎（Flink）
• 全量计算流程 — 启动新的流任务，从消息队列头部重新消费，超过原结果后切换
• 优势 — 一套代码、维护简单、概念清晰
• 劣势 — 历史数据处理能力受限于消息队列性能，超大规模历史数据吃力

选型决策因素

数据治理框架（DAMA-DMBOK）

• 数据治理 — 核心，统领其他职能
• 数据架构管理 — 数据模型、数据流
• 数据开发 — 数据库设计、实现
• 数据操作管理 — 数据库运维、性能
• 数据安全管理 — 访问控制、隐私保护
• 主数据与参考数据管理
• 数据仓库与商业智能管理
• 文档与内容管理
• 元数据管理
• 数据质量管理

数据质量的六个维度

主数据管理的关键能力

• 数据建模 — 定义主数据实体、属性、关系
• 数据集成 — 从多源系统采集主数据
• 数据清洗与匹配 — 去重、合并、纠错
• 数据分发 — 推送到下游业务系统
• 数据治理流程 — 数据所有权、变更审批
• 数据服务 — API 方式提供主数据查询

可用性战术 · 错误检测

• 命令/响应 — 构件发出命令，期望预定时间内收到审查构件的响应，用于检测远程错误
• 心跳（计时器） — 构件定期发心跳消息，监听方未收到则判定故障
• 异常 — 出现异常时由异常处理程序处理

可用性战术 · 错误恢复

• 表决 — 冗余构件并行计算，表决器按多数规则决定结果（常见于控制系统）
• 主动冗余（热备份） — 所有冗余构件并行响应，仅用一个结果，错误时切换
• 被动冗余（暖备份） — 主构件响应，定期同步状态给备用构件，主故障时备用接管
• 备件 — 备用计算平台，需要时启动替换故障构件
• 状态再同步 — 恢复的构件提供服务前必须更新状态
• 检查点/回滚 — 定期记录一致状态，故障时回滚到最近检查点

可用性战术 · 错误预防

• 从服务中删除 — 如定期删除并重启进程防止内存泄漏
• 事务 — 保证多步操作的原子性
• 进程监视器 — 监视进程并处理错误

典型高可用方案

高可用设计原则

• 消除单点 — 任何组件都要有冗余
• 故障隔离 — 舱壁模式、限制故障传播
• 服务降级 — 非核心功能可暂时停用以保证核心
• 熔断与限流 — 防止故障雪崩
• 幂等性 — 重试不产生副作用
• 无状态化 — 便于横向扩展和故障切换

信息安全的核心属性（CIA）

• 机密性（Confidentiality） — 防止数据资源未授权披露
• 完整性（Integrity） — 防止数据资源未授权修改
• 可用性（Availability） — 防止系统数据和资源丢失
• 扩展属性 — 真实性、不可抵赖性、可控性、可审查性

常见安全威胁

安全架构设计的关键技术

• 身份鉴别 — 密码、生物特征、多因素认证、单点登录（SSO）
• 访问控制 — DAC（自主访问控制）、MAC（强制访问控制）、RBAC（基于角色）、ABAC（基于属性）
• 内容安全 — 数据脱敏、内容过滤、DLP（数据防泄漏）
• 冗余恢复 — 数据备份、灾难恢复、业务连续性
• 审计响应 — 日志记录、安全事件响应、SIEM
• 恶意代码防范 — 病毒查杀、入侵检测、入侵防御
• 密码技术 — 对称加密（DES/AES）、非对称加密（RSA/ECC）、哈希、数字签名、PKI

等级保护与风险评估

• 等保 1.0 / 2.0 — 五个等级：用户自主保护、系统审计保护、安全标记保护、结构化保护、访问验证保护
• 风险评估三要素 — 资产（价值）、威胁（可能性）、脆弱性（暴露）
• 评估流程 — 范围确定 → 资产识别 → 威胁识别 → 脆弱性识别 → 风险计算 → 处置建议
• 残余风险 — 实施安全措施后仍存在的风险，需持续监视

零信任架构（新趋势）

• 核心原则 — 默认不信任任何用户、设备、网络（"Never trust, always verify"）
• 持续验证 — 每次访问都需重新认证授权
• 最小权限 — 仅授予必需的权限，按需供给
• 微隔离 — 网络细粒度分段，限制横向移动

架构评估的三大关键要素

• 敏感点（Sensitivity Point） — 为达成某种质量属性所需的关键决策（特定组件/属性）
• 权衡点（Tradeoff Point） — 影响多个质量属性的关键属性，是同时影响多个敏感点的属性
• 风险承担者（Stakeholders） — 架构相关的所有人：架构师、开发、维护、测试、运维、客户、最终用户等
• 场景（Scenarios） — 由刺激（Stimulus）、环境（Environment）、响应（Response）三部分描述

SAAM 方法

• 全称 — Scenarios-based Architecture Analysis Method，基于场景的架构分析方法
• 提出 — 卡耐基梅隆大学 SEI 的 Kazman 等人，最早形成文档的架构分析方法
• 主要目标 — 评估可修改性，也可用于可移植性、可扩充性等
• 五个步骤 — 场景开发 → 架构描述 → 单个场景评估 → 场景交互评估 → 总体评估
• 特点 — 简单实用，可对比多个不同架构

ATAM 方法

• 全称 — Architecture Tradeoff Analysis Method，架构权衡分析方法
• 核心 — 在 SAAM 基础上发展而来，重点是识别多个质量属性之间的权衡
• 九个步骤 — 描述方法 → 描述商业动机 → 描述架构 → 识别架构方法 → 生成质量属性效用树 → 分析架构方法 → 头脑风暴场景 → 再分析 → 呈现结果
• 输出 — 风险（影响目标的决策）、敏感点、权衡点、非风险（已论证合理的决策）

CBAM 方法

• 全称 — Cost-Benefit Analysis Method，成本效益分析方法
• 定位 — 在 ATAM 之上加入经济维度，评估架构决策的成本与收益
• 用途 — 帮助决策者在多种架构方案中选择性价比最高的

两种扩展方式

可扩展性的核心设计原则

• 无状态设计 — 服务层不保存状态，状态外移到缓存/数据库
• 负载均衡 — DNS、四层（LVS）、七层（Nginx）、客户端均衡
• 数据分片 — 数据库按 Key 分片、读写分离、分库分表
• 缓存层次 — 浏览器缓存、CDN、网关缓存、应用缓存、数据库缓存
• 异步化 — 通过消息队列削峰填谷、解耦组件
• 资源池化 — 连接池、线程池、对象池
• 弹性伸缩 — 基于负载指标自动扩缩容（K8s HPA、云平台自动伸缩组）

负载均衡算法

关键指标

• RPO（Recovery Point Objective） — 恢复点目标，可接受的最大数据丢失量（以时间衡量）
• RTO（Recovery Time Objective） — 恢复时间目标，从灾难发生到业务恢复的最大可接受时间
• RCO（Recovery Cost Objective） — 恢复成本目标
• NRO（Network Recovery Objective） — 网络恢复目标

容灾级别（国标 GB/T 20988）

• 第 1 级 · 基本支持 — 异地数据备份介质
• 第 2 级 · 备用场地支持 — 灾难时临时调用备用场地
• 第 3 级 · 电子传输和部分设备支持
• 第 4 级 · 电子传输及完整设备支持
• 第 5 级 · 实时数据传输及完整设备支持
• 第 6 级 · 数据零丢失和远程集群支持 — 异地双活，RPO ≈ 0

备份策略

异地多活架构

• 同城双活 — 同城两数据中心同时对外，主备切换快
• 两地三中心 — 生产中心 + 同城灾备 + 异地灾备
• 异地多活 — 多地数据中心同时承担业务流量，靠近用户访问
• 单元化 — 将业务按用户维度划分单元，单元内闭环，减少跨地域调用

大模型应用的三种模式

• Prompt Engineering — 通过精心设计的提示词驱动大模型，成本最低、最灵活
• RAG（检索增强生成） — 外部知识库 + 大模型，解决知识时效性与领域专业性
• 微调（Fine-tuning） — 在基础模型上用领域数据训练，成本高但效果定制化
• 组合应用 — Prompt + RAG + Fine-tuning 三者结合是主流方案

典型大模型应用架构层次

• 基础设施层 — GPU 集群、模型推理引擎（vLLM、TGI、Triton）、模型服务（MaaS）
• 模型层 — 基础大模型 + 领域微调模型 + Embedding 模型 + Reranker 模型
• 能力层 — Prompt 工程、RAG 检索、Agent 编排、工具调用、Function Calling
• 应用层 — 智能客服、文档助手、代码助手、企业知识库、业务流程自动化
• 治理层 — 模型评估、内容安全、成本管控、审计日志

关键架构挑战

AI Agent 智能体架构

• 大脑 — 大模型作为推理决策核心
• 记忆 — 短期记忆（对话上下文）+ 长期记忆（向量数据库）
• 规划 — 任务分解、ReAct、CoT、ToT 等推理范式
• 工具 — Function Calling 调用外部 API、代码执行、数据库查询
• 反思 — 自我评估与修正
• 多 Agent 协作 — 角色分工、辩论、群体智能

RAG 的核心流程

• 离线 · 知识库构建 — 文档采集 → 解析 → 分块（Chunking） → Embedding → 入向量库
• 在线 · 检索 — 用户问题向量化 → 向量库 ANN 检索 Top-K → 重排（Rerank）
• 在线 · 生成 — 检索结果 + 问题 + 系统 Prompt 一同输入大模型 → 生成答案
• 反馈闭环 — 用户反馈用于优化分块策略、检索策略、Prompt

关键技术点

• 文档解析 — PDF / Word / 表格 / 图片 OCR，保留结构信息
• 分块策略 — 固定大小 / 按段落 / 按语义 / 重叠窗口 / 父子分块
• Embedding 模型 — BGE、M3E、OpenAI Embedding、bce-embedding 等
• 混合检索 — 向量检索（语义）+ 关键词检索（BM25）取长补短
• 重排（Reranker） — Cross-Encoder 精排，提高 Top-K 准确性
• 查询改写 — HyDE、Multi-Query、Step-Back 等改写技巧
• 引用溯源 — 答案中标注来源，可信可查

高级 RAG 架构

RAG 评估维度

• 检索质量 — 召回率（Recall）、精确率（Precision）、MRR
• 生成质量 — 答案相关性、事实准确性、流畅度
• 系统指标 — 端到端延迟、Token 消耗、可用性
• 评估框架 — RAGAS、TruLens、LangSmith

边缘计算的核心价值

• 低延迟 — 数据本地处理，避免回传云端的网络延迟
• 带宽节省 — 大量原始数据本地处理，仅上传摘要
• 隐私保护 — 敏感数据不出本地
• 可靠性 — 网络断开时仍能本地工作
• 合规要求 — 数据主权与本地化要求

云边端协同架构

• 端（Device） — 传感器、设备，采集数据，初步处理
• 边（Edge） — 边缘节点、边缘网关，区域汇聚与实时处理
• 云（Cloud） — 中心云，全局训练、模型下发、统一管理
• 协同模式 — 数据协同、模型协同、应用协同

典型应用场景

数字孪生的三项核心技术

• 建模 — 将物理实体数字化、模型化，是创建数字孪生体的源头
• 仿真 — 让模型动起来，验证物理实体在不同场景下的行为
• 基于数据融合的数字线程（Digital Thread） — 贯穿全生命周期的数据流

支撑技术体系

数字孪生的应用层次

• 数字孪生原型体 — 设计阶段的虚拟产品模型
• 数字孪生实例体 — 每个物理实例对应的运行时孪生
• 数字孪生聚合体 — 多个实例聚合分析、群体优化
• 典型应用 — 智能制造、智慧城市、数字电网、数字孪生流域

DevOps 的三大支柱（CALMS）

• Culture · 文化 — 协作、责任共担、容错文化
• Automation · 自动化 — 代码、构建、测试、部署、监控全链路自动化
• Lean · 精益 — 小批量、快速反馈、持续改进
• Measurement · 度量 — 数据驱动的决策与改进
• Sharing · 分享 — 知识共享、跨团队透明

CI/CD 流水线

• 持续集成（CI） — 开发者频繁合并代码到主干，自动构建与测试
• 持续交付（CD - Delivery） — 构建产物随时可部署到生产，手动触发
• 持续部署（CD - Deployment） — 通过测试的构建自动部署到生产
• 典型流程 — 代码提交 → 静态扫描 → 单元测试 → 构建镜像 → 集成测试 → 安全扫描 → 部署预发 → 自动化测试 → 部署生产

关键技术与工具链

部署策略

• 蓝绿部署 — 双套环境切换流量，回滚快
• 金丝雀发布 — 小流量先行验证，逐步放量
• 滚动更新 — 逐批替换实例，平滑过渡
• 灰度发布 — 按用户特征定向发布
• A/B 测试 — 多版本并行验证