6.2 信息系统架构、集成与运维（补强）
本篇定位（2026-11-03 补强）：这是第 6 篇原稿最大的覆盖缺口——原书这一块几乎是 0 字，而 9 年真题里"架构 / 集成 / 运维 / 性能 / 容灾"合计每年 8–12 题：2020 单26/28/29/30/32/34/38/多83/多86/多99、2021 单32/37/38/41/多83/多85、2022 单22/27/30/多83、2023 单22/25/27/39/41/42/多82、2024 单29/62/64/多82/多84/多89/多93、2025 单22/23/36/38/多81、2026 单62/多97。这一块的分值高于数据结构与程序设计，必须按"能出单选/多选"的密度补。 数据依据：
01-真题/考点汇总/9 份计算机考点汇总（逐题核过锚点）。 学法：先背"分层与方位"（谁在谁之前/之上），再背"错项"（命题人最爱在"扩展能力差""能捕获需求""增加设计复杂度"这类句子上设错）。
一、C/S 与 B/S 架构
四层结构（方位必背）：
| 架构 | 构成 | 要点 |
|---|---|---|
| 两层 C/S | 客户机 ＋ 数据库服务器 | 业务逻辑分散在客户端或数据库存储过程里 → 难重用、数据库负荷高、改起来难 |
| 三层 C/S | 客户机 ＋ 应用服务器 ＋ 数据库服务器 | 表示层 / 业务逻辑层 / 数据层；逻辑集中、易重用、负荷分担 |
| 三层 B/S | 浏览器 ＋ Web 服务器 ＋ 数据库服务器 | 客户端零部署（瘦客户端） |
| 四层 B/S | 浏览器 → 中间件 → 应用服务器 → 数据库服务器 | 2020 单34 考的就是这个访问顺序；中间件排在应用服务器之前 |
C/S 与 B/S 对照（高频辨析表）：
| 维度 | C/S | B/S |
|---|---|---|
| 客户端 | 胖客户端，逐台安装、升级、维护 | 瘦客户端，零部署，升级只在服务器端 |
| 响应速度 | 本地处理多，快 | 频繁往返请求，慢于 C/S |
| 交互功能 | 易实现拖放、撤销—重复、上下文相关帮助 | 难以实现这些功能 |
| 动态页面/数据库能力 | 强 | 缺乏动态页面支持、无有效数据库处理能力 |
| 扩展与安全 | — | 传统口径：扩展能力差、安全性难控制 |
| 数据提交 | 交互性强，适合频繁大量录入 | 以页面为单位，不利于 OLTP |
判断点（2021 单38 原题）：B/S 的缺点就四句——动态页面支持弱、安全难控制、响应速度低于 C/S、不利于 OLTP。凡写成"远高于 C/S""利于 OLTP""安全性容易控制"的都是错项。 场景题（2020 单26）：手机银行 APP 最接近 C/S（有专用客户端，不是浏览器）。 ⚠️ 口径边界：现代 Web 用多层架构＋缓存＋负载均衡＋容器可以获得很强的服务器端扩展能力，"B/S 扩展差"是传统教材比较客户端功能时的结论，不要绝对化成"所有 B/S 都不能扩展"——但考试按传统口径选。
二、中间件
定义与定位：中间件是工作在操作系统与应用程序之间的一类支撑软件，为分布式应用提供通信、数据访问、事务与运行支撑等公共服务。
作用（2021 多85 的四个选项）：屏蔽底层异构、提高可移植性、提高开发效率、提供特定功能服务。⚠️ "增加设计复杂度"是错项——中间件是降低设计复杂度。
五类中间件（穷举表）：
| 类别 | 代表 | 关键机制 |
|---|---|---|
| RPC 远程过程调用 | RMI、gRPC | 像调本地过程一样调远端（参数编组→传输→远端分派→返回） |
| MOM 面向消息中间件 | RabbitMQ、RocketMQ、Kafka、ActiveMQ | 消息传递 + 消息队列两种模型；异步解耦、削峰填谷（2022 单27） |
| TPM 事务（交易）中间件 | Tuxedo、CICS | 支持数万进程并发、负载均衡、两阶段提交、故障恢复 |
| 数据库访问中间件 | ODBC（Windows）、JDBC（Java）、ADO.NET | 用相同代码访问不同数据库（2025 单22） |
| 分布式对象/构件中间件 | CORBA、EJB、DCOM | 跨语言跨平台的分布式对象调用 |
判断点：ODBC/JDBC 属于数据库访问中间件，不是 RPC；RPC 解决"远程调用"，ODBC/JDBC 解决"连数据库"。 Web 容器：Tomcat、WebLogic 本质是 Web 容器 ＋ 中间件（不是应用软件）。 分类归属：中间件属支撑软件；判断软件类别看主要用途，不能因为部署在银行系统里就归为应用软件。
三、SOA、企业应用集成（EAI）与微服务
三个概念的分工：
- SOA：把应用功能拆成服务，通过定义良好的接口与契约联系起来（重复用、重企业集成、重 ESB 与集中治理）。
- ESB 企业服务总线：异构系统的总线技术，负责协议转换、数据格式转换、路由、消息转换、服务编排——2023 单25：异构系统协议/格式不同 ⇒ 用 ESB（总线）集成。
- 微服务：按业务边界拆成独立部署的服务单元，服务间通过 API（HTTP/REST、gRPC）轻量通信（2020 单30：微服务提倡轻量级通信，粒度不是越细越好）。
Web Service 三要素（2024 单64）：WSDL（描述服务）＋SOAP（消息封装与传输，即服务通信协议标准）＋UDDI（服务注册与发现）。
EAI 的四层（自下而上）：通信层 → 信息传输与转化层 → 应用连接层 → 流程控制层（最高层）。
2026 单62：系统应用集成的最高层 = 流程控制服务。
四类集成（按"集成什么"分）：
| 集成方式 | 解决什么 | 手段 |
|---|---|---|
| 数据集成 | 打通数据孤岛 | 联邦数据库、数据仓库、数据复制、ETL、ESB 数据转换 |
| 应用集成 | 系统之间互相调用 | API、适配器、ESB、消息中间件 |
| 流程（控制）集成 | 协调跨系统流程与业务规则 | BPM、工作流引擎、服务编排——业务逻辑层上的"黑盒集成"属于控制集成（2025 单38） |
| 界面（表示）集成 | 统一入口与界面 | 企业门户、Portlet、SSO（不负责业务逻辑） |
SOA vs 微服务（必背对照）：
| 维度 | SOA | 微服务 |
|---|---|---|
| 拆分粒度 | 较粗（企业级服务） | 细，按业务边界 |
| 通信 | 常经 ESB 集中治理 | 轻量 REST/gRPC，去中心化 |
| 治理 | 集中 | 去中心化 |
| 部署 | 常共享平台 | 可独立构建、发布、回滚、单独扩容 |
| 数据 | 常共享大库 | 数据自治（各服务管自己的库，跨服务用事件/最终一致性） |
四、集群、高可用与容灾
集群三种模式（必背）：
| 模式 | 特征 | 考法 |
|---|---|---|
| 主备（Active-Standby） | 一主一备，主故障切备 | 资源利用率低但简单 |
| 双机双工（Active-Active 同应用） | 两台均活动、跑相同应用、负载均衡 + 互为备份 | 2025 单23 原题 |
| 双活（Active-Active 数据中心级） | 两个中心同时对外服务 | 容灾等级高 |
高可用策略的"是/不是"（2026 多97 原题）：
- ✅ 属于：主从复制（数据复制＋故障切换）、服务发现。
- ❌ 不属于：分布式锁、集中管理。
可靠性 vs 可用性（2023 单27，必背公式）：
- 可靠性看"故障频次"——MTBF（平均无故障时间）越大越可靠；
- 可用性＝MTBF ÷（MTBF＋MTTR）——MTTR（平均修复时间）越短越可用。
- 算例：甲 10 次/年 × 20 min ＝ 200 min/年不可用；乙 2 次/年 × 5 h ＝ 600 min/年不可用 ⇒ 甲可靠性差（故障多）但可用性高（修得快）。
- 结论：故障多 ≠ 可用性低，两个指标方向可以相反——这是命题人最爱的反直觉点。
容灾与业务连续性：
- RTO（恢复时间目标）：允许多久恢复；RPO（恢复点目标）：允许丢多少数据。
- 容灾方案要点（2024 多82）：灾难类型、恢复时间、恢复技术、恢复程度、成本——五要素。
- 金融系统降硬件故障风险的四件套（2020 多99）：系统与数据备份、磁盘阵列、双机热备、服务器集群。
- 灾备选址（2019 单79）：同城/异地、距离与地质条件；与"消防安全选点"区分（后者是同楼层的机房布局问题）。
五、负载均衡、缓存与存储
负载均衡（按层次分，2020 单29）：
| 层次 | 代表 | 依据 | 特点 |
|---|---|---|---|
| 地域级 | DNS 轮询 | 域名解析 | 粗粒度，天然容灾 |
| 四层 | LVS | IP＋端口 | 性能高，转发快 |
| 七层 | Nginx | URL/内容 | 灵活，可做内容路由 |
- 算法：轮询、加权轮询、最少连接、IP Hash、一致性哈希。
- 判断点：负载均衡会增加系统吞吐量——2020 单29 的错项就是"负载均衡并不会增加吞吐量"。
缓存三兄弟（必背区分）：
| 问题 | 场景 | 对策 |
|---|---|---|
| 缓存穿透 | 查不存在的数据，请求直接打到 DB | 布隆过滤器、空值缓存 |
| 缓存击穿 | 热点 key 过期瞬间大量回源 | 互斥锁、永不过期＋异步刷新 |
| 缓存雪崩 | 大批 key 同时过期 | 错开过期时间、多级缓存、限流降级 |
读写分离与分库分表（2020 多83、2024 多93）：
- 适用：读多写少；主库负责写、从库分担读；异步复制有延迟（"刚写完立刻读"要走主库或用会话粘滞）。
- 分库分表：水平/垂直拆分；代价是跨库 JOIN、分布式事务、扩容复杂度。
- 2024 多93 的场景题：短时性能瓶颈 → Nginx 负载均衡、Redis 缓存、读写分离三种都对；换更强的服务器不保证短时解决。
存储三型（2020 单28）：
| 类型 | 连接方式 | 数据单位 | 能否跨平台文件共享 |
|---|---|---|---|
| DAS | 直连（SCSI/SAS） | 块 | 不能（原题错项就说"DAS 支持跨平台文件共享"） |
| NAS | 网络（NFS/CIFS） | 文件级 | 能 |
| SAN | 专用网络（FC/iSCSI） | 块级，高性能 | 需文件系统配合 |
- RAID5 容量 ＝ (n−1) × 单盘容量（2020 单25：3×1T ⇒ 2T；2021 单31：6×500G ⇒ 2.5T）。
六、企业架构与 IT 战略规划
企业架构四域（2021 多83，必背）：
| 架构域 | 关注内容 |
|---|---|
| 业务架构 | 业务流程、组织、能力模型 |
| 数据架构 | 数据模型、存储位置、流转关系 |
| 应用架构 | 应用系统及交互关系 |
| 技术架构 | 服务器/主机、操作系统、平台、中间件、网络等运行环境 |
判断点："信息系统架构"＝应用架构＋数据架构；业务架构、技术架构属于企业架构；架构愿景是规划阶段文档，不算架构组成部分（2021 多83 的完整坑）。
对照 TOGAF 记（2021 多83）：阶段 B＝业务架构、阶段 C＝信息系统架构（数据架构＋应用架构）、阶段 D＝技术架构 ⇒ "信息系统架构"正好是四域里的中间两层：业务在最上、技术在最下。
IT 战略规划四步（2023 单22）：业务分析 → 评估现行系统 → 识别机会 → 选择方案。 四要素（2024 单29）：现状分析、战略分析、差距分析、路径分析。 出发点（2023 单39）：从企业战略出发（不是从技术、不是从部门需求）。 应用架构规划（2022 单22）：应用现状评估、应用要素识别与关系、应用体系结构设计属于规划内容；"应用建模"不属于（属分析设计工作）——这是原题的错项。
两个框架（各记一句）：
- TOGAF：核心是 ADM 架构开发方法（预备 → 架构愿景 → 业务架构 → 信息系统架构 → 技术架构 → 机会与解决方案 → 迁移规划 → 实施治理 → 架构变更管理，需求管理贯穿全程）。
- Zachman：6×6 分类矩阵（What/How/Where/Who/When/Why × 六层视角），是分类框架，不是实施方法。
七、架构风格、三层架构与 MVC
架构风格清单（能认名字＋特征即可）：
| 风格 | 特征 | 考法 |
|---|---|---|
| 管道—过滤器 | 数据流经一串处理单元 | 编译、数据处理 |
| 分层 | 每层只依赖下一层 | 三层架构、协议栈 |
| 仓库（黑板） | 中心数据结构＋多个知识源 | 专家系统、数据库应用 |
| C/S | 请求—响应 | 见第一节 |
| 事件驱动（隐式调用） | 发布/订阅，松耦合 | 消息中间件、GUI |
| 解释器 | 虚拟机上解释执行 | 脚本引擎 |
| 规则系统 | 业务规则可独立配置、不定期更新 | 2021 单32：会员标准不定期更新 ⇒ 规则系统 |
| 面向服务（SOA） | 服务通过契约组合 | 见第三节 |
三层架构 vs MVC（最容易混，必背）：
- 三层架构是部署/逻辑分层：表示层（UI）—业务逻辑层—数据访问层。
- MVC 是表示层内部的职责分离：Model（数据/业务）—View（展示）—Controller（接收请求、调度）。
- 一句话：三层管"分几层"，MVC 管"界面层内部怎么分"；两者可以并存，不是替代关系。
架构设计的价值（2021 单37、2023 多82、2025 多81 连续考）：
- ✅ 满足性能/安全/可维护性等质量要求、帮助利益相关人理解系统结构、有效管理复杂性、降低维护费用、支持项目计划与分工。
- ❌ "良好的架构能更好捕获/帮助表达用户需求"是错项——需求捕获是需求分析阶段的任务，架构设计不承担这个职责。这条连续三年设错，务必记死。
质量属性与 ATAM（2022 多83）：
- 常见质量属性：性能、可用性、安全性、可修改性（ATAM 评估的四项就是它们）。
- 架构视图：逻辑视图、进程视图、开发视图、物理视图 ＋ 场景（4+1 视图）。
八、运维与 IT 服务管理
ITIL（2020 单38）：ITIL 的核心模块是"服务管理"（服务支持＋服务交付）；不是资产管理、不是能力管理。
配置管理（CMDB）：
- 2023 单41：更新服务器 CPU 信息 → 走配置管理流程。
- 2025 单36：配置管理属于运维管理过程（不是开发过程、不是项目管理过程）。
- 配置管理四要素：配置项、基线、变更控制、版本标识（与 6.8 的配置管理呼应）。
运维 / 运营 / 经营（2024 多89）：
- 运维（O&M）：对基础设施与基础软件（系统、网络、数据库）的日常保障；
- 运营：以业务持续为导向，分战略层/战术层，以经营为中心；
- 经营：面向价值与收益。
- 判断句：运维是"保系统活着"、运营是"保业务转起来"、经营是"保收入"。
DevOps（2020 多86）：自动部署、微服务、容器化、自动化测试四者都相关——核心是开发与运维一体化 + 流水线自动化。
云运维（2023 单42）：挑战包括运维对象虚拟化/不可见、责任边界变化、监控工具与技能转型；"设施运维成本更高"是错项——上云恰好降低了设施成本。
性能指标（2021 多84、2024 多84）：
- 属于性能需求：响应时间、吞吐量、资源利用率、最大并发连接数、并发用户数。
- 不属于：日志保存期限（那是合规/运维要求，不是性能）。
提升性能的手段与边界（2020 单32、2024 多93）：
- 有效：队列调度/异步化、负载均衡、缓存、读写分离、索引优化、分库分表；
- 不能保证：单纯"换更强的服务器"（受软件瓶颈制约）。
九、本章自测（5 题，教材口径）
- 四层 B/S 架构的访问顺序是（口径已核）→ 中间件 → 应用服务器 → 数据库服务器。A. 浏览器
- 关于中间件，下列说法错误的是（口径已核）。A. 提高可移植性 B. 提高开发效率 C. 增加设计复杂度 D. 提供公共服务 → C
- 两台服务器都运行相同应用、负载均衡且互为备份，这种集群模式是（口径已核）。A. 主备 B. 双机双工 C. 冷备 D. 双活数据中心 → B
- 某系统年故障 10 次、每次修复 20 分钟；另一系统年故障 2 次、每次修复 5 小时。则前者（口径已核）。A. 可靠性与可用性都高 B. 可靠性差、可用性高 C. 可靠性高、可用性差 D. 都低 → B
- 关于软件架构，下列说法错误的是（口径已核）。A. 帮助干系人理解系统结构 B. 支持满足性能与可维护性 C. 能更好捕获并表达用户需求 D. 有效管理复杂性 → C
十、本章小结
- 一条主线：分层方位（C/S·B/S 四层）→ 中间件五类 → 集成分层（EAI 四层/四类集成）→ 高可用（集群/负载/缓存/容灾）→ 企业架构与战略（四域/四步）→ 风格与视图 → 运维（ITIL/配置/性能）。
- 必背判断句：B/S 缺点四句；中间件不增加复杂度；架构不捕获需求；负载均衡增加吞吐量；DAS 不跨平台共享；云运维成本更低；日志期限不是性能指标。
- 必背公式：RAID5＝(n−1)×单盘；可用性＝MTBF/(MTBF＋MTTR)。
- 衔接：本章与 2.1（存储/RAID）、4.5（事务/两阶段提交）、5.5（负载均衡设备）、6.8 配置管理/6.9 DevOps、8.2（云服务模型）互引。