第一章 信息系统架构
一、本章考情与知识地图
1.1 本章题量与分值估计
本章是"金融监管计算机类"专业科目中最稳定、最好拿分的一章。它不考推导、不考代码，考的是"你认不认识这个架构、这个中间件、这个指标"。近八年真题中，本章每年稳定出 10---14 题，单选、多选各占一部分，折合 10---14 分，约占计算机专业知识的八分之一。
以下为按回忆版逐题归类的估算，仅用于把握比重，非官方统计。
| 年份 | 题量（单选+多选，估计） | 分值估计 | 高频落点（归纳） |
|---|---|---|---|
| 2018 | 11 | 11 分 | 架构风格识别、C/S 与 B/S、中间件、容灾 |
| 2019 | 12 | 12 分 | 4+1 视图、负载均衡、虚拟化、两地三中心 |
| 2020 | 13 | 13 分 | 微服务、容器、MVC、B/S 访问顺序、负载均衡 |
| 2021 | 14 | 14 分 | 架构风格（规则系统）、中间件、信息系统架构四层、性能需求 |
| 2022 | 10 | 10 分 | 应用架构规划、MVC、消息中间件 |
| 2023 | 12 | 12 分 | 双活数据中心、IT 治理、DevOps、云服务层次 |
| 2024 | 11 | 11 分 | 容器与 Kubernetes、中间件、可用性指标 |
| 2025 | 13 | 13 分 | 双机双工、ODBC/JDBC、缓冲队列、高可用 |
【注意】上表为依据 2018---2025 年真题回忆版与考生反馈作出的估计，题量、分值按每题 1 分折算，实际以官方答案为准；"高频落点"是该年命题方向的归纳，不是逐题清单。
1.2 命题规律
规律一：分类识别题占七成。 典型问法是"下列属于哪种架构风格""该系统最适合采用哪种架构""下列哪项属于 IaaS"。题干往往给一个银行场景（VIP 会员规则调整、核心系统下移、柜面终端打印），要求把场景映射到教材分类。
规律二：多选题专挑并列项。 信息系统架构的四个层次、系统性能需求包含哪些、中间件的作用、DevOps 相关技术、灾备关键指标，这类"包括/分为几类"的考点几乎每年出一道多选，答错一项即 0 分，所以本讲义所有并列项都编号列全。
规律三：数值题集中在可用性与灾备。 可用性百分比换算年停机时间、灾备能力 1---6 级、RTO/RPO、两地三中心构成，属于"背了就会、不背就猜"的送分题。
规律四：银行实务背景强。 核心系统分布式改造、主机下移、两地三中心、同城双活、单元化、信创、云合规、外包风险，这些监管语境反复出现，题干常以"某商业银行"开头。
规律五：新技术只考概念级。 容器与虚拟机的区别、Kubernetes 各对象的作用、Serverless 的特点，考的是"是什么、解决什么问题"，不考版本号、不考命令、不考参数配置。
1.3 本章知识地图
- 第一板块：信息系统与架构基础
· 信息系统的五个组成部分、五种典型类型（TPS/MIS/DSS/ES/OA）
· 软件架构的定义（构件 + 连接件 + 约束）与作用
· 架构描述方法：4+1 视图、TOGAF ADM、Zachman 框架
· 六大质量属性与设计策略 - 第二板块：架构风格与分层
· 五大类架构风格（数据流、调用返回、独立构件、虚拟机、仓库）
· 分层架构、三层/多层架构、MVC 与 MVP/MVVM
· C/S 与 B/S 的对比与选型 - 第三板块：企业架构与 IT 规划
· 企业架构四层（业务、应用、数据、技术）
· IT 战略规划、IT 治理、ITIL
· SOA 三要素与微服务对比、微服务组件与治理
· 中台、API 网关、前后端分离 - 第四板块：中间件与应用支撑
· 中间件分类（数据库访问、RPC、消息、事务、应用服务器、缓存）
· 消息中间件的作用、可靠投递与幂等
· 缓存体系与穿透/击穿/雪崩
· 负载均衡（四层/七层、算法、硬件与软件）
· 集群与分布式、分布式事务方案 - 第五板块：虚拟化、云与容器
· 虚拟化类型与 Hypervisor 两类
· 云计算三层（IaaS/PaaS/SaaS）与四种部署形态
· 容器、Kubernetes、云原生、Serverless - 第六板块：高可用、容灾与连续性
· 可用性指标与年停机时间换算
· RTO/RPO、备份方式、冷温热备、双机双工
· 灾难恢复能力 1---6 级、两地三中心、同城双活、单元化 - 第七板块：性能容量与架构演进
· 性能指标、性能测试类型、瓶颈定位与调优
· 垂直扩展与水平扩展、无状态设计
· 蓝绿/灰度/滚动发布、DevOps 与 CI/CD、技术债务
二、考点精讲
2.1 信息系统基础与架构的定义
是什么。 信息系统由五个部分组成：硬件、软件、数据、人员、规程（也叫过程或管理制度）。这五者缺一不可，其中人员是主体、数据是对象、硬件软件是手段、规程是保障。信息系统在运行上表现为"输入---处理---输出---反馈---控制"的闭环。
怎么考。 一是问"信息系统由哪几部分组成"，多选直接考五要素；二是给场景判断系统类型，如下表。2018---2025 年间，系统类型题以单选为主，偶尔出多选。
| 系统类型 | 全称 | 处理对象与特点 | 典型例子 |
|---|---|---|---|
| TPS | 事务处理系统 | 处理日常联机交易，实时、明细、结构化，是 MIS 的数据来源 | 银行核心系统、柜面交易、ATM 取款 |
| MIS | 管理信息系统 | 对 TPS 数据进行汇总统计与报表，面向中层管理，解决结构化问题 | 经营报表、绩效考核系统 |
| DSS | 决策支持系统 | 模型库 + 数据库 + 对话接口，面向高层，解决半结构化问题 | 信贷定价测算、风险偏好模拟 |
| ES | 专家系统 | 知识库 + 推理机，把专家经验规则化，解决需要专家判断的问题 | 反洗钱可疑交易研判、贷款审批辅助 |
| OA | 办公自动化系统 | 公文流转、协同办公、流程审批 | 银行内部公文与用印审批 |
【易错】TPS 与 MIS 的分界是"明细交易"与"汇总分析"；DSS 与 ES 的分界是"模型计算"与"知识推理"。DSS 强调模型和模拟，ES 强调知识库和推理机，两者在题干中常被故意互换。
银行报考者还要知道：核心系统属于 TPS，数据仓库与报表平台属于 MIS 的延伸，而资产负债管理、经济资本计量这类带模型测算的系统更接近 DSS。
架构是什么。 软件架构是软件系统的结构，由三要素构成：构件（组件）、连接件（连接机制）、约束（配置规则）。构件是计算或存储的单元，连接件是构件之间的交互机制（调用、消息、管道、事件），约束规定了构件如何连接、如何组合。架构是系统的骨架，是"在需求与实现之间做出的、难以更改的设计决策集合"。
架构的作用有四个：一是作为各方沟通的共同语言，使业务、开发、运维、测试对系统有一致理解；二是承载并落实质量属性，性能、可用性、安全性等非功能需求主要靠架构解决；三是支持复用与演化，好的架构让系统能低成本扩展和替换；四是支持项目计划与成本估算，为任务分解、人员分工提供依据。
【真题】2021 年单选题：软件架构设计是降低成本、改进质量、按时交付的关键活动，以下关于软件架构重要性的叙述中，错误的是（ ）。A. 架构设计能够满足系统的性能、可维护性等品质 B. 良好的架构设计能够更好地捕获并了解用户需求 C. 架构设计能够使得不同利益相关方达成一致的目标 D. 架构设计能够支持项目计划和项目管理等活动。【答案】B。【解析】捕获和了解用户需求是需求分析阶段的任务，不是架构设计的作用；架构是在需求明确之后，对系统结构做出的高层决策。（2021 年卷无公开答案页，答案按考点推定）
易错点。 第一，架构不等于详细设计，架构关注"有哪些构件、怎么连、受什么约束"，详细设计关注类、接口、算法；第二，架构不能替代需求分析（上面真题的坑）；第三，架构是"难以更改的决策"，所以架构评审要早做；第四，构件＋连接件＋约束是必背三要素，常把"约束"替换成"接口"来设错。
2.2 架构视图：4+1 视图、TOGAF ADM 与 Zachman
是什么。 一个系统不可能用一张图描述清楚，所以要用多个视图从不同角度描述，每个视图只关心一类关注点、面向一类干系人。最经典的是 Kruchten 提出的"4+1 视图"：逻辑视图、开发视图、进程视图、物理视图，再加一个场景视图。"4+1"中的"1"就是场景（用例）视图，它把其余四个视图串起来并验证它们是否自洽。
| 视图 | 关注点 | 主要干系人 | 常用表达 |
|---|---|---|---|
| 逻辑视图 | 系统提供什么功能、有哪些类与对象、静态结构 | 最终用户、分析设计人员 | 类图、对象图 |
| 开发视图 | 代码如何组织、包与构件如何划分、如何复用 | 程序员、配置管理员 | 包图、构件图 |
| 进程视图 | 并发、同步、性能、吞吐量、运行时进程与线程 | 系统集成人员、性能工程师 | 状态图、活动图 |
| 物理视图 | 软件如何映射到硬件、节点部署、网络与容灾 | 系统工程人员、运维人员 | 部署图 |
| 场景/用例视图 | 用典型用例验证上述四个视图，串联需求与设计 | 全部干系人 | 用例图 |
【真题】2020 年单选题：在 UML 提供的系统视图中，下列哪一个视图是最基本的需求分析模型？（ ）A. 部署视图 B. 进程视图 C. 逻辑视图 D. 用例视图。【答案】D。【解析】用例视图即场景视图，从用户角度描述系统功能，是需求分析最基本的模型，也是 4+1 视图中"1"的落点。（2020 年卷无公开答案页，答案按考点推定）
TOGAF ADM。 TOGAF 是企业架构领域最主流的框架，其核心是 ADM（架构开发方法）。ADM 由一个预备阶段和 A---H 共 8 个正式阶段组成，中间始终环绕"需求管理"。考试常问"ADM 有几个阶段""某阶段做什么"，所以下表要按顺序背。
| 阶段 | 名称 | 核心任务 |
|---|---|---|
| 预备 | Preliminary | 确定架构能力、架构原则、治理与裁剪方案，建立架构团队 |
| A | 架构愿景 | 明确架构范围、干系人、目标与高层愿景，形成架构工作说明书 |
| B | 业务架构 | 描述业务战略、组织、流程、能力，回答"业务怎么干" |
| C | 信息系统架构 | 含数据架构与应用架构两部分，回答"有哪些数据、有哪些应用" |
| D | 技术架构 | 描述技术构件、平台与服务，回答"用什么技术承载" |
| E | 机会及解决方案 | 把架构差距转化为工作包与项目，划分实施批次 |
| F | 迁移规划 | 制定实施与迁移计划、优先级、成本与风险 |
| G | 实施治理 | 对实施项目进行架构合规性检查与治理 |
| H | 架构变更管理 | 管理架构变更需求，驱动下一轮 ADM 循环 |
【易错】ADM 常被简称为"8 个阶段"，严格说是"1 个预备阶段 + A---H 8 个阶段"，另有贯穿全程的需求管理。考试问"ADM 有几个阶段"按 8 个（A---H）作答，把需求管理也算作一个阶段（共 9 个）是常见错误表述。另外 B、C、D 分别对应业务架构、信息系统架构（数据＋应用）、技术架构，与企业架构四层的对应关系是必考点。
Zachman 框架。 Zachman 是一个分类（本体）框架，用 6 行 × 6 列的矩阵描述企业架构。列是六个基本疑问：What（数据）、How（功能）、Where（网络）、Who（人员）、When（时间）、Why（动机）；行是六类视角：规划者（范围）、所有者（业务模型）、设计者（系统模型）、构建者（技术模型）、实现者（详细表达）、使用者（运行中的企业）。它回答"用哪些描述来刻画企业"，本身不含开发过程。
【易错】TOGAF 与 Zachman 的分工是经典考点：TOGAF 是"过程/方法"框架（告诉你按什么步骤做架构），Zachman 是"分类/描述"框架（告诉你从哪些维度描述架构）。把两者说成"都是架构开发方法"或"Zachman 定义了 ADM"都是错的。
2.3 架构质量属性与设计策略
是什么。 质量属性（非功能属性）是架构设计真正的目标。教材常列的六大质量属性是：性能、可用性、可修改性、安全性、可测试性、易用性。此外还有可靠性、可扩展性、互操作性、可移植性等，但考试以六大属性为主。
| 质量属性 | 含义 | 典型设计策略 |
|---|---|---|
| 性能 | 响应时间短、吞吐量大、资源占用低 | 资源调度（队列调度、优先级）、引入并发、增加计算资源、缓存、减少计算开销、异步化 |
| 可用性 | 系统在规定时间内可正常服务的比例 | 冗余（主动冗余/被动冗余）、故障检测（心跳）、故障恢复（回滚、切换）、心跳与选举 |
| 可修改性 | 修改功能或结构的成本低 | 模块化、信息隐藏、限制依赖、发布-订阅、分层 |
| 安全性 | 抵抗攻击、数据保密与可审计 | 认证授权、加密、审计日志、最小权限、隔离 |
| 可测试性 | 容易观察和验证系统行为 | 清晰的接口、可观测性、日志与埋点、依赖可替换 |
| 易用性 | 用户学习与使用成本低 | 界面一致性、任务向导、帮助与提示、错误恢复 |
怎么考。 一是给一个设计动作，问它提升哪种质量属性（如"加队列缓冲"提升性能/削峰）；二是给一个质量属性，问用哪些战术实现；三是考质量属性之间的权衡。
【真题】2020 年单选题：下列哪个设计策略有助于提升系统的性能？（ ）A. 分层结构 B. 事务机制 C. 主动冗余 D. 队列调度。【答案】D。【解析】队列调度属于性能战术中的"资源调度"，通过排队与优先级安排提升吞吐与响应；分层结构主要提升可修改性且带来跨层调用开销；事务机制保障一致性；主动冗余提升可用性。（2020 年卷无公开答案页，答案按考点推定）
【易错】"主动冗余"提升的是可用性，不是性能；"分层"提升可修改性但通常损失性能；"加密"提升安全性但损失性能；"缓存"提升性能但代价是一致性。这类"策略---属性"对应关系每年至少一题，必须成对记忆。
质量属性还可以用"质量属性场景"来精确描述，一个完整场景包含六要素：刺激源、刺激、环境、制品、响应、响应度量。例如"在业务高峰期（环境），大量用户（刺激源）发起查询请求（刺激），系统在 1 秒内返回结果（响应与度量）"。
2.4 架构风格五大类与识别方法
是什么。 架构风格是对一类系统组织方式的抽象，规定了构件与连接件的类型、组合规则和语义。Garlan 和 Shaw 的经典分类是五大类，这是本章最高频的命题点。
| 大类 | 子风格 | 核心特征 | 金融场景举例 |
|---|---|---|---|
| 数据流 | 批处理序列、管道-过滤器 | 数据按顺序流经处理单元，处理单元之间通过数据流连接 | 日终批量、清算文件处理、ETL |
| 调用返回 | 主程序-子程序、面向对象、层次结构 | 一个构件调用另一个构件，调用方向明确 | 传统分层业务系统 |
| 独立构件 | 进程通信、隐式调用（事件驱动） | 构件之间不直接调用，通过事件或消息解耦 | 事件驱动风控、消息通知、渠道联动 |
| 虚拟机 | 解释器、规则系统 | 系统包含一个"虚拟执行环境"，按规则或指令解释执行 | 规则引擎、产品定价、脚本化流程 |
| 仓库 | 数据库系统、黑板、超文本 | 以共享数据为中心，构件围绕数据读写协作 | 数据仓库、报表平台、知识库系统 |
逐个子风格要点。
- 管道-过滤器：过滤器彼此独立、不共享状态，可复用、可并发、支持增量处理，新增过滤器容易；缺点是交互性差、不适合复杂用户交互，且数据格式转换有开销。
- 批处理序列：整体按顺序执行、无并发、无交互，适合大规模定时处理，典型如银行日终批量、总分核对。
- 隐式调用（事件驱动）：构件通过发布事件、订阅事件通信，松耦合、易扩展，新增订阅者不影响发布者；缺点是控制流不确定、整体行为难推导、调试与测试困难。
- 规则系统：由规则库、规则引擎、工作内存组成，业务规则独立于程序代码、可动态调整，适合规则频繁变化且需要业务人员参与维护的场景。
- 解释器：把业务逻辑写成可解释的脚本或模型，由解释引擎执行，灵活性高但性能低于编译执行。
- 黑板：多个知识源围绕共享黑板协作，没有确定的求解算法，由控制构件决定知识源的触发顺序，典型用于人工智能、语音识别、信号处理。
- 层次结构：每层只依赖相邻下层，层内变化不影响其他层，支持复用与替换；缺点是跨层调用带来性能损失，不是所有系统都能抽象成清晰层次。
- 仓库风格中的数据库系统：多个构件围绕中心数据库协作，数据集成度高，但数据结构变更影响面大。
怎么考。 最常见的是"给场景选风格"。看到"业务规则频繁调整、由业务人员配置"就选规则系统；看到"定时批量处理、顺序执行"选批处理；看到"多个处理步骤串成流水线、可增删步骤"选管道-过滤器；看到"异步通知、发布订阅、松耦合"选事件驱动/隐式调用；看到"知识源协同、无固定算法"选黑板；看到"数据集中、构件围绕数据"选仓库。
【真题】2021 年单选题：某公司拟开发一个 VIP 会员管理系统，系统需根据不同商场活动，不定期更新 VIP 会员的审核标准和 VIP 折扣标准。针对上述需求，采用（ ）架构风格最为合适。A. 规则系统 B. 过程控制 C. 事件驱动 D. 管道-过滤器。【答案】A。【解析】"审核标准和折扣标准"属于业务规则，需要不定期更新且由业务人员维护，规则系统把规则从代码中抽出、由规则引擎解释执行，正好匹配"规则频繁变更"这一需求特征。
【易错】三个高频混淆：第一，批处理与管道-过滤器同属数据流风格，但批处理是整体顺序执行、无并发，管道-过滤器可并发、可增量，题干出现"流水线、可插拔过滤器"要选管道-过滤器；第二，事件驱动属于独立构件风格，不是"调用返回"；第三，规则系统与解释器同属虚拟机风格，但规则系统强调"规则库+规则引擎"，解释器强调"解释执行指令/脚本"，2021 年真题的陷阱正是把规则系统混在仓库风格里让人犹豫。
选型的通用原则。 架构风格没有优劣，只看匹配度：交互复杂、界面多变选调用返回或分层；处理流程固定、数据量大选数据流；需要解耦、异步、扩展选事件驱动；规则多变选规则系统；以数据共享为核心选仓库。多选题若问"属于数据流风格的有"，答案应包含批处理序列与管道-过滤器，不要把"事件驱动"选进去。
2.5 分层架构与 MVC / MVP / MVVM
是什么。 分层架构把系统按职责纵向切分，每层只依赖下层、向上层提供服务。最常见的是三层架构：表示层、业务逻辑层、数据访问层。
| 层次 | 职责 | 典型内容 |
|---|---|---|
| 表示层（UI） | 接收用户输入、展示结果、做基础校验 | 页面、APP 界面、接口报文拼装 |
| 业务逻辑层（BLL） | 实现业务规则、流程编排、事务控制 | 账户服务、额度计算、审批流程 |
| 数据访问层（DAL） | 封装数据读写、屏蔽数据库差异 | 数据访问对象、ORM 映射、DAO |
三层之上再加"服务层/接口层"就是四层，再往下拆就是多层（N 层）。分层的优点是职责清晰、可替换、可复用、便于分工；缺点是调用链变长导致性能下降，且层间如果随意跨层调用就会退化成"假分层"。
MVC。 MVC 是一种表现层的设计模式（也常被当作架构模式）：模型（Model）承载业务数据和业务逻辑，视图（View）负责展示，控制器（Controller）接收请求、调度模型与视图。三者职责必须分清。
| 部分 | 职责 | 关键点 |
|---|---|---|
| 模型 Model | 业务数据、业务规则、状态管理 | 业务逻辑的核心，与界面无关 |
| 视图 View | 把模型数据渲染成用户界面 | 只负责表现，不写业务逻辑 |
| 控制器 Controller | 接收用户请求、调用模型、选择视图 | 起调度作用，不承载业务规则 |
【真题】2020 年单选题：MVC 架构模式中，业务数据和业务逻辑主要由下列哪部分负责？（ ）A. 模型 B. 控制 C. 视图 D. 模型和控制。【答案】A。2022 年单选题：MVC 模式中，（ ）主要表现用户界面。A. 视图 B. 模型 C. 控制器 D. 视图和控制器。【答案】A。【解析】两题一正一反，考的都是 MVC 三部分的职责边界：模型管业务数据与逻辑，视图管界面表现，控制器管请求调度。（2020 年卷无公开答案页，该题答案按考点推定；2022 年卷有官方解析，答案一致）
MVP 与 MVVM。 MVP 把控制器换成 Presenter，Presenter 通过接口与视图交互，视图完全被动，便于单元测试，适合界面逻辑复杂的桌面或原生客户端。MVVM 把 Presenter 换成 ViewModel，利用双向数据绑定把视图状态与 ViewModel 自动同步，视图与逻辑进一步解耦，是前端框架的主流组织方式。
【易错】三者区别只在"中间那一层怎么和视图交互"：MVC 的控制器可以直接操作视图；MVP 的 Presenter 通过接口操作视图，视图被动；MVVM 的 ViewModel 通过数据绑定与视图双向同步。多选题若问"MVC 各部分的职责"，不要把"业务逻辑"分给控制器或视图。
2.6 C/S 与 B/S 架构
是什么。 C/S（Client/Server）是客户端/服务器两层架构，业务逻辑一部分在客户端、一部分在服务器；B/S（Browser/Server）是浏览器/服务器架构，客户端只需要浏览器，业务逻辑集中在服务器端，通常表现为"浏览器---Web 服务器/中间件---应用服务器---数据库服务器"的多层结构。
| 对比项 | C/S 架构 | B/S 架构 |
|---|---|---|
| 客户端 | 需安装专用客户端（胖客户端） | 只需浏览器（瘦客户端） |
| 部署与升级 | 每台机器都要安装升级，成本高 | 服务器端升级，客户端零安装 |
| 交互与性能 | 界面丰富、响应快、可离线处理 | 交互受浏览器限制，依赖网络 |
| 跨平台 | 差，需分平台开发 | 好，浏览器天然跨平台 |
| 安全性 | 客户端可缓存数据，管控难度大 | 数据集中在服务端，便于管控 |
| 适用场景 | 柜面终端、高频交易、图形密集处理 | 网银、手机银行、内部管理系统、对外门户 |
B/S 的访问顺序。 这是真题原题考过的细节：用户通过浏览器发起请求，先到 Web 服务器/中间件（负责接入、静态资源、反向代理），再转发给应用服务器（执行业务逻辑），最后由应用服务器访问数据库服务器。
【真题】2020 年单选题：在一个多层 B/S 架构中，应用访问从用户端到后台的通常顺序是（ ）。A. 浏览器、应用服务器、中间件、数据库服务器 B. 浏览器、数据库服务器、中间件、应用服务器 C. 浏览器、中间件、应用服务器、数据库服务器 D. 浏览器、应用服务器、数据库服务器、中间件。【答案】C。【解析】浏览器先到中间件（Web 服务器/接入层），再进入应用服务器执行业务逻辑，最后访问数据库；中间件在应用服务器之前、数据库在最后，是基本顺序。（2020 年卷无公开答案页，答案按考点推定）
中间件在 B/S 中的作用。 中间件位于操作系统与应用程序之间，屏蔽网络与平台的差异，提供接入、事务、消息、缓存等通用能力，使应用服务器专注业务逻辑。三层 B/S 之所以能"瘦客户端＋集中管理"，正是靠中间件层把接入与业务分离。
【易错】第一，B/S 不是"没有客户端"，浏览器就是客户端；第二，三层 B/S 不等于"浏览器直接连数据库"，数据库只能由应用服务器访问；第三，C/S 并非已被淘汰，柜面、交易终端等对响应和交互要求高的场景仍用 C/S，考试常以"凡是 B/S 都优于 C/S"设错；第四，手机银行 APP 需要下载安装客户端，从架构形态看更接近 C/S 的胖客户端模式，但业务上采用前后端分离与多层服务端架构，遇到此类题要先看题干强调的是"安装方式"还是"服务端分层"。
2.7 企业架构四层与 IT 战略规划
是什么。 企业架构（EA）是把整个企业的业务、应用、数据、技术统一起来描述和规划的方法。它分为四个架构域，这是多选题的固定考点，必须逐项记全。
| 架构域 | 回答的问题 | 主要内容 | 与 TOGAF ADM 对应 |
|---|---|---|---|
| 业务架构 | 企业做什么业务、怎么组织 | 业务战略、组织架构、业务流程、业务能力 | 阶段 B |
| 应用架构 | 有哪些应用系统、如何交互 | 应用现状、应用要素（服务域/服务类/服务组件）、应用体系设计 | 阶段 C |
| 数据架构 | 有哪些数据、如何管理 | 数据模型、数据标准、主数据、数据分布与流转 | 阶段 C |
| 技术架构 | 用什么技术承载 | 技术平台、基础设施、中间件、部署与安全技术 | 阶段 D |
【真题】2021 年多选题：以下属于信息系统架构的有（ ）。A. 业务架构 B. 技术架构 C. 应用架构 D. 数据架构。【答案】ABCD。【解析】四个架构域并列构成企业架构（信息系统总体架构），缺一不可，多选必须全选。（2021 年卷无公开答案页，答案按考点推定）
应用架构规划的内容。 应用架构以业务架构为依据，说明应用体系的结构与相互关系，其规划内容包含三项：一是应用现状，描述现有应用系统的功能、边界、技术栈与问题；二是应用要素，说明服务域、服务类、服务组件；三是应用体系设计，按信息化建设要求规划设计主要业务与相关领域的应用系统。
【真题】2022 年单选题：信息系统总体规划中需要进行应用架构规划，（ ）不属于应用架构规划应考虑的内容。A. 应用建模 B. 应用现状 C. 应用要素 D. 应用体系设计。【答案】A。【解析】应用架构规划的内容是应用现状、应用要素、应用体系设计三项；应用建模属于系统分析与设计阶段的建模活动，不属于应用架构规划的固定内容。
IT 战略规划与 IT 治理。 IT 战略规划的核心是"业务与 IT 对齐"：先明确业务战略与能力需求，再推导 IT 能力蓝图、应用蓝图与实施路线图，最后落到投资与项目组合。IT 治理是在治理层面对 IT 决策权、责任、风险与价值进行制度安排，常用框架是 COBIT；IT 服务管理常用 ITIL，其核心模块是服务管理（服务支持与服务交付）。
【真题】2021 年单选题：商业银行实施 IT 治理框架时，最重要的目标是（ ）。A. 实现 IT 价值 B. IT 与业务目标相一致 C. IT 风险可计量 D. 增加 IT 投资回报。【答案】B。【解析】IT 治理的首要目标是保证 IT 与业务目标一致，在此基础上才有价值交付、风险可控与资源优化；"实现 IT 价值""风险可计量"都是目标之一，但不是"最重要"。（2021 年卷无公开答案页，答案按考点推定）
【易错】企业架构四层不要写成三层（漏掉数据架构）或多加"安全架构""网络架构"；应用架构规划的三项内容不要与"应用建模"混为一谈；IT 治理（治理层，定方向、定责任）与 IT 管理（执行层，做运维、做服务）不是一回事。
2.8 SOA 与微服务
是什么。 SOA（面向服务的架构）把业务功能封装成可复用的服务，通过标准化接口与松耦合方式组合，实现跨系统的集成与复用。SOA 的三要素是：服务、企业服务总线（ESB）、服务编排。其中 ESB 承担服务路由、协议转换、消息转换、服务注册与监控；服务编排用流程把多个服务串成端到端业务；服务本身强调粗粒度、标准化契约、位置透明、可复用。
| 对比项 | SOA | 微服务 |
|---|---|---|
| 服务粒度 | 粗粒度，一个服务可能覆盖一个业务域 | 细粒度，一个服务只做一件事 |
| 通信方式 | 多依赖 ESB 等智能管道 | 轻量级通信（HTTP/REST、RPC、消息） |
| 数据管理 | 常共享数据库或集中数据层 | 每个服务独立数据库，去中心化 |
| 部署方式 | 常与单体应用混合部署 | 独立打包、独立部署、独立扩缩容 |
| 治理方式 | 集中治理、统一标准 | 分散治理、去中心化、自动化 |
| 典型问题 | ESB 易成为单点与瓶颈 | 分布式事务、运维复杂度高 |
怎么考。 一是给场景判断"用 SOA 还是微服务"；二是多选题考微服务的特征与组件；三是以"微服务粒度越粗越好""微服务必须依赖 ESB"设错。
【真题】2020 年单选题：关于微服务，以下说法正确的是（ ）。A. 与 SOA 相比，微服务粒度要粗一些 B. 微服务数量越多越好 C. 微服务需要企业服务总线支持服务间通信 D. 微服务提倡轻量级的通信方式。【答案】D。【解析】微服务粒度比 SOA 更细；拆分不是越多越好，过度拆分带来分布式事务与运维成本；微服务强调去中心化、轻量级通信，正是对 ESB 集中式管道的替代，故 A、B、C 均错。（2020 年卷无公开答案页，答案按考点推定）
【易错】SOA 不等于"过时"，微服务可以看作 SOA 思想在容器与 DevOps 条件下的落地；"微服务一定比 SOA 好"是错误表述；"微服务需要 ESB"是典型陷阱，微服务恰恰强调轻量级通信与服务自治。
2.9 微服务关键组件与服务治理
是什么。 微服务把单体应用按业务能力拆成一组小服务，每个服务独立开发、部署、扩缩容。拆开之后，原来在单体内部的一次方法调用变成了跨进程调用，于是必须补齐一组基础设施组件，这就是微服务组件体系。
| 组件 | 解决什么问题 | 关键点 |
|---|---|---|
| 注册中心 | 服务实例地址动态变化 | 服务注册与发现、健康检查（如 Nacos、Eureka、Consul） |
| 配置中心 | 配置分散、需动态生效 | 集中管理、灰度发布配置、动态刷新 |
| 服务网关 | 统一入口、统一鉴权 | 路由转发、鉴权、限流、熔断、日志、协议转换 |
| 负载均衡 | 请求分摊到多实例 | 客户端负载均衡与服务端负载均衡 |
| 熔断降级 | 下游故障引发雪崩 | 熔断器三态（关闭、打开、半开）、降级返回兜底 |
| 限流 | 流量超过处理能力 | 令牌桶、漏桶、滑动窗口，保护系统不被打垮 |
| 链路追踪 | 一次请求跨多个服务，排障困难 | TraceID 贯穿、调用链与耗时分析（如 SkyWalking、Zipkin） |
| 消息中间件 | 服务间异步解耦 | 最终一致性、削峰填谷 |
| 服务治理 | 版本、路由、灰度、权重 | 灰度发布、流量染色、服务分组 |
服务拆分原则。 一是按业务能力拆分（如账户、支付、额度、风控各成服务）；二是按领域驱动设计（DDD）的限界上下文拆分，一个限界上下文对应一个服务边界；三是单一职责、高内聚低耦合；四是数据库独立，服务之间不直接访问对方数据库，只通过接口或消息交互；五是拆分粒度以团队规模与业务边界为准，不是越细越好。
【易错】注册中心与配置中心的区别：注册中心管"服务在哪"，配置中心管"参数是什么"，两者常由同一产品（如 Nacos）提供，但职责不能混。熔断与限流的区别：熔断是下游已经出问题时"断开"以免被拖死，限流是入口流量过大时"挡住"一部分。降级是主动放弃非核心功能保核心功能，不是故障本身。
2.10 中台、API 网关与前后端分离
是什么。 中台是把各业务线重复建设的能力抽出来、沉淀为可复用的共享能力，从而让前台快速响应市场。常见分类是：业务中台（用户中心、订单中心、支付中心、产品中心等共性业务能力）、数据中台（数据采集、治理、资产化、服务化，输出标签、指标、模型）、技术中台（微服务框架、中间件、DevOps 与容器平台）。
中台与平台的区别。 平台偏技术与资源支撑（如云平台、消息平台），中台强调"业务能力复用"并直接服务前台。中台建设失败的常见原因是只建技术平台、不做业务沉淀与组织配套。
API 网关与前后端分离。 前后端分离指前端（Web、APP、小程序）只负责展示与交互，通过 RESTful API 调用后端；后端不再渲染页面，只提供接口。API 网关是后端的统一入口，负责路由、鉴权、限流、熔断、日志、协议转换与版本管理，使内部服务不直接暴露给外部。
【易错】中台不是"技术平台"的同义词；业务中台沉淀的是业务能力，数据中台沉淀的是数据资产与服务；API 网关与 ESB 都做集成，但网关偏"对外统一入口与流量治理"，ESB 偏"内部服务集成的协议转换与路由"。
2.11 中间件分类与消息中间件
是什么。 中间件是位于操作系统、网络与应用程序之间的通用服务软件，它屏蔽底层差异、提供可复用的公共能力，使应用开发者专注业务逻辑。中间件是本章"送分题"密集区，分类必须记全。
| 中间件类型 | 作用 | 典型代表 |
|---|---|---|
| 数据库访问中间件 | 统一数据库访问接口，屏蔽数据库差异 | ODBC、JDBC、ADO.NET |
| 远程过程调用中间件 | 让跨进程、跨主机调用像本地调用一样 | RPC、gRPC、Dubbo |
| 面向消息中间件 | 异步通信、解耦、削峰、可靠传递 | Kafka、RabbitMQ、RocketMQ |
| 事务中间件（交易中间件） | 保证分布式交易的一致性与高并发处理 | Tuxedo 类交易中间件 |
| 应用服务器 | 提供 Web 容器、事务、连接池、安全等运行环境 | Tomcat、WebLogic、WebSphere、JBoss |
| Web 服务器 | 处理 HTTP 请求、静态资源、反向代理 | Nginx、Apache HTTP Server、IIS |
| 缓存中间件 | 提供高性能数据缓存 | Redis、Memcached |
| 分布式服务/对象中间件 | 服务注册发现、远程调用、治理 | 各类服务框架 |
【真题】2025 年单选题：中间件有多种类型，Windows 平台的 ODBC 和 JAVA 平台的 JDBC 属于（ ）。A. 数据库访问中间件 B. 远程过程调用中间件 C. 面向消息中间件 D. 事务中间件。【答案】A。【解析】ODBC 与 JDBC 都是数据库访问的标准接口，用于屏蔽不同数据库的差异，属于数据库访问中间件。（2025 年卷为考生回忆版、无公开答案页，答案按考点推定）
【真题】2021 年多选题：关于中间件，以下描述正确的有（ ）。A. 使用中间件可以提高应用软件的可移植性 B. 使用中间件会增加应用软件设计的复杂度 C. 使用中间件有助于提高开发效率 D. 中间件为应用软件提供特定功能的服务。【答案】ABCD。【解析】中间件屏蔽平台与网络差异，提升可移植性与开发效率，同时引入一层抽象与配置，确实增加设计与运维复杂度，其本质就是为应用提供特定通用功能的服务，四项均正确。（2021 年卷无公开答案页，答案按考点推定）
应用服务器与 Web 服务器的区别。 Web 服务器主要处理 HTTP 协议、静态资源与反向代理，不擅长运行业务逻辑；应用服务器提供容器、事务、连接池、消息等运行时能力，用来运行业务组件。实际系统中两者常组合使用：Nginx 做接入与静态资源，Tomcat 或 WebLogic 承载应用。
消息中间件的作用。 四个核心作用：异步解耦（生产者不必等消费者）、削峰填谷（把突发流量放入队列，按能力消费）、最终一致性（配合本地消息表、事务消息实现跨系统数据一致）、广播与顺序（发布订阅、分区顺序）。金融场景中，消息中间件广泛用于支付结果通知、账务异步记账、风控事件推送、批量文件处理。
| 产品 | 特点 | 典型场景 |
|---|---|---|
| Kafka | 高吞吐、分区顺序、持久化日志、生态成熟 | 日志采集、流式计算、埋点与监控 |
| RabbitMQ | 低延迟、路由灵活（多种交换机）、AMQP 协议 | 业务通知、任务分发、中小规模解耦 |
| RocketMQ | 事务消息、顺序消息、消息重试、金融级可靠 | 支付、账务、订单等一致性要求高的场景 |
可靠投递与幂等。 可靠投递要解决"生产不丢、存储不丢、消费不丢"：生产端用确认机制与重试，存储端用持久化与多副本，消费端用确认（ACK）与重试队列。但"至少一次"投递必然带来重复，所以消费端必须幂等：用业务唯一键、去重表、状态机或版本号保证同一消息重复执行结果不变。
【易错】消息队列不能保证"恰好一次"，工程上常用"至少一次 + 幂等"；削峰填谷削的是"流量峰值"，不是"数据量"；异步解耦的代价是一致性从强一致变为最终一致，账务类场景必须补偿与对账。
2.12 缓存体系与三大缓存问题
是什么。 缓存是把高频访问的数据放在离计算更近、速度更快的存储中，以降低响应时间、减轻数据库压力。按位置分为本地缓存（进程内，如 Caffeine）与分布式缓存（独立部署，如 Redis、Memcached）。本地缓存快但多实例间不一致，分布式缓存一致性好但有网络开销。
Redis 要点。 常用数据结构有五种：String（计数、token）、Hash（对象属性）、List（队列、时间线）、Set（去重、交并集）、ZSet（排行榜、延时队列）。持久化有两种：RDB 是周期性快照，文件小、恢复快，但可能丢失最后一次快照后的数据；AOF 是追加写命令日志，数据更完整、可配置每秒同步，但文件大、恢复慢，需要重写压缩。实际生产常采用"RDB + AOF"混合持久化。
| 问题 | 现象 | 原因 | 对策 |
|---|---|---|---|
| 缓存穿透 | 查询不存在的数据，请求直打数据库 | 恶意攻击或业务查无此数据，缓存永远不命中 | 布隆过滤器拦截、缓存空值并设短过期、参数校验 |
| 缓存击穿 | 某个热点 key 过期瞬间，大量请求压到数据库 | 热点 key 失效，重建成本高 | 互斥锁/分布式锁重建、逻辑过期不删 key、热点永不过期 |
| 缓存雪崩 | 大量 key 同时失效或缓存集群宕机，数据库被打垮 | 过期时间集中、缓存层不可用 | 过期时间加随机值、缓存集群高可用、限流降级、多级缓存 |
缓存一致性。 常用 Cache Aside 模式：读时先读缓存、未命中读数据库并回填；写时先更新数据库、再删除缓存（不是更新缓存）。删除失败可用延迟双删或订阅数据库变更日志（binlog）补偿。强一致场景不宜用缓存，缓存本质是用一致性换性能。
【易错】穿透是"查不存在的数据"，击穿是"一个热点 key 失效"，雪崩是"一片 key 同时失效或缓存整体不可用"，三者常被互换设错。写缓存时"先删缓存再更新数据库"与"先更新数据库再删缓存"都可能不一致，考试只要求知道主流做法是后者并配合补偿。
2.13 负载均衡与集群
是什么。 负载均衡把请求按策略分发到多个服务实例，目的是提升吞吐、降低延迟、提高可用性、支持横向扩展。它是"集群"对外表现为一台逻辑设备的关键。
| 对比项 | 四层负载均衡 | 七层负载均衡 |
|---|---|---|
| 工作层次 | 传输层（TCP/UDP），基于 IP + 端口 | 应用层（HTTP/HTTPS），可解析 URL、Header、Cookie |
| 典型产品 | LVS、F5 等硬件设备 | Nginx、HAProxy、云负载均衡 |
| 性能 | 高，转发开销小 | 相对低，需解析应用层内容 |
| 能力 | 连接级转发，不懂内容 | 内容路由、会话保持、SSL 卸载、灰度分流、改写 |
| 适用 | 大流量入口、TCP 服务 | Web 应用、需要按内容分流的场景 |
常见算法。 轮询（依次分发）、加权轮询（按能力分配）、最少连接（发给当前连接最少的实例）、加权最少连接、源地址哈希（同一客户端固定到同一实例，实现会话保持）、一致性哈希（节点变化时影响面小）、响应时间优先。
硬件与软件。 硬件负载均衡（如 F5）性能强、功能全、成本高；软件负载均衡（LVS、Nginx、HAProxy）成本低、部署灵活、可扩展。银行常见做法是"硬件负载均衡做入口 + 软件负载均衡做应用层"。
集群。 集群是把多台服务器组织成一台逻辑设备，对外透明。按目的分为三类：高可用集群（主备切换，故障时接管）、负载均衡集群（多实例分担请求）、高性能计算集群（并行计算）。集群解决的是"同一件事多人干"，分布式解决的是"不同的事分开干"。
会话保持。 有状态应用需要把同一用户的请求固定到同一实例，常用源 IP 哈希、Cookie 插入或重写、会话粘滞。更好的做法是会话外置（Redis 存会话）实现无状态化，从而任意实例都能处理任意请求。
【真题】2020 年单选题：以下关于负载均衡的叙述中，错误的是（ ）。A. 负载均衡并不会增加系统的吞吐量 B. 负载均衡可以通过硬件或软件实现 C. 负载均衡可以在不同地理位置、不同网络结构的服务器群之间进行 D. 负载均衡可使用户只通过一个 IP 地址或域名就能访问相应的服务器。【答案】A。【解析】负载均衡通过多实例分担请求，可以提升整体吞吐量与并发能力，A 项说法错误；B、C、D 均正确，负载均衡既可由硬件也可由软件实现，并可跨机房、以统一地址对外服务。（2020 年卷无公开答案页，答案按考点推定）
【易错】负载均衡的作用是"提吞吐、提可用、可扩展"，不是"降低单机压力"这么简单；四层与七层的区别在"是否解析应用层内容"，不要记成"四层比七层慢"；源地址哈希是为了会话保持，不是为了提高命中率。
2.14 分布式系统与分布式事务
是什么。 分布式系统是把一个系统拆到多台机器上，各节点通过网络协作，对外表现为一个整体。它与集群的区别是：集群是"同样的服务多份"，分布式是"不同的服务分开"。分布式带来可扩展、高可用、地理容灾，也带来网络不可靠、时钟不同步、局部失败、数据一致性问题。
CAP 与 BASE。 CAP 指一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。分布式系统必须容忍网络分区，所以 P 必选，实际是在 C 与 A 之间取舍；这也是为什么很多互联网系统选择最终一致性。BASE 是对 CAP 中 AP 的工程化延伸：基本可用（Basically Available）、软状态（Soft state）、最终一致（Eventually consistent）。
| 方案 | 机制 | 一致性 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|---|
| 2PC 两阶段提交 | 协调者先询问准备，再统一提交/回滚 | 强一致 | 原理简单、数据库支持好 | 同步阻塞、协调者单点、性能差 | 强一致要求、参与者少的场景 |
| 3PC | 在 2PC 前加 CanCommit，并引入超时 | 较强 | 降低阻塞范围 | 仍有脑裂、实现复杂 | 较少直接使用 |
| TCC | Try 预留资源、Confirm 确认、Cancel 取消 | 最终一致（业务层面强） | 性能较好、业务可控 | 侵入性强，需写三个接口、防悬挂 | 资金、库存等核心交易 |
| 消息最终一致性 | 本地消息表 + 消息中间件重试 | 最终一致 | 解耦、吞吐高 | 需幂等、需对账 | 跨系统通知、账务异步记账 |
| Saga | 长事务拆成本地事务，失败时按反序补偿 | 最终一致 | 无长锁、适合长流程 | 补偿逻辑复杂、无隔离性 | 跨服务的长业务流程 |
怎么考。 一是给一致性要求选方案（强一致选 2PC，核心交易选 TCC，通知类选消息最终一致）；二是多选考分布式事务方案的组成；三是把 CAP 三项说成"可以同时满足"来设错。
【易错】CAP 只能三选二的前提是"发生分区"，若系统没有分区问题则可同时满足 C 与 A；TCC 的 Cancel 是业务补偿，不是数据库回滚；"消息最终一致"必须配合幂等与对账，否则重复消费会导致重复记账。
2.15 虚拟化技术
是什么。 虚拟化把一台物理资源抽象成多个相互隔离的逻辑资源，核心是在硬件与操作系统之间加入 Hypervisor（虚拟机监视器），由它调度 CPU、内存、存储、网络并呈现给虚拟机。虚拟化的基本能力包括：多虚一（资源池化）、一虚多（分区隔离）、快照、克隆、在线迁移、资源超分。
| 分类维度 | 类型 | 特点 | 代表 |
|---|---|---|---|
| 实现方式 | 全虚拟化 | 客户操作系统无需修改，由 Hypervisor 动态翻译敏感指令 | 早期 VMware、多数商用虚拟化产品 |
| 实现方式 | 半虚拟化 | 需修改客户操作系统内核，通过超级调用与 Hypervisor 交互 | Xen 半虚拟化模式 |
| 实现方式 | 硬件辅助虚拟化 | 依赖 CPU 虚拟化指令（Intel VT-x、AMD-V）提升性能 | KVM、Hyper-V、ESXi |
| 部署形态 | Type1 裸金属型 | Hypervisor 直接运行在硬件上，性能与安全性好 | VMware ESXi、Xen、KVM、Hyper-V |
| 部署形态 | Type2 宿主型 | Hypervisor 运行在宿主操作系统之上，部署方便 | VirtualBox、VMware Workstation |
怎么考。 一是判断"全虚拟化/半虚拟化/硬件辅助"的特征（是否修改客户机操作系统）；二是判断 Type1 与 Type2；三是与容器对比。裸金属（Bare Metal）另指直接把业务部署在物理服务器上，不经虚拟化层，性能最高但资源利用率低，是"虚拟化"的反面而不是一种虚拟化。
【易错】半虚拟化的标志是"修改客户操作系统内核"，全虚拟化的标志是"客户机无感知、不改 OS"；硬件辅助虚拟化是加速手段，可与全虚拟化结合，不是独立于两者的第四类；Type1 的 Hypervisor 直接跑在硬件上，Type2 才是"装在操作系统上的软件"。
2.16 云计算三层与部署形态
是什么。 云计算把计算、存储、网络等资源以服务方式按需提供，具有按需自服务、广泛网络访问、资源池化、快速弹性、可计量服务五个基本特征。按服务层次分为 IaaS、PaaS、SaaS 三层，这是本章每年必考的多选或单选。
| 层次 | 提供什么 | 用户负责什么 | 金融场景举例 |
|---|---|---|---|
| IaaS 基础设施即服务 | 虚拟机、裸金属、云硬盘、对象存储、虚拟网络、负载均衡 | 操作系统及以上：中间件、运行时、应用、数据 | 开发测试资源池、灾备资源池、非核心系统服务器 |
| PaaS 平台即服务 | 数据库服务、中间件服务、消息服务、容器平台、DevOps 工具链 | 应用与数据（不碰操作系统与运行时） | 应用托管平台、微服务运行平台、数据库即服务 |
| SaaS 软件即服务 | 可直接使用的成品软件 | 只负责使用与配置 | 企业邮箱、协同办公、客服系统、报销系统 |
判断口诀。 看"谁管操作系统"：用户管操作系统就是 IaaS，平台管操作系统、用户只管应用就是 PaaS，用户连应用都不管、直接用功能就是 SaaS。再记三个例子：云主机是 IaaS，云数据库与容器平台是 PaaS，在线办公软件是 SaaS。
部署形态。 公有云（面向公众、多租户共享）、私有云（单一组织专用、可自建或托管）、混合云（公有云与私有云组合、数据与业务按敏感度分布）、社区云/行业云（若干同行业组织共同使用）。金融行业的合规取向是：核心业务系统与敏感数据放在私有云或行业云，非核心、可弹性伸缩的业务可用公有云，且必须满足数据安全、业务连续性、外包与退出机制等监管要求。
【真题】2020 年单选题：某保险公司为降低成本和提高部署效率，使用公有云来部署其客户营销系统，（ ）是最值得关注的安全风险。A. 远程网络缺乏备用通讯线路 B. 云服务提供商中断外包服务 C. 云平台上存储的客户数据被共享 IT 环境上其它云租户非法访问 D. 公有云管理员操作错误。【答案】C。【解析】公有云的核心风险是多租户共享环境下的数据越权访问与隔离失效，这是保险客户信息保护最直接的威胁；通讯线路、外包中断、管理员误操作是通用风险，但不是"最值得关注"的公有云特有问题。（2020 年卷无公开答案页，答案按考点推定）
【易错】IaaS 与 PaaS 的分界是"操作系统由谁管"，不是"是否用虚拟机"；私有云不等于"自己机房"，托管也可算私有云；金融上云不是"不能上公有云"，而是按业务重要性与数据敏感度分级部署，核心系统原则上私有云/行业云。
2.17 容器、Kubernetes 与云原生
是什么。 容器是操作系统级虚拟化：多个容器共享宿主机内核，通过命名空间做资源隔离、通过控制组做资源限制，因此启动快、开销小、密度高。容器镜像由多层只读层叠加而成，容器运行时在镜像之上加一层可写层。镜像存放在镜像仓库中，由 Dockerfile 构建，实现"一次构建、到处运行"。
| 对比项 | 虚拟机 | 容器 |
|---|---|---|
| 虚拟化层次 | 硬件级，含完整客户操作系统 | 操作系统级，共享宿主内核 |
| 启动速度 | 分钟级 | 秒级甚至更快 |
| 资源开销 | 大（每个 VM 一套 OS） | 小（只含应用与依赖） |
| 镜像大小 | GB 级 | MB 级 |
| 隔离强度 | 强（硬件级隔离） | 较弱（内核共享，隔离靠 namespace/cgroup） |
| 适合场景 | 异构操作系统、强隔离、传统应用 | 微服务、持续交付、弹性伸缩、高密度部署 |
【真题】2020 年单选题：下列关于容器的说法，正确的是（ ）。A. 与虚拟机类似，容器镜像包含了一个客户机操作系统（Guest OS） B. 容器镜像包含了软件运行时环境、代码、系统工具和设置 C. 容器需要虚拟硬件 D. 与虚拟机相比，容器启动速度较慢。【答案】B。【解析】容器共享宿主机内核，镜像中不含客户机操作系统、不需要虚拟硬件，启动速度是秒级而非分钟级，A、C、D 均错；镜像打包的正是运行时环境、代码、系统工具与配置。（2020 年卷无公开答案页，答案按考点推定）
Kubernetes 要点。 Kubernetes 是容器编排平台，负责调度、自愈、扩缩容、服务发现、滚动发布与配置管理。
| 对象/组件 | 作用 |
|---|---|
| Pod | 最小调度单元，一个或多个容器共享网络与存储，同生共死 |
| Deployment | 管理无状态应用的副本数，支持滚动更新与回滚 |
| StatefulSet | 管理有状态应用，保证稳定的网络标识与存储 |
| DaemonSet | 每个节点运行一个副本，用于日志、监控、网络插件 |
| Service | 为一组 Pod 提供稳定访问入口与负载均衡 |
| Ingress | 七层入口，按域名与路径路由到不同 Service |
| ConfigMap/Secret | 配置与敏感信息与镜像解耦 |
| HPA | 按 CPU、内存或自定义指标自动伸缩副本数 |
| 控制面组件 | API Server、调度器、控制器管理器、etcd |
| 节点组件 | kubelet、kube-proxy、容器运行时 |
云原生与 Serverless。 云原生是"容器 + 微服务 + DevOps + 持续交付"的方法论集合，目标是让应用天生适合云上的弹性、自动化与快速迭代。Serverless（无服务器）进一步把服务器管理完全交给平台：函数即服务（FaaS）按事件触发、按调用计费、自动伸缩到零，代价是冷启动延迟、运行时长受限、调试与可观测性较弱。
【易错】容器不是"轻量级虚拟机"，本质区别在"是否共享宿主内核"；Kubernetes 的 Pod 不是容器，是最小调度单元；Deployment 管无状态、StatefulSet 管有状态，两者不要互换；Serverless 不是"没有服务器"，而是"用户不感知服务器"。
2.18 高可用指标、备份与容灾等级
是什么。 高可用是系统在预定时间内持续提供服务的能力。核心指标有三个：MTBF（平均无故障时间）、MTTR（平均修复时间）、可用性 A = MTBF /（MTBF + MTTR）。这一公式必背，且要注意"可用性由可靠性与可维护性共同决定"。
| 可用性等级 | 年停机时间（按 365 天计） | 通俗说法 |
|---|---|---|
| 99%（两个 9） | 约 87.6 小时 | 全年允许停 3 天多 |
| 99.9%（三个 9） | 约 8.76 小时（8 小时 45 分） | 全年允许停 1 个工作日 |
| 99.95% | 约 4.38 小时 | 全年允许停半天 |
| 99.99%（四个 9） | 约 52.6 分钟 | 全年允许停不到 1 小时 |
| 99.999%（五个 9） | 约 5.26 分钟 | 全年允许停 5 分钟 |
| 99.9999%（六个 9） | 约 31.5 秒 | 电信级、金融核心级 |
系统可用性的合成。 串联系统的可用性等于各部件可用性之积（A = A1 × A2 × ...），部件越多越不可靠；并联（冗余）系统的可用性为 1 减去各部件不可用性之积，即 A = 1 −（1 − A1）（1 − A2）...，冗余越多越可靠。这就是"串联降可用、并联提可用"。
RTO 与 RPO。 RTO（Recovery Time Objective，恢复时间目标）指业务中断后必须恢复的最长时间，衡量"停多久能接受"；RPO（Recovery Point Objective，恢复点目标）指可容忍的数据丢失量，用时间表示，衡量"丢多少数据能接受"。两者越小，灾备要求越高、成本越大。RTO 对应"业务连续性"，RPO 对应"数据保护"，不能写反。
备份方式。
| 方式 | 备份内容 | 优点 | 缺点 |
|---|---|---|---|
| 全量备份 | 备份全部数据 | 恢复简单、单份即可恢复 | 耗时、占空间大 |
| 增量备份 | 只备份上次备份以来的变化 | 备份快、空间省 | 恢复需依次叠加，恢复慢、链路易断 |
| 差异备份 | 备份上次全量以来的变化 | 备份与恢复折中 | 空间随时间增长 |
冷备、温备、热备。 冷备是设备与系统不运行、故障后才启动，RTO 最长、成本最低；温备是设备就绪但数据需恢复或应用未启动，处于中间状态；热备是实时同步、可立即接管，RTO 最短、成本最高。按接管方式分为主备（一台工作一台待命）与主主/双机双工（两台都工作、互为备份、同时负载均衡）。
【真题】2025 年单选题：通常在信息系统配置中采用容错技术，提供相应的可靠性，（ ）是集群的一种形式，两台服务器均处于活动状态，同运行相同的应用，以保证整体系统的性能，也实现了负载均衡和互为备份。A. 双机双工模式 B. 双机热备模式 C. 双机集群模式 D. 双机互备模式。【答案】A。【解析】"两台均处于活动状态、同运行相同应用、负载均衡且互为备份"正是双机双工（主主）的定义；双机热备是一主一备，备用机不对外服务；双机互备是两台各跑不同应用、互相备份。（2025 年卷为考生回忆版、无公开答案页，答案按考点推定）
灾难恢复能力 1---6 级。 依据 GB/T 20988---2007，灾难恢复能力从低到高分为六级，等级名称与核心特征是必背内容。
| 等级 | 名称 | 核心特征 | RTO/RPO 量级 |
|---|---|---|---|
| 1 级 | 基本支持 | 数据备份并异地存放，无备用场地、无备用设备 | RTO 2 天以上，RPO 1 天以上 |
| 2 级 | 备用场地支持 | 有备用场地，介质异地存放，需临时配置设备 | RTO 24 小时以上，RPO 1 天左右 |
| 3 级 | 电子传输和部分设备支持 | 数据电子传输到备用场地，配备部分数据处理设备 | RTO 12 小时以上，RPO 数小时至 1 天 |
| 4 级 | 电子传输及完整设备支持 | 备用场地配备完整设备，可接替运行 | RTO 数小时至 12 小时，RPO 数小时 |
| 5 级 | 实时数据传输及完整设备支持 | 数据实时复制到备用场地，完整设备就绪 | RTO 数十分钟至数小时，RPO 数分钟 |
| 6 级 | 数据零丢失和远程集群支持 | 远程集群/双活，自动切换，数据零丢失 | RTO 数分钟，RPO 为 0 |
【易错】第 6 级的标志是"RPO = 0"与"远程集群自动切换"，不是"有异地机房"；1---2 级都没有完整备用设备，区别在有没有备用场地；等级越高 RTO、RPO 越小，绝不能记反。考试若问"某银行要求数据零丢失"，答案指向 6 级。
2.19 两地三中心与单元化架构
是什么。 两地三中心是金融行业灾备的经典布局：一个生产中心、一个同城灾备中心、一个异地灾备中心。"两地"指同城与异地两个地理位置，"三中心"指三个数据中心。同城中心通常承担双活或热备，异地中心承担灾难性事件下的兜底。
| 布局 | 距离与链路 | 数据复制 | RTO/RPO | 作用 |
|---|---|---|---|---|
| 同城双活 | 同城，通常几十公里内，光纤直连、时延低 | 同步复制为主 | RTO 分钟级甚至接近 0，RPO 接近 0 | 抵御单中心机房级故障，业务不中断 |
| 异地灾备 | 异地，距离远 | 异步复制为主 | RTO 小时级，RPO 分钟至小时级 | 抵御城市级灾难（地震、洪水、大面积停电） |
| 两地三中心整体 | 同城 + 异地 | 同城同步、异地异步 | 兼顾局部故障与城市级灾难 | 达成监管要求的业务连续性目标 |
双活的两种含义。 应用双活指两个中心都运行应用并同时对外服务；数据双活指两套存储同时可读写、互为镜像。双活的价值是资源利用率高、切换无感，难点是数据一致性、写冲突处理、跨中心调用时延与脑裂风险。
单元化架构。 把系统按用户、客户号或地域切分成若干自包含的单元，每个单元内含完整的应用与数据，单元内闭环处理，单元之间尽量不跨调用。单元化的好处是故障爆炸半径小（一个单元故障不影响全局）、可按单元扩容、支持异地多活与灰度迁移；代价是路由复杂度高、跨单元交易需特殊处理、数据分片规则一旦确定难以调整。银行核心系统分布式改造常采用"单元化 + 分布式数据库"的组合。
【真题】2023 年多选题：双活数据中心架构分为主机层、网络层和存储层。在对双活数据中心技术的叙述中，正确的是（ ）。A. 分布于不同数据中心的存储系统均处于工作状态，两套存储系统承载相同的前端业务，且互为热备，同时承担生产和灾备服务 B. 存储双活是数据中心双活的重要基础，存储数据的双活通过使用虚拟卷镜像与节点分离两个核心功能来实现 C. 双活数据中心不仅要实现存储的双活，而且要考虑存储、网络、数据库、服务器、应用等各层面上实现双活 D. 在双活解决方案中，两项灾备关键指标 RPO（业务系统所能容忍的数据丢失量）和 RTO（所能容忍的业务停止服务最长时间）均趋于 1。【答案】ABCD。【解析】2023 年卷官方答案给 ABCD，官方解析为"双活方案是两台服务器同时工作，提高可靠性与可用性，平衡负载"。A 正确描述存储双活（两套存储同时工作、互为热备、同时承担生产与灾备）；B 指出存储双活是数据中心双活的重要基础，靠虚拟卷镜像与节点分离实现；C 强调双活必须覆盖存储、网络、数据库、服务器、应用各层面；D 项称"RPO 与 RTO 均趋于 1"，按双活定义两项指标应趋近于 0（数据零丢失、业务近零中断），该表述须理解为"趋于 0"才成立，真题按官方答案选 ABCD，但考生要记住双活指标的方向是越小越好。
【易错】两地三中心不是"三个中心都双活"，典型是"同城双活 + 异地灾备"；双活不等于"两个机房"就够，还要网络、存储、数据库、应用全链路支持；单元化不等于简单分库分表，单元是"应用 + 数据"的自包含整体。
2.20 性能容量、发布模式与架构演进
是什么。 性能是系统在给定资源下完成工作的能力，常用指标包括响应时间、吞吐量（TPS 每秒事务数、QPS 每秒查询数）、并发用户数、资源利用率、错误率与命中率。容量规划是根据业务增长预测资源需求，保证在目标负载下满足性能与可用性要求。
| 测试类型 | 目的 | 典型做法 |
|---|---|---|
| 负载测试 | 验证预期负载下的性能表现 | 逐步加压到设计负载，观察响应时间与吞吐量 |
| 压力测试 | 找系统极限与崩溃点 | 持续加压超过设计负载，直至出错或性能骤降 |
| 稳定性测试 | 验证长时间运行的可靠性 | 在 70%---80% 负载下连续运行数十小时，观察内存泄漏 |
| 并发测试 | 发现并发问题 | 多用户同时操作同一功能，查死锁、资源争用 |
| 容量测试 | 确定最大处理能力 | 逐级加压直到指标不达标，推算容量上限 |
瓶颈定位。 按资源分层看：CPU 使用率高说明计算密集或存在死循环；内存持续上涨说明内存泄漏或缓存无上限；磁盘 IO 高说明随机读写多、慢查询多或日志过量；网络带宽打满或时延抖动说明传输瓶颈；数据库层看慢 SQL、锁等待、连接数耗尽；中间件层看线程池满、队列积压。定位方法是"先监控指标、再分段压测、后逐层排除"。
调优手段。 索引优化与慢 SQL 治理、缓存、异步化与消息队列、读写分离、分库分表、连接池与线程池调优、动静分离与 CDN、批量与并行处理、JVM 与 GC 调优。调优的顺序是先找瓶颈再动手，不能盲目加机器。
【真题】2025 年单选题：为了解决银行柜面终端与票据打印机之间速度不匹配的问题，需要设置一个打印缓冲区，逐条、依次将柜面终端的打印需求传递至打印机。该缓冲区的结构应该选择（ ）。A. 栈 B. 队列 C. 二叉树 D. 图。【答案】B。【解析】打印任务按到达顺序"逐条、依次"处理，符合先进先出特性，应选队列；栈是后进先出，树与图用于层次与关系表示。该题以架构中的缓冲/异步思想为背景，实质考数据结构选择。（2025 年卷为考生回忆版、无公开答案页，答案按考点推定）
扩展方式。 垂直扩展（Scale Up）是给单机加 CPU、内存、磁盘，简单但有上限、成本递增；水平扩展（Scale Out）是增加节点，理论无上限，但要求应用无状态或可分片。无状态设计要求会话外置、不依赖本地文件、任意实例可处理任意请求，是水平扩展的前提。
| 发布模式 | 做法 | 优点 | 缺点 |
|---|---|---|---|
| 蓝绿部署 | 准备蓝、绿两套环境，切换流量 | 切换快、回滚快 | 资源翻倍、数据库变更需兼容 |
| 灰度发布（金丝雀） | 先放量给少量用户，观察后逐步扩大 | 风险可控、可快速止损 | 需要流量路由与监控能力 |
| 滚动发布 | 逐批替换实例，新旧版本短暂共存 | 不中断服务、资源占用小 | 发布期间版本不一致，回滚较慢 |
| A/B 测试 | 两组用户使用不同版本，对比业务指标 | 可验证业务效果 | 需要分流与统计支撑 |
DevOps 与 CI/CD。 DevOps 是开发与运维一体化的文化、实践与工具链，目标是缩短交付周期、提高发布质量。CI 持续集成指频繁合并代码并自动构建、自动测试；CD 持续交付指始终具备可发布状态，持续部署指自动发布到生产。流水线通常包括编码、构建、单元测试、代码扫描、打包、部署、自动化测试、监控告警。
【真题】2020 年多选题：以下哪些技术与 DevOps 相关？（ ）A. 自动部署 B. 微服务 C. 容器 D. 自动测试。【答案】ABCD。【解析】DevOps 依赖自动化部署与自动化测试实现快速交付，微服务提供可独立部署的粒度，容器提供一致的环境与快速交付载体，四项均与 DevOps 密切相关。（2020 年卷无公开答案页，答案按考点推定）
架构演进与技术债务。 典型路径是：单体应用 → 垂直分层 → SOA → 微服务 → 云原生。单体适合业务简单、团队小的起步阶段，优点是开发快、事务简单、部署容易；随着规模增长出现耦合高、发布影响大、扩展困难，才需要拆分。技术债务是因赶工期、设计妥协或技术落后而欠下的"未来成本"，管理方法是识别登记、量化影响、纳入迭代偿还，而不是一次性重构。架构评审与架构看板用于在项目关键节点检查架构是否符合原则与目标。
【易错】"微服务一定优于单体"是错误表述，架构要与业务规模、团队能力匹配；蓝绿部署靠"切流量"回滚，灰度靠"按比例放量"控制风险，两者不要混；持续交付不等于持续部署，前者是"随时可发"，后者是"自动就发"。
三、高频考点速查表
| 考点 | 一句话结论/数值 |
|---|---|
| 信息系统五要素 | 硬件、软件、数据、人员、规程 |
| 软件架构三要素 | 构件、连接件、约束 |
| 架构的四大作用 | 沟通语言、承载质量属性、支持复用演化、支持计划估算 |
| 4+1 视图 | 逻辑视图、开发视图、进程视图、物理视图，加场景（用例）视图 |
| 4+1 中的"1" | 场景视图，用用例串联并验证其余四个视图 |
| 逻辑视图与物理视图 | 逻辑视图面向最终用户、看功能与类；物理视图看软硬件映射与部署 |
| TOGAF ADM 阶段 | 预备阶段 + A 至 H 共 8 个正式阶段，需求管理贯穿全程 |
| ADM 的 B、C、D 阶段 | 业务架构、信息系统架构（数据 + 应用）、技术架构 |
| Zachman 框架 | 6 行视角 × 6 列疑问（What/How/Where/Who/When/Why）的分类框架 |
| 六大质量属性 | 性能、可用性、可修改性、安全性、可测试性、易用性 |
| 性能战术 | 资源调度（队列调度）、并发、缓存、减少计算、异步 |
| 架构风格五大类 | 数据流、调用返回、独立构件、虚拟机、仓库 |
| 数据流风格 | 批处理序列、管道-过滤器 |
| 调用返回风格 | 主程序-子程序、面向对象、层次结构 |
| 独立构件风格 | 进程通信、隐式调用（事件驱动） |
| 虚拟机风格 | 解释器、规则系统 |
| 仓库风格 | 数据库系统、黑板、超文本 |
| 规则系统典型场景 | 业务规则频繁变更、由业务人员维护的定价与审批 |
| 黑板风格典型场景 | 无确定算法、多知识源协同（人工智能、信号处理） |
| 三层架构 | 表示层、业务逻辑层、数据访问层 |
| MVC 职责 | 模型=业务数据与逻辑，视图=界面表现，控制器=请求调度 |
| B/S 访问顺序 | 浏览器 → Web 服务器/中间件 → 应用服务器 → 数据库服务器 |
| 企业架构四层 | 业务架构、应用架构、数据架构、技术架构 |
| 应用架构规划三项 | 应用现状、应用要素、应用体系设计 |
| SOA 三要素 | 服务、企业服务总线（ESB）、服务编排 |
| 微服务与 SOA 的区别 | 粒度更细、轻量级通信、独立数据库、独立部署 |
| 微服务核心组件 | 注册中心、配置中心、网关、熔断降级、限流、链路追踪 |
| 中台三类 | 业务中台、数据中台、技术中台 |
| 中间件分类 | 数据库访问、远程过程调用、消息、事务、应用服务器、Web 服务器、缓存 |
| ODBC 与 JDBC | 数据库访问中间件（屏蔽数据库差异） |
| 消息中间件四大作用 | 异步解耦、削峰填谷、最终一致、广播与顺序 |
| 缓存三大问题 | 穿透（布隆过滤器/缓存空值）、击穿（互斥锁/逻辑过期）、雪崩（随机过期/高可用） |
| 四层与七层负载均衡 | 四层看 IP + 端口（LVS/F5），七层看 URL/Header/Cookie（Nginx） |
| 常见负载均衡算法 | 轮询、加权轮询、最少连接、源地址哈希、一致性哈希 |
| 集群三类 | 高可用集群、负载均衡集群、高性能计算集群 |
| CAP 与 BASE | 分区容忍必选，C 与 A 取舍；BASE=基本可用+软状态+最终一致 |
| 分布式事务方案 | 2PC、3PC、TCC、消息最终一致、Saga |
| IaaS/PaaS/SaaS | 云主机、云数据库与容器平台、在线办公软件 |
| 云四种部署形态 | 公有云、私有云、混合云、社区云（行业云） |
| 虚拟化三类实现 | 全虚拟化、半虚拟化、硬件辅助虚拟化 |
| Hypervisor 两类 | Type1 裸金属型（ESXi、Xen、KVM），Type2 宿主型（VirtualBox） |
| 容器与虚拟机 | 共享宿主内核、秒级启动、隔离较弱、镜像 MB 级 |
| Kubernetes 核心对象 | Pod、Deployment、StatefulSet、Service、Ingress、ConfigMap、HPA |
| 可用性公式 | A = MTBF /（MTBF + MTTR）；串联取乘积，并联按冗余计算 |
| 三个九 | 99.9%，年停机约 8.76 小时 |
| 四个九 | 99.99%，年停机约 52.6 分钟 |
| 五个九 | 99.999%，年停机约 5.26 分钟 |
| RTO | 恢复时间目标，业务中断后可容忍的最长恢复时间 |
| RPO | 恢复点目标，可容忍的数据丢失量（以时间计） |
| 灾难恢复能力等级 | GB/T 20988---2007，1---6 级，6 级为数据零丢失与远程集群 |
| 两地三中心 | 生产中心 + 同城灾备中心 + 异地灾备中心 |
| 备份三种方式 | 全量备份、增量备份、差异备份 |
| 冷备、温备、热备 | 冷备需启动、温备需恢复数据、热备实时可接管 |
| 双机双工 | 两台都运行、负载均衡、互为备份（主主模式） |
| 性能测试五类 | 负载测试、压力测试、稳定性测试、并发测试、容量测试 |
| 扩展两种方式 | 垂直扩展（加配置，有上限）、水平扩展（加节点，需无状态） |
| 四种发布模式 | 蓝绿部署、灰度发布、滚动发布、A/B 测试 |
| CI 与 CD | 持续集成（自动构建测试）、持续交付（随时可发）、持续部署（自动发） |
| 架构演进路径 | 单体 → 垂直分层 → SOA → 微服务 → 云原生 |
四、易混辨析
| 辨析组 | 核心区别 | 判断口诀 |
|---|---|---|
| 可靠性 与 可用性 | 可靠性看 MTBF，指连续无故障运行能力；可用性看可服务时间占比，由 MTBF 与 MTTR 共同决定 | 可靠是"不坏"，可用是"能用" |
| RTO 与 RPO | RTO 是恢复业务所需的最长时间（停多久），RPO 是可容忍的数据丢失量（丢多少） | RTO 管时间，RPO 管数据 |
| 双活 与 主备 | 双活两台都对外服务、资源利用率高、RTO 接近 0；主备一台待命、切换有中断 | 双活都干活，主备一闲一忙 |
| 热备/温备/冷备 | 热备实时同步可立即接管；温备设备就绪但需恢复数据；冷备故障后才启动 | 热即接、温需等、冷要启 |
| 全量/增量/差异备份 | 全量备份全部数据；增量备份上次备份以来的变化；差异备份上次全量以来的变化 | 增量叠链、差异对全量 |
| IaaS/PaaS/SaaS | IaaS 用户管操作系统；PaaS 平台管操作系统、用户管应用；SaaS 用户只管用 | 看谁管操作系统 |
| 容器 与 虚拟机 | 容器共享宿主内核、秒级启动、隔离弱；虚拟机含完整客户 OS、分钟级启动、隔离强 | 有没有自己的操作系统 |
| 微服务 与 SOA | 微服务粒度细、轻量通信、独立数据库、独立部署；SOA 粒度粗、依赖 ESB、常共享数据 | 细、轻、自治 对 粗、重、集中 |
| 四层 与 七层负载均衡 | 四层基于 IP + 端口转发，不解析内容；七层解析 URL/Header/Cookie，可内容路由 | 懂不懂内容 |
| 横向扩展 与 纵向扩展 | 横向加节点（需无状态、理论无上限）；纵向加单机配置（有上限、成本陡增） | 加机器 对 加配置 |
| 缓存穿透/击穿/雪崩 | 穿透是查不存在的数据；击穿是一个热点 key 失效；雪崩是一片 key 失效或缓存宕机 | 穿=无、击=一个、雪=一片 |
| 蓝绿 与 灰度 | 蓝绿两套完整环境切流量，回滚快；灰度按比例/人群逐步放量，风险可控 | 蓝绿切环境，灰度切比例 |
| 集群 与 分布式 | 集群是同一服务多份副本、对外透明；分布式是不同服务拆开、协同完成 | 同样的事多人干，不同的事分开干 |
| 中台 与 平台 | 中台沉淀可复用业务能力并服务前台；平台偏技术与资源支撑 | 中台出能力，平台出资源 |
| TOGAF 与 Zachman | TOGAF 是架构开发过程方法（ADM）；Zachman 是架构描述分类框架（6×6 矩阵） | 一个管怎么做，一个管怎么描述 |
| 同城双活 与 两地三中心 | 同城双活是两个中心同时承载业务；两地三中心是"生产 + 同城灾备 + 异地灾备"的完整布局 | 双活是形态，三中心是布局 |
| 消息中间件 与 RPC | 消息是异步、解耦、最终一致；RPC 是同步、远程调用、强时序 | 异步解耦对同步调用 |
| 熔断/限流/降级 | 熔断是下游故障时断开；限流是入口流量超限时拦截；降级是主动牺牲非核心功能 | 断下游、挡入口、舍功能 |
| 架构 与 详细设计 | 架构定构件、连接件、约束与质量属性；详细设计定类、接口、算法 | 架构管骨架，详细设计管内脏 |
| 2PC 与 TCC | 2PC 是数据库层两阶段提交、强一致但阻塞；TCC 是业务层三接口补偿、最终一致 | 一个靠数据库，一个靠业务 |
五、真题精练
【注意】以下 8 题取自 2020---2023 年真题扫描页，题干与选项按原图抄录，个别标点与选项顺序已按图片校正。其中 2022 年的 2 题已与 2022 年卷官方解析逐题核对；2020、2021 年卷无公开答案页，相关题目已在解析末尾标注"答案按考点推定"；2023 年多选（双活数据中心）已核对 2023 年卷官方答案页。所有解析文字为本讲义编写，非官方答案原文。
【单选】（2022 年真题）面向消息中间件通过高效可靠的（ ），在分布式环境下扩展进程间的通信，可支撑多种通信协议、语言、应用程序、硬件和软件平台。
A. 消息扩展机制
B. 消息共享机制
C. 消息传递机制
D. 消息处理机
【答案】C
【解析】面向消息中间件（MOM）以"消息"为通信载体，通过消息的发送、排队、接收这一消息传递机制，实现跨平台、跨语言的异步通信；扩展机制、共享机制、消息处理机都不是其通信本质。（已与 2022 年卷官方解析核对一致：MOM 利用高效可靠的消息传递机制进行平台无关的数据传递，通过提供消息传递和消息队列模型，在分布式环境下扩展进程间通信。）
【单选】（2022 年真题）下列选项中不属于虚拟化主要特征的是（ ）。
A. 高扩展性
B. 高可用性
C. 高安全性
D. 实现技术简单
【答案】D
【解析】虚拟化通过资源池化带来高扩展性，通过迁移、快照、集群带来高可用性，通过隔离带来较好的安全性；但虚拟化层本身实现复杂，涉及指令翻译、设备模拟、资源调度，故"实现技术简单"不属于其主要特征。（已与 2022 年卷官方解析核对一致：虚拟化的主要特征包括封装、独立、隔离、分区、高扩展性、高可用性、高安全性等。）
【单选】（2021 年真题）云计算基础架构的基石是（ ）。
A. 虚拟化
B. 分布式
C. 并行
D. 集中式
【答案】A
【解析】虚拟化把物理资源池化、按需切分，是云计算实现资源弹性与多租户共享的基础，通常被称为云计算基础架构的基石；分布式、并行是计算的组织方式，集中式与云计算的资源池化方向相反。（2021 年卷无公开答案页，答案按考点推定）
【单选】（2020 年真题）以下关于网络存储的叙述，不正确的是（ ）。
A. NAS 设备可有自己的 OS
B. FCSAN 的网络介质为光纤通道
C. IPSAN 使用标准的以太网
D. DAS 支持跨平台文件共享功能
【答案】D
【解析】DAS（直连存储）是存储设备直接连接到服务器，只能被所连主机独占访问，不支持跨平台文件共享；NAS 是文件级共享存储、自带文件系统与操作系统；FC SAN 走光纤通道，IP SAN 走标准以太网（iSCSI），A、B、C 均正确。（2020 年卷无公开答案页，答案按考点推定）
【单选】（2021 年真题）对于提升磁盘 I/O 性能问题，以下表述正确的是（ ）。
A. 数据库对象在物理设备上的合理分布能改善系统读写性能
B. 磁盘镜像可以提高磁盘读写的速度
C. 建议把数据库、回滚段、日志放在同一块设备上，以提高数据读写的性能
D. 将磁盘升级到更大容量可提高磁盘 I/O 速度
【答案】A
【解析】把数据文件、日志文件、临时文件分散到不同物理设备上，可并行 I/O、减少争用，A 正确；磁盘镜像是冗余措施，写操作要写两份，反而降低写性能，B 错；数据库、回滚段、日志放在同一设备会加剧 I/O 争用，C 错；容量与 I/O 速度无直接关系，D 错。（2021 年卷无公开答案页，答案按考点推定）
【单选】（2020 年真题）ITIL（信息技术基础设施库）的最核心模块是（ ）。
A. 业务管理
B. 服务管理
C. 安全管理
D. 基础架构管理
【答案】B
【解析】ITIL 以 IT 服务管理为核心，其主体是服务支持与服务交付两个流程组，其他模块都围绕"如何高质量地提供 IT 服务"展开，故最核心模块是服务管理。（2020 年卷无公开答案页，答案按考点推定）
【多选】（2020 年真题）在分布式数据库架构下，下列哪些方法可以提升系统的可扩展性？
A. 数据复制
B. 数据垂直切分
C. 数据水平划分
D. 缓存
【答案】ABC
【解析】数据复制增加副本以分担读请求、提升可用与扩展能力；垂直切分按列拆分、水平划分按行分片，都能把数据分散到多节点，是从架构层面提升可扩展性的手段。缓存主要提升访问性能、降低数据库压力，不改变数据的分布与扩展能力，故 D 不选。（2020 年卷无公开答案页，答案按考点推定）
【多选】（2020 年真题）以下有关存储区域网络（SAN）的描述中，正确的是（ ）。
A. 采用文件共享存取方式
B. 采用块（block）级别存储
C. 可基于光纤或 IP 网络实现
D. 将存储设备从传统的以太网中分离出来
【答案】BCD
【解析】SAN 提供块级存储访问，可通过光纤通道（FC SAN）或 IP 网络（IP SAN、iSCSI）承载，并把存储流量从业务以太网中独立出来形成专用存储网络，B、C、D 正确；文件级共享存取是 NAS 的特征，A 错。（2020 年卷无公开答案页，答案按考点推定）
六、自测清单
- 信息系统的五个组成部分是硬件、软件、数据、人员和（）？
- 软件架构由构件、连接件和（）三要素构成？
- 架构设计不能替代需求分析，因为"捕获并了解用户需求"属于（）阶段？
- 4+1 视图包括逻辑视图、开发视图、进程视图、物理视图和（）视图？
- 4+1 视图中的"1"指的是（），其作用是串联并验证其余四个视图？
- UML 中最基本的需求分析模型是（）视图？
- TOGAF ADM 由预备阶段和 A 至 H 共（）个正式阶段组成？
- ADM 中 C 阶段对应的是（）架构，包含数据架构与应用架构？
- Zachman 框架是 6 行视角 × 6 列疑问的（）框架，而不是开发过程？
- 六大质量属性是性能、可用性、可修改性、安全性、可测试性和（）？
- "队列调度"属于提升（）属性的设计策略？
- "主动冗余"提升的是（）属性，而不是性能？
- 架构风格五大类为数据流、调用返回、独立构件、（）和仓库？
- 批处理序列与管道-过滤器同属（）风格，但批处理无并发、整体顺序执行？
- 事件驱动（隐式调用）属于（）风格，而不是调用返回风格？
- 规则系统与解释器同属（）风格？
- 业务规则频繁变更、由业务人员维护的场景应选（）架构风格？
- 三层架构的三层分别是表示层、（）层和数据访问层？
- MVC 中负责业务数据和业务逻辑的是（），负责界面表现的是视图？
- 多层 B/S 架构中，浏览器请求依次经过浏览器、（）、应用服务器和数据库服务器？
- 企业架构四层是业务架构、应用架构、（）和技术架构？
- 应用架构规划的三项内容是应用现状、应用要素和（），不包括应用建模？
- SOA 三要素是服务、企业服务总线和（）？
- 与 SOA 相比，微服务的粒度更（）、通信更轻量、数据库独立？
- 微服务中负责"服务在哪里"的组件是（），负责"参数是什么"的是配置中心？
- 缓存穿透的典型对策是布隆过滤器和（），缓存击穿的对策是互斥锁与逻辑过期？
- 四层负载均衡基于 IP 和（）转发，七层负载均衡可解析 URL、Header 和 Cookie？
- 集群解决"同一件事多人干"，分布式解决"（）"？
- CAP 在发生网络分区时只能三选二，实际系统必须在一致性与（）之间取舍？
- 分布式事务中，Try-Confirm-Cancel 简称（）；两阶段提交简称 2PC？
- IaaS 与 PaaS 的分界是"（）由谁管理"？
- 容器与虚拟机最本质的区别是容器共享宿主机的（），不需要完整客户操作系统？
- Kubernetes 中最小的调度单元是（），而不是容器？
- 可用性 = MTBF /（MTBF + MTTR），其中 MTTR 指的是（）？
- 99.9% 的可用性对应年停机约（）小时？
- 99.99% 的可用性对应年停机约（）分钟？
- RTO 指恢复时间目标，衡量"停多久"；RPO 指（），衡量"丢多少数据"？
- GB/T 20988---2007 将灾难恢复能力分为（）级，最高级要求 RPO 为 0？
- 两地三中心由生产中心、同城灾备中心和（）灾备中心构成？
- 增量备份备份的是"上次（）以来的变化"，差异备份备份的是"上次全量以来的变化"？