第 11 周｜主打科目：综合知识 + 案例分析｜对应知识域：企业信息化、新技术、计算机网络与分布式系统｜主打基本问题：Q2 + Q3（在没有唯一最优解的世界里，新技术选型怎么被论证？数据的一致性该在什么时候让位于可用性？）｜本阶段产出：集成方案 + 新技术选型论证
项目宪法见 00-课程总纲.md；企业信息化占 6–9%、新技术占 6–9%、网络与分布式占 7–9%，合计约 20 分，且论文”新技术及其应用””企业信息化”两个方向直接依赖本周素材，见 02-考点地图.md。
一、情境开场（Hook）
评审会上，设备部负责人提了一个让全场安静的请求：**”能不能用区块链做质量追溯？我在展会上看过，说是’不可篡改、可追溯’，正好解决我们跟整车厂的信任问题。”**
生产部立刻反对：”采集数据每秒几万条，链上扛得住吗？别到时候追溯报告半天出不来。”质量部补刀：”就算上了链，设备传上来的数本来就是错的，链能保证它真吗？“
CIO 转向你。你知道这三句话里，每一句都对，而且互相冲突：
- 设备部的需求是真实的——整车厂确实要求可验证的质量凭证；
- 生产部的担心是真实的——公有链 TPS 只有几十，采集数据上链一定崩；
- 质量部的质疑更是致命的——区块链保证的是”上链之后改不了“，保证不了”上链之前是真的“。如果采集端可以被人为改动，链只会让假数据变得更可信。
你真正要回答的不是”用不用区块链”，而是三个更一般的问题：一项新技术凭什么被选中？它解决的是哪个具体的质量属性？它牺牲了什么，由谁承担代价？
这正是 S06 的那个问题（Q2：怎么证明一个架构是好的）在新技术语境下的重演，也是 S05 那个问题（Q3：什么时候该为性能打破规范）在分布式环境下的升级版。本周把这两个问题一起收。
二、为什么学这一周（Where & Why）
- 企业信息化（BPR、ERP/MES、SCM、CRM、PLM、电子政务）：综合知识 4–6 题，几乎全是名词与缩写的对应辨析，纯记忆送分。
- 企业应用集成 EAI 四层次：综合知识 1–2 题 + 案例”系统集成分层与设计”约 8–10 分；数据集成 / 应用集成 / 流程集成 / 界面集成的区分是固定套路。
- 数据仓库与商务智能：综合知识 2–3 题；OLTP vs OLAP、星型 vs 雪花模型、ETL、Inmon 四特征是必考组合。
- 新技术谱系：综合知识 5–7 题（年年考），集中在云计算服务模型与部署模型、Hadoop 生态组件对应、IoT 三层架构、AI 分支归类、区块链共识机制。
- 分布式系统基础：综合知识 2–4 题 + 案例（常嵌入 Web/微服务题）；CAP 与 BASE 的取舍、缓存穿透/击穿/雪崩、分布式事务方案选择是近年高频。
- 论文：本周是**”新技术及其应用””企业信息系统””应用系统集成”三个方向的共同素材来源，没有具体落地数字就千万别选这些题**（呼应
02-考点地图.md的选题原则）。 - 不学的代价：新技术题是”见过就会、没见过就全靠猜”的典型，是拉开 45 分与 60 分差距的分水岭。
三、核心讲义（Equip）
3.1 企业信息化：战略、BPR 与主流系统
定义：企业信息化指企业利用现代信息技术，通过对信息资源的深度开发与广泛利用，提高生产、经营、管理、决策的效率与水平。信息化战略规划（ISP）的三种主流方法：BSP（企业系统规划法）（企业目标 → 企业过程 → 数据类 → 信息系统结构，自顶向下规划、自底向上实现）、SST（战略集合转移法）、CSF（关键成功因素法）。
业务流程重组（Business Process Reengineering, BPR）：根本性（Fundamental）、彻底性（Radical）、戏剧性（Dramatic）、流程导向（Process）——Hammer 四要素。与业务流程改进（BPI）的区别（高频考点）：
| 维度 | BPR 业务流程重组 | BPI 业务流程改进 |
|---|---|---|
| 幅度 | 根本性再思考、彻底再设计 | 渐进式、局部优化 |
| 出发点 | 抛开现有流程，从”应该怎么做”倒推 | 在现有框架内消除浪费 |
| 效果 | 追求戏剧性改善（成倍） | 追求持续改善（百分比级） |
| 风险 | 高（组织阵痛大、失败率高） | 低 |
| 本项目 | 一期不做 BPR，只做 BPI（先跑通，二期再谈重组） | 优化报工与检验流转 |
BPR 四阶段：项目启动与规划 → 流程诊断（描述与分析现有流程）→ 流程再设计 → 实施与持续改进。
本项目立场（论文可用）：**”先固化、后优化、再重组”——在一个数据孤岛严重、连准确数据都拿不到的企业里直接推 BPR，等于在流沙上盖楼。** 一期先把流程搬到线上并采集到可信数据（BPI），二期有了数据基础再谈 BPR。这是一条能写进论文的、有立场的判断。
主流企业信息系统：
| 系统 | 全称与核心思想 | 关键概念 | 与本项目关系 |
|---|---|---|---|
| ERP | 企业资源计划；核心思想是供应链管理 + 事前计划与事中控制 | MPS 主生产计划 → MRP 物料需求计划 → CRP 能力需求计划；MRP 输入 = MPS + BOM 物料清单 + 库存信息 | 计划层：向 MES 下生产订单，接收报工/入库/消耗实绩 |
| MES | 制造执行系统 | 工单执行、报工、质检、设备数据采集、追溯 | 执行层：本项目要建的系统 |
| SCM | 供应链管理 | 物流、信息流、资金流三流合一；牛鞭效应（需求信息沿供应链逐级放大） | 供应商来料批次信息是追溯起点 |
| CRM | 客户关系管理 | 客户获取、保持、增值；操作型 / 分析型 / 协作型 CRM | 客户投诉 → 反查追溯链条 |
| PLM / PDM | 产品全生命周期管理 / 产品数据管理 | BOM 多视图、版本与变更管理、工艺路线 | 提供 BOM 与工艺路线主数据 |
| 电子商务 | — | B2B / B2C / C2C / O2O | — |
| 电子政务 | — | G2G（政府对政府）、G2B（政府对企业）、G2C（政府对公民）、G2E（政府对公务员） | 与质量监管平台对接属 G2B |
ERP 与 MES 的集成关系（案例常考）：ERP 管”计划层”（生产什么、什么时候生产、需要多少物料），MES 管”执行层”（怎么生产、实际生产了多少、质量如何）。 集成方向是双向的：ERP → MES 下发生产订单与物料主数据；MES → ERP 回报工单实绩、报工、物料消耗、入库、检验结果。本项目一期集成的第一优先级就是这两条数据流。
3.2 企业应用集成 EAI 与数据仓库 / 商务智能
定义：企业应用集成（Enterprise Application Integration, EAI）解决”已有异构系统如何协同”的问题。四个层次由浅入深：
| 层次 | 做法与典型技术 | 解决什么 | 代价 / 局限 |
|---|---|---|---|
| 数据集成 | 数据复制、ETL、共享数据库、联邦数据库、数据仓库 | 让 A 系统能读到 B 的数据（数据可流动） | 最简单，但不解决业务语义差异；易形成新的孤岛副本 |
| 应用集成 / API 集成 | 接口调用、ESB 企业服务总线、API 网关、消息中间件 | 让 A 系统能触发 B 的功能（功能可互调） | 需定义清晰的接口契约；点对点集成会形成蜘蛛网 |
| 业务流程集成 | BPM / BPEL、流程编排引擎 | 跨系统端到端流程自动流转（流程可贯通） | 最高层次，要求各系统暴露可编排的服务 |
| 界面集成 / 表示层集成 | 企业门户、单点登录 SSO、统一待办 | 用户在一个入口看到所有系统（界面可统一） | 最表面，底层仍是孤岛 |
- ESB 企业服务总线：提供服务注册、路由、协议转换、消息格式转换、编排，是应用集成的中心化载体。与 API 网关的区别：ESB 偏企业内部、重量级、强调异构协议与格式转换；API 网关偏对外暴露、轻量级、强调认证、限流、监控、灰度。
- 消息中间件（Message Queue, MQ）的四大价值：削峰、解耦、异步、可靠投递（详见 3.4）。
数据仓库与商务智能：
- Inmon 定义的数据仓库四特征：面向主题、集成的、非易失（不可更新）、随时间变化（时变）。
- OLTP vs OLAP（必考配对）：
| 维度 | OLTP（联机事务处理） | OLAP（联机分析处理） |
|---|---|---|
| 用途 | 支撑日常业务操作 | 支撑管理决策分析 |
| 操作 | 增删改查频繁，小事务、高并发 | 查询为主，大批量扫描 |
| 数据 | 当前的、细节的、可更新 | 历史的、综合的、不可更新 |
| 模型 | 规范化（3NF） | 反规范化（星型/雪花）——呼应 S05 的 Q3 |
| 响应时间 | 毫秒级 | 秒级到分钟级 |
- ETL：抽取 Extract → 转换 Transform（清洗、转换、集成）→ 加载 Load。
- 星型模型 vs 雪花模型：星型＝事实表 + 维度表直接相连，维度表反规范化（查询快、冗余多）；雪花＝维度表再规范化成多层（冗余少、JOIN 多、查询慢）。数据仓库常用星型（以冗余换查询性能，这正是 S05 反范式思想在分析型场景的应用）。
- 数据集市（Data Mart）：面向特定部门或主题的数据仓库子集。建设顺序之争：Inmon 主张”自顶向下先建数据仓库再建数据集市“，Kimball 主张”自底向上先建数据集市再集成“。
- 数据中台 vs 业务中台：数据中台＝数据资产化 + 数据服务化（统一数据标准 OneData、统一数据服务 OneService），解决”同一指标在不同系统里数值不同“；业务中台＝通用业务能力（用户中心、订单中心）的复用。警惕：”为建中台而建中台”——中台的前提是存在多个前台业务复用同一能力，单业务线强上中台只会增加一层耦合。
3.3 新技术谱系（综合知识年年 5–7 题）
3.3.1 云计算
| 维度 | 三种服务模型 / 四种部署模型 |
|---|---|
| 服务模型 | IaaS 基础设施即服务（虚拟机、存储、网络，用户管 OS 及以上）；PaaS 平台即服务（运行时、数据库、中间件，用户只管应用与数据）；SaaS 软件即服务（直接用应用，用户只管用） |
| 部署模型 | 公有云（多租户、按需付费、成本低、可控性弱）；私有云（专属、可控性强、成本高）；混合云（敏感数据本地 + 弹性算力上云，本项目最契合）；社区云（特定行业社群共享） |
| 关键技术 | 虚拟化 → 容器（Docker）→ 容器编排（Kubernetes, K8s）→ 服务网格（Service Mesh，如 Istio，把熔断/限流/链路追踪下沉到基础设施）→ Serverless / 函数计算（FaaS，按调用计费，无需管服务器） |
| 云原生 | 容器化 + 微服务 + DevOps + 持续交付 + 声明式 API |
| 责任共担模型 | 云服务商负责”云本身的安全”（物理、主机、虚拟化层），客户负责”云中的安全”（操作系统补丁、应用、数据、身份与访问管理）——这是云安全题的标准答案 |
3.3.2 大数据
- 5V 特征：Volume 体量大、Velocity 速度快、Variety 类型多、Value 价值密度低、Veracity 真实性。
- Hadoop 生态组件对应（必考）：
| 组件 | 作用 |
|---|---|
| HDFS | 分布式文件系统，分块存储 + 多副本，适合大文件顺序读、不适合低时延随机写与小文件 |
| MapReduce | 分布式批处理计算框架（Map 映射 → Shuffle → Reduce 归约），高吞吐、高时延 |
| YARN | 资源管理与作业调度（Hadoop 2.0 引入，解耦计算与资源） |
| Hive | 把 SQL 翻译成 MapReduce/Spark 任务，数据仓库工具，适合离线分析 |
| HBase | 基于 HDFS 的列族式 NoSQL，适合海量数据的随机实时读写 |
| Spark | 基于内存的计算引擎，批处理比 MapReduce 快数倍，支持 SQL / 流处理 / 机器学习 |
| Flink | 真正的流式计算（事件驱动、低延迟、Exactly-Once 语义），流批一体 |
- 批处理 vs 流处理：批处理（高吞吐、T+1 延迟，适合报表、对账、模型训练）；流处理（低延迟、秒级/毫秒级，适合实时监控、告警、实时看板）。
- Lambda 架构 vs Kappa 架构：Lambda＝批处理层（保准确）+ 速度层（保实时）+ 服务层（合并结果），缺点是同一逻辑要写两套代码、维护成本高；Kappa＝全部走流处理，历史数据通过消息重放重算，缺点是对消息队列的存储能力与重放性能要求高。本项目取值示例：实时看板走 Flink（秒级），追溯报告与质量分析走 Spark 离线（T+1），采用 Lambda 的简化版，且明确”两套代码的口径必须统一”这一治理要求。
- 数据治理：元数据管理、主数据管理（MDM）、数据标准、数据血缘、数据质量（六维度：准确性、完整性、一致性、及时性、唯一性、有效性）。**”同一个’合格率’在生产部和质量部算出两个值”就是典型的缺主数据与缺数据标准。**
3.3.3 物联网 IoT（直接对应本项目场景）
- 三层架构：感知层（传感器、RFID、摄像头、PLC、工业仪表——采集物理世界数据）→ 网络层（5G、NB-IoT、LoRa、工业以太网、Wi-Fi——传输）→ 应用层（数据处理、分析、可视化、控制）。
- 典型协议：MQTT（轻量、发布/订阅、适合低带宽不稳定网络，工业采集首选）、CoAP（受限设备）、OPC UA（工业互操作标准，跨平台、带安全模型）、Modbus（工业现场总线，简单但无安全机制）。
- 边缘计算：在靠近数据源的网络边缘侧完成数据处理，价值是降低时延、节省带宽、保障断网可用性、本地数据不出厂区。
- IIoT 工业物联网：本项目落点——边缘网关 + OPC UA/Modbus 采集 + MQTT 上行 + 断点续传，380 台无标准接口设备通过协议逆向 + 边缘适配 + 传感器外挂三条路接入（呼应 S09 的 R-01 风险）。
3.3.4 人工智能与机器学习
| 分支 | 含义 | 典型任务 | 本项目落点 |
|---|---|---|---|
| 监督学习 | 用带标签数据训练 | 分类（合格/不合格判定）、回归（预测设备剩余寿命） | SPC 判异、质量预测 |
| 无监督学习 | 无标签，发现内在结构 | 聚类（缺陷模式分群）、降维、异常检测 | 异常工况发现 |
| 半监督 / 自监督 | 少量标签 + 大量无标签 | 预训练 | 缺陷样本稀缺时 |
| 强化学习 | 智能体与环境交互、奖励最大化 | 排产优化、参数寻优 | 工艺参数推荐 |
- 深度学习典型网络：CNN 卷积神经网络（图像，用于外观缺陷检测）、RNN / LSTM（序列，用于时序预测）、Transformer（自注意力，大模型基础）、GAN 生成对抗网络（数据增强、样本生成）。
- 大模型与 AIGC：预训练 → 有监督微调 SFT → 人类反馈强化学习 RLHF；应用范式 Prompt 提示工程、RAG 检索增强生成（外挂知识库缓解幻觉）、Agent 智能体。落地风险：幻觉、数据泄露、推理成本、可解释性不足。
- 知识图谱：实体—关系—实体三元组构成的语义网络，适合表达”批次—工单—设备—供应商—检验项“这类多跳追溯关系，支持关联推理（”这批钢还用在了哪几个批次”）。
- MLOps：把 DevOps 引入机器学习，覆盖数据流水线 → 特征工程 → 训练 → 评估 → 部署 → 监控 → 再训练的闭环，解决”模型上线即退化“。
3.3.5 区块链（对应质量追溯场景）
- 核心机制：分布式账本（多节点各存全量副本）+ 链式结构 + 哈希指针（改任一区块后续全部失效）+ 共识机制 + 智能合约（自动执行的链上程序）。
- 共识机制：PoW 工作量证明（算力竞赛，公有链，能耗高、TPS 低）、PoS 权益证明（按持币量与时长，节能）、PBFT 实用拜占庭容错（多轮投票，可容忍不超过 1/3 的恶意节点，联盟链首选，TPS 高、无挖矿）、Raft（非拜占庭容错，用于可信环境如 etcd）。
- 链的三种形态：公有链（完全去中心、任何人可读写、性能最低）、联盟链（多组织共同维护、准入控制、企业级应用主流）、私有链（单组织、接近传统数据库）。
- 局限（论文必须写，也是本项目的关键判断）：① 性能低（PoW 每秒几十笔，无法承载高频采集）；② 存储成本高（全量副本，不适合存原始采集数据）；③ 隐私（链上数据对参与方可见）；④ 最致命的一条——“存证上链 ≠ 数据真实”：区块链只能保证上链之后不可篡改，无法保证上链之前的数据是真实采集的。若采集端可被人为修改，链只会让假数据变得更可信。
- 本项目的可取方案：联盟链 + 仅上链关键节点的哈希值（不存原始数据），配合采集端签名（SM2）+ 边缘网关可信环境 + 采集链路视频/日志留痕，形成”链上验真 + 链下存证 + 采集端可信“的组合。被否决方案与理由：全量上链（性能与成本不可行）、不上链（整车厂与监管不认可可验证性）。
3.3.6 其他新技术
- 数字孪生（Digital Twin）：物理实体的数字化镜像，通过实时数据驱动实现状态映射、仿真推演、预测性维护；本项目可用于产线仿真与产能推演。
- 5G 三大场景：eMBB 增强移动宽带（高清视频）、uRLLC 超可靠低时延通信（工业控制、远程操控）、mMTC 海量机器通信（海量传感器接入）。边缘计算常与 5G 配合，把算力下沉到基站侧。
- 工业互联网：网络、平台、安全三大体系；平台层即工业 PaaS（设备接入、数据治理、工业模型、应用开发）。
3.4 分布式系统基础（呼应 Q3：一致性与冗余的取舍）
定义与 CAP 定理：CAP 定理指出分布式系统无法同时满足 C 一致性（Consistency，所有节点同一时刻看到相同数据）、A 可用性（Availability，每次请求都能得到非错误响应）、P 分区容错性（Partition tolerance，网络分区时系统仍能运行）三者。关键结论：分布式系统必然面临网络分区，P 必须保，因此实际是 CP 与 AP 的取舍。
| 选择 | 含义 | 典型系统 | 本项目场景 |
|---|---|---|---|
| CP | 分区发生时拒绝部分请求以保证数据一致 | ZooKeeper、etcd、分布式锁、账务系统 | 追溯报告生成与签发（宁可慢、不可错） |
| AP | 分区发生时继续响应，但各节点数据可能不一致，事后收敛 | DNS、多数 Web 系统、社交动态 | 生产实时看板（宁可数据晚几秒，不可白屏） |
两个常考的补充点：① 没有发生分区时，C 与 A 可以同时满足，CAP 讨论的是”分区发生时”的取舍；② CAP 中的 C 指强一致（线性一致性），放弃强一致不等于放弃正确性。
BASE 理论（对 AP 的延伸）：基本可用 Basically Available（允许损失部分可用性，如降级、延长响应）、软状态 Soft state（允许中间状态存在）、最终一致性 Eventually consistent（经过一段时间后数据自动收敛一致）。
一致性模型（由强到弱）：强一致（线性一致）→ 顺序一致 → 因果一致 → 会话一致（读写一致）→ 最终一致（弱一致的一种）。
分布式事务方案：
| 方案 | 机制 | 优点 | 缺点 | 本项目适用 |
|---|---|---|---|---|
| 2PC 两阶段提交 | 准备阶段 + 提交阶段，协调者统一裁决 | 强一致、简单 | 同步阻塞、协调者单点故障、提交阶段失败可能不一致 | 少用 |
| 3PC 三阶段 | CanCommit + PreCommit + DoCommit，引入超时 | 减少阻塞 | 仍可能不一致，实现复杂 | 少用 |
| TCC | Try 预留资源 / Confirm 确认 / Cancel 释放 | 强一致、性能好（无长事务锁） | 业务侵入强，每个操作都要写三段 | 入库/出库 |
| Saga | 长事务拆为多个本地事务，失败时反向补偿 | 无锁、适合长流程 | 无隔离性（可能脏读），补偿逻辑复杂 | 跨系统的不合格品处置流程 |
| 本地消息表 / 可靠消息最终一致 | 本地事务 + 消息表 + MQ，消费端幂等 | 简单、性能好、最终一致 | 只保证最终一致 | 本项目首选：采集数据入库 → 通知追溯索引更新 |
| 最大努力通知 | 尽力投递 + 定期校对 | 最简单 | 一致性最弱 | 对账、外部通知 |
分库分表与读写分离：垂直拆分（按业务域拆库）/ 水平拆分（按分片键拆表，取模、范围、一致性哈希）。带来的问题：跨库 JOIN、跨库分页排序、分布式事务、扩容迁移。读写分离（主库写、从库读）的代价是主从延迟导致的读不到刚写的数据（解决方案：写后读主、延迟监控、一致性哈希路由）。
分布式 ID：雪花算法 Snowflake（64 位 = 1 位符号 + 41 位时间戳 + 10 位机器 ID + 12 位序列号，趋势递增、本地生成、无中心依赖）；对比 UUID（无序、索引性能差）与数据库号段（有中心依赖）。
缓存三大问题与对策（高频）：
| 问题 | 场景 | 对策 |
|---|---|---|
| 缓存穿透 | 查询根本不存在的数据，缓存永远不命中，直击 DB | 布隆过滤器、缓存空值（短期）、参数校验 |
| 缓存击穿 | 单个热点 key 过期瞬间，大量并发直击 DB | 互斥锁/单飞、逻辑过期（不设 TTL，后台异步刷新）、热点 key 永不过期 |
| 缓存雪崩 | 大批 key 同时过期或缓存集群宕机 | TTL 加随机抖动、多级缓存、熔断限流降级、Redis 集群高可用（哨兵/Cluster） |
更新策略：Cache Aside（旁路缓存）——读时先读缓存、未命中读 DB 再写回缓存；写时先更新 DB、再删除缓存（不是更新缓存，避免并发写导致脏数据）。
消息队列的可靠性要点：生产端确认（Confirm）+ 消息持久化 + 消费端手动 ACK 保证至少一次投递；幂等消费（业务唯一 ID + 去重表 / 数据库唯一索引 / Redis SETNX）应对重复投递；顺序消息（单分区内有序）；死信队列处理反复失败的消息。MQ 的四大价值：削峰（缓冲突发流量）、解耦（生产消费双方不感知）、异步（提升响应）、可靠投递。
3.5 新技术选型论证（正面回答 Q2）
论证方法（复用 S06 的 ADR 与 ATAM）——面对任何一项新技术，按五问走完，答案就是一份合格的 ADR：
- 它解决哪个具体的质量属性场景？（写不出场景，就是伪需求——设备部的”区块链追溯”必须先翻译成”追溯凭证可被第三方独立验证，验证时延 ≤ 2 秒“）
- 不引入行不行？有没有更便宜的替代？（数字签名 + 时间戳服务 + 集中审计，往往已能满足 80% 需求）
- 有几个候选方案，各自牺牲了什么？（全量上链 vs 仅存哈希 vs 不上链——牺牲的是性能、成本、可信度中的哪一项）
- 代价由谁承担？（性能损耗由生产部承担，成本由设备部承担，合规风险由质量部承担——**必须写清”谁买单”**）
- 什么信号出现时该推翻这个决定？（如”追溯查询 P99 时延 > 3 秒””联盟链节点运维成本 > 15 万/年””整车厂不再认可链上凭证”）
本项目的最终 ADR 摘要（可直接用作论文素材）：决策——采用联盟链（PBFT 共识）存储追溯关键节点的 SM3 哈希，原始数据存于本地时序库与对象存储。被否决方案及理由：① 全量上链——PoW 类方案 TPS 仅数十，无法承载每秒万级采集点，且存储成本呈副本数倍增长；② 不上链——整车厂与监管方要求可独立验证的质量凭证，中心化数据库无法提供第三方验证能力。风险与触发重构的信号：链上查询 P99 > 2 秒则改为异步验证 + 本地缓存哈希；年运维成本 > 15 万则退化为”数字签名 + 可信时间戳”方案。
四、典型考法
4.1 综合知识怎么考
题 1：ERP 系统中，由主生产计划、物料清单与库存信息共同驱动，计算出自制件与外购件需求数量与需求时间的子系统是（ ）。 A. MPS B. MRP C. CRP D. BOM
答案：B。解析：MRP 物料需求计划的三项输入正是 MPS 主生产计划 + BOM 物料清单 + 库存信息，输出自制件的生产计划与外购件的采购计划。MPS 是”生产什么、什么时间”的排产；CRP 能力需求计划校验产能是否够；BOM 是物料清单本身，不是子系统。
题 2：关于 OLTP 与 OLAP，下列说法错误的是（ ）。 A. OLTP 面向日常业务操作，OLAP 面向管理决策分析 B. OLTP 数据可更新，OLAP 数据一般不更新 C. OLTP 常采用反规范化的星型模型 D. OLAP 查询以大批量扫描为主
答案：C。解析：采用星型/雪花等反规范化模型的是 OLAP（以冗余换查询性能）；OLTP 为减少冗余与更新异常而采用规范化（3NF）设计——这正是 S05 的 Q3 在不同场景下的两种答案。
题 3：Hadoop 生态中，负责资源管理与作业调度、并将计算框架与资源管理解耦的组件是（ ）。 A. HDFS B. MapReduce C. YARN D. HBase
答案：C。解析：HDFS 分布式存储；MapReduce 批处理计算；YARN 资源管理与调度（Hadoop 2.0 引入）；Hive 数据仓库 SQL；HBase 列族 NoSQL（随机实时读写）；Spark 内存计算；Flink 流式计算。
题 4：关于 CAP 定理，下列说法正确的是（ ）。 A. 分布式系统可以同时满足一致性、可用性、分区容错性 B. 分区容错性必须保证，因此实际是在一致性与可用性之间取舍 C. 选择 AP 意味着放弃正确性 D. 没有发生网络分区时也必须放弃一致性
答案：B。解析：分布式系统必然面临网络分区，P 必须保，故实为 CP 与 AP 的取舍（A 错）；选择 AP 放弃的是强一致，不是正确性，系统仍可通过 BASE 达到最终一致（C 错）；无分区时 C 与 A 可同时满足（D 错）。
题 5：关于缓存三大问题，应对”单个热点 key 过期瞬间引发大量并发请求直击数据库“的措施是（ ）。 A. 布隆过滤器 B. 缓存空值 C. TTL 加随机抖动 D. 互斥锁（单飞）或逻辑过期
答案：D。解析：热点 key 过期 = 缓存击穿 → 互斥锁/单飞重建 或 逻辑过期（不设 TTL，后台异步刷新）。布隆过滤器与缓存空值应对的是穿透（查不存在的数据）；TTL 随机抖动与多级缓存、熔断降级应对的是雪崩（大批 key 同时过期或集群宕机）。
4.2 案例分析怎么考
【案例题】（共 25 分）
承接本项目。系统需集成的对象包括：3 个厂区共 1200 台设备（其中 380 台无标准接口）、运行 12 年的 C/S 架构老 MES、新建的一体化系统、ERP、以及质量监管平台。业务诉求为：
- 生产实时监控：设备状态与关键工艺参数秒级刷新，允许数据晚几秒，但看板不能白屏；
- 质量追溯报告：按批次号查询完整追溯链条（含原材料供应商、工序、检验值、设备参数、班组），响应 ≤ 3 秒，报告必须准确、可作为法律凭证；
- 历史数据分析：支撑质量分析与客户对账，T+1 出结果即可；
- 采集数据峰值约 3 万点/秒，且老 MES 历史数据存在大量缺失与口径不一致。
【问题 1】（8 分） 说明企业应用集成的四个层次及其适用场景与代价，并为本项目选择集成策略、说明理由。
【问题 2】（9 分） 设计数据采集与分析平台的技术方案：给出分层架构，说明批处理与流处理的分工与组件选型，并针对 380 台无标准接口设备给出采集方案。
【问题 3】（8 分） 实时监控与追溯报告对数据一致性的要求不同。说明 CAP 定理的含义，分析两个场景分别该如何取舍，并给出一致性实现方案（含分布式事务方案选择与理由）。
采分点拆解
| 问题 | 采分点 | 分值 |
|---|---|---|
| 问题 1 | 四个层次名称与做法正确 | 4 |
| 各层的适用场景与代价/局限 | 2 | |
| 本项目的集成策略与理由（分层组合，不是单选一层） | 2 | |
| 问题 2 | 分层架构完整（采集 → 传输 → 存储 → 计算 → 服务） | 3 |
| 批处理与流处理分工正确并选定组件（Flink / Spark） | 3 | |
| 无标准接口设备的采集方案（≥2 条具体路径） | 3 | |
| 问题 3 | CAP 定理含义表述准确（P 必须保，实为 CP/AP 取舍） | 2 |
| 两场景取舍判断正确（看板 AP、报告 CP） | 3 | |
| 一致性实现方案（分布式事务选型 + 幂等 + 理由） | 3 |
标准作答范例
【问题 1】 ① 四个层次（由浅入深）：数据集成——通过数据复制、ETL、共享数据库或联邦数据库让系统间数据可流动，最简单但不解决业务语义差异；应用集成（API 集成）——通过接口调用、ESB 企业服务总线、API 网关让系统间功能可互调，需定义清晰的接口契约，点对点集成易形成蜘蛛网；业务流程集成——通过 BPM/BPEL 实现跨系统端到端流程编排，是最高层次，要求各系统暴露可编排的服务；界面集成——通过企业门户与 SSO 实现统一入口，最表面，底层仍是孤岛。
② 本项目的集成策略（分层组合，不是单选一层）：一期以”数据集成 + 应用集成”为主，二期再上”流程集成”，界面集成本期只做 SSO。 具体为：与 ERP 之间采用应用集成（API 网关 + 消息中间件），双向同步生产订单与工单实绩、入库与消耗；与老 MES 之间采用数据集成（ETL 抽取历史数据 + 只读视图），因为老系统无接口、不能改造；与质量监管平台采用应用集成（REST + 双向证书的身份认证）；对最终用户采用界面集成（统一门户 + SSO）。理由：老 MES 不具备服务化能力，强行做流程集成会失败；先保证数据与功能可达，流程贯通留待二期老 MES 下线后统一规划——这符合”先固化、后优化、再重组”的推进节奏。
【问题 2】 ① 分层架构（五层）：采集层 → 传输层 → 存储层 → 计算层 → 服务层。
- 采集层：厂区部署边缘网关，标准接口设备走 OPC UA / Modbus，非标准设备走协议逆向适配（见③）；网关负责协议转换、数据清洗、本地缓存与断点续传，保证网络中断时数据不丢。
- 传输层：MQTT 上行到 Kafka 消息队列，承担削峰（3 万点/秒峰值）、解耦（采集与消费双方不感知）与可靠投递（生产端 Confirm + 持久化 + 消费端手动 ACK）。
- 存储层：时序数据库（如 InfluxDB/TDengine）存高频采集点；关系库（分库分表）存工单、批次、检验等业务主数据；对象存储存 PDF 报告与图片；冷数据按时间分区归档，满足 3 年留存要求。
- 计算层：流处理（Flink）负责实时看板、阈值告警与 SPC 判异；批处理（Spark）负责 T+1 的质量分析、客户对账与模型训练。二者口径必须统一并纳入数据治理，即”实时合格率”与”离线合格率”由同一套指标定义生成。
- 服务层：API 网关统一暴露查询服务，追溯查询走预生成报告 + 缓存，保证 ≤3 秒。
② 批处理与流处理分工：流处理处理秒级时效、低延迟需求（实时监控看板、异常告警），容忍近似；批处理处理高吞吐、可延迟、要求准确的需求（T+1 质量分析、对账、历史追溯索引重建）。采用 Lambda 的简化架构：实时链路走 Flink 供看板，离线链路走 Spark 校准并生成权威数据，二者由统一指标定义约束。
③ 380 台无标准接口设备的采集方案（三条路径，按优先级）：方案一 外挂传感器（对关键参数加装独立传感器，直接采物理量，不侵入原设备、改造成本最低，优先用于老旧机床）；方案二 协议逆向 + 边缘适配（抓包分析私有协议，在边缘网关写适配插件，成本中等、需样机试点验证，对应 S09 的 R-01 风险）；方案三 人工/半自动补录 + 逐步淘汰（对价值低、即将报废的设备，先由操作工扫码报工补齐业务数据，物理参数留待设备更新时解决）。判定原则：按单台改造成本与数据价值排序，先覆盖贡献 80% 追溯价值的 20% 关键设备。
【问题 3】 ① CAP 定理：分布式系统无法同时满足一致性 C、可用性 A、分区容错性 P；分布式系统必然面临网络分区，P 必须保，因此实际是在 C 与 A 之间取舍。 选择 CP 时分区发生会拒绝部分请求以保数据一致；选择 AP 时会继续响应但数据可能暂时不一致，事后收敛（BASE：基本可用、软状态、最终一致）。
② 两个场景的取舍：生产实时监控看板选 AP——诉求是”允许数据晚几秒，但看板不能白屏”，分区时继续返回最近一版缓存数据并显式标注”数据延迟 X 秒”，可用性优先，容忍最终一致；质量追溯报告选 CP——诉求是”准确、可作为法律凭证”，宁可查询慢或提示稍后重试，也绝不能返回不一致或不完整的追溯链条，一致性优先。
③ 一致性实现方案：主体采用”本地消息表 + 消息队列”的最终一致性——采集数据入库与追溯索引更新在同一个本地事务中写入消息表，由 MQ 可靠投递到索引服务，消费端以业务唯一 ID + 去重表实现幂等消费，保证”至少一次投递 + 幂等 = 恰好一次效果”。跨系统的长流程（如不合格品处置涉及 MES、ERP、质量三方）采用 Saga：拆为多个本地事务，失败时按反向顺序调用补偿操作，并在补偿中保证幂等；对强一致有刚性要求的关键写操作（出库/入库、报告签发）采用 TCC（Try 预留 → Confirm 确认 → Cancel 释放），以业务侵入换取无长事务锁的强一致。不采用 2PC——其同步阻塞与协调者单点在跨厂区网络（分区概率高）下会显著放大不可用时间。补充：所有关键数据写入时附 SM3 摘要 + SM2 签名（呼应 S10），使”最终一致”的数据在收敛后仍可验证未被篡改——一致性解决”数据一样”，签名解决”数据没被改”，二者不可互相替代。
五、易错点（Rethink）
| 错误认知 | 为什么错 | 正确理解 |
|---|---|---|
| “BPR 就是优化现有流程” | 混淆 BPR 与 BPI | BPR 是根本性、彻底性、戏剧性、流程导向的再设计；BPI 是渐进式局部优化。前者风险高、后者稳 |
| “ERP 和 MES 是一回事” | 层次不同 | ERP 管计划层（生产什么、何时、要多少料），MES 管执行层（怎么生产、实际产了多少、质量如何）；二者双向集成 |
| “MRP 的输入是 CRP” | 计划层次顺序记错 | MPS → MRP → CRP；MRP 的输入是 MPS + BOM + 库存信息 |
| “数据仓库和数据库只是大小区别” | 忽略四个本质特征 | 面向主题、集成的、非易失、随时间变化；OLAP 用反规范化星型，OLTP 用 3NF |
| “星型模型比雪花模型更规范” | 恰恰相反 | 星型 = 维度表反规范化（冗余多、JOIN 少、查询快）；雪花 = 维度表再规范化（冗余少、JOIN 多） |
| “PaaS 就是虚拟机” | 服务模型层次混淆 | IaaS 给基础设施（虚机、存储）；PaaS 给平台（运行时、数据库、中间件）；SaaS 给现成应用；越往上用户管的越少 |
| “上云就不用管安全了” | 忽略责任共担 | 云服务商负责”云的安全”（物理、主机、虚拟化层），客户负责”云中的安全”（OS 补丁、应用、数据、身份与访问） |
| “HDFS 适合海量小文件” | 与 HDFS 设计目标相反 | HDFS 适合大文件、顺序读、一次写入多次读取；小文件会撑爆 NameNode 内存 |
| “区块链能保证数据真实” | 这是最危险的误解 | **区块链只保证”上链之后不可篡改”，不保证”上链之前是真的”**。采集端可被人为修改时，链只会让假数据更可信 |
| “CAP 是三选二，可以放弃 P” | 忽略 P 的前提地位 | 分布式系统必须容忍网络分区，P 必须保，实为 CP 与 AP 的取舍；无分区时 C 与 A 可同时满足 |
| “选 AP 就是不要正确性” | 把强一致等同于正确 | 放弃的是强一致，不是正确性；通过 BASE 达到最终一致，是正确的另一种实现 |
| “缓存穿透和击穿是一回事” | 触发条件不同 | 穿透 = 查不存在的 key（布隆过滤器/缓存空值）；击穿 = 单个热点 key 过期（互斥锁/逻辑过期）；雪崩 = 大批 key 同时过期或集群宕机（TTL 抖动/多级缓存/熔断） |
| “写操作应该更新缓存” | 并发写会留脏数据 | Cache Aside：写时先更新 DB、再删除缓存（不是更新缓存） |
六、GRASPS 推进（Experience）
本周五前，往交付物里加两块内容，总计 1500–1800 字 + 两张图：
- 系统集成方案（并入「架构设计说明书」）：① 集成全景图一张——标出全部 5 类集成对象（1200 台设备、老 MES、新系统、ERP、质量监管平台），每条连线上标注集成层次（数据/应用/流程/界面）与具体技术（ETL / API 网关 + REST / MQTT + Kafka / 门户 + SSO）；② 集成接口清单 ≥8 条，每条含接口名、提供方、消费方、方向、协议、频率、数据量、幂等键、失败处理；③ 400 字说明为什么老 MES 只做数据集成而不做流程集成，以及二期演进路径。
- 新技术选型论证（新增 2 份 ADR，使总数达到 ≥8 份）：从下列三项中任选两项，每项按 S11 3.5 的五问写成完整 ADR（含被否决方案、代价承担方、触发重构的信号）：① 联盟链用于质量追溯存证；② 边缘计算 + 时序库用于设备采集；③ 大模型/RAG 用于质量知识问答。同时更新 S06 的质量属性场景表，把”追溯凭证可被第三方独立验证””看板不白屏””采集峰值 3 万点/秒不丢数”三条场景补进去，响应度量必须带数字。
- 数据一致性设计说明（并入「数据模型」交付物）：给出CAP 取舍说明（哪几个场景 CP、哪几个 AP），分布式事务方案清单（哪些用本地消息表、哪些用 Saga、哪些用 TCC，各举 1 例），以及幂等设计（唯一 ID 构成 + 去重表结构）。
验收标准：① 集成全景图上每条连线都能说出”为什么是这个层次”；② 两份 ADR 里都写着被否决方案与理由，且都写清了”什么信号出现时推翻这个决定”；③ 三份一致性设计能回答”如果 Kafka 挂了，采集数据会丢吗“（答案必须是”不丢——边缘网关本地缓存 + 断点续传”）；④ 把新技术方案拿给生产部看，他能指出至少一处”这个实时性达不到”——能被业务方证伪的选型，才是可论证的选型。
七、自测
- BPR 的四个关键特征不包括（ ）。 A. 根本性 B. 彻底性 C. 渐进性 D. 戏剧性
- MRP 的三项输入是（ ）。 A. MPS、BOM、库存信息 B. MPS、CRP、BOM C. CRP、BOM、销售订单 D. MPS、CRP、采购订单
- 数据仓库的基本特征不包括（ ）。 A. 面向主题 B. 集成的 C. 可频繁更新 D. 随时间变化
- 下列采用反规范化星型模型的是（ ）。 A. OLTP B. OLAP C. 实时交易库 D. 消息队列
- Hadoop 生态中支持海量数据随机实时读写的组件是（ ）。 A. HDFS B. HBase C. Hive D. MapReduce
- 物联网三层架构由底向上依次是（ ）。 A. 感知层、网络层、应用层 B. 网络层、感知层、应用层 C. 应用层、网络层、感知层 D. 感知层、应用层、网络层
- 联盟链常用的高效共识机制是（ ）。 A. PoW B. PoS C. PBFT D. 哈希cash
- 物联网采集场景首选的轻量级消息协议是（ ）。 A. HTTP B. MQTT C. FTP D. SMTP
- 应对”查询不存在的数据导致缓存永不命中“的措施是（ ）。 A. 布隆过滤器 B. 互斥锁 C. TTL 随机抖动 D. 多级缓存
- 分布式 ID 生成中，趋势递增、本地生成、无中心依赖的方案是（ ）。 A. UUID B. 数据库自增 C. 雪花算法 Snowflake D. Redis INCR
| 题号 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 |
|---|---|---|---|---|---|---|---|---|---|---|
| 答案 | C | A | C | B | B | A | C | B | A | C |
| 解析 | BPR 四要素＝根本性、彻底性、戏剧性、流程导向；渐进性属 BPI | MPS + BOM + 库存信息 → MRP → CRP | 数据仓库非易失（不可更新） | OLAP 用星型/雪花反规范化以冗余换查询性能；OLTP 用 3NF | HBase 列族 NoSQL，随机实时读写；HDFS 大文件顺序读；Hive 离线 SQL | 感知层 → 网络层 → 应用层 | PBFT 实用拜占庭容错，联盟链首选，TPS 高无挖矿 | MQTT 轻量发布/订阅，适合低带宽与不稳定网络 | 穿透用布隆过滤器/缓存空值；击穿用互斥锁；雪崩用 TTL 抖动 | Snowflake＝时间戳+机器ID+序列号，趋势递增、本地生成；UUID 无序 |
八、分档任务（Tailor）
- 保底 45：背死四张表——3.1 主流企业系统缩写对应、3.2 EAI 四层次与 OLTP/OLAP 对比、3.3 Hadoop 生态组件与云服务模型、3.4 CAP/BASE 与缓存三问题对策；完成 4.1 五题 + 自测十题。这四处覆盖约 15 分，是 45 分线的重要拼图。
- 冲 60：完成 GRASPS 三块（集成方案 + 2 份 ADR + 一致性设计）；案例 4.2 的【问题 1】【问题 3】限时 25 分钟手写完整作答并对照采分点自评；把”区块链不保证数据真实“和”P 必须保“两句话练成条件反射。
- 冲 70：以本项目的设备数据采集与质量追溯平台为题写一篇 2500 字论文（方向：”新技术及其应用”或”企业信息系统”），要求含不少于 3 个带数字的真实细节（如”峰值 3 万点/秒””380 台无标准接口设备””看板延迟 ≤5 秒、追溯报告 ≤3 秒”），并必须写出一项新技术的局限与你所做的取舍；另用 300 字论述”为什么在老 MES 仍在运行时强推业务流程集成是错的“。
九、本阶段回答基本问题
Q2（第三次追问）：在没有唯一最优解的世界里，怎么证明一个架构（或一项新技术选型）是”好的”？
第一，证明一个选型是好的，靠的不是”它先进”，而是”它解决了哪个可度量的质量属性场景”。 设备部说”用区块链做追溯”，这句话无法论证；把它翻译成”追溯凭证可被整车厂独立验证、验证时延 ≤ 2 秒“，它才进入可讨论的范围。凡是不能被翻译成场景与响应度量的技术诉求，都是审美表达，不是需求。 这正是 S06 的 ATAM 方法在新技术语境下的复用——换汤不换药，方法不变，只是候选方案变多了。
第二，一个能被论证的决策，必须同时写下”被否决方案”和”什么信号出现时该推翻它”。 我们在区块链 ADR 里否决了全量上链（性能与成本）和不上链（不满足第三方验证），并写下”P99 > 2 秒则改异步验证、年运维成本 > 15 万则退化为数字签名 + 可信时间戳“。这两句话才是 ADR 的价值所在：前者证明你比较过，后者承认你可能错。 一个不允许自己被推翻的架构决策，是宗教，不是工程——这是 EU-2”架构不是选最优解，而是把权衡写清楚”在新技术上的延伸。
Q3（第三次追问）：什么时候该遵守规范，什么时候该为性能打破规范？在分布式环境下谁来承担代价？
第三，Q3 的答案在 S05 是”范式 vs 反范式”，在 S11 变成了”CP vs AP”，但底层是同一个权衡——用可控的不一致去换可用性或性能，前提是你知道代价并主动管理它。 OLAP 用星型模型（反规范化）换查询速度，代价是冗余与更新异常，由 ETL 统一重建来补偿；实时看板选 AP 换不白屏，代价是数据可能晚几秒，由显式标注”数据延迟 X 秒”来补偿。共同点：打破规范必须配一个补偿机制，且必须让使用者看见代价。 看不见代价的取舍不叫权衡，叫事故。
第四，分布式环境下，”一致性”和”没被篡改”是两件事，不能互相替代。 一致性解决”各节点数据一样“，数字签名解决”这份数据没被改过“。本项目里，追溯报告既要靠 Saga/TCC/本地消息表保证链条完整一致，又要靠 SM3 + SM2 保证内容不可篡改——缺前者，链条可能残缺；缺后者，链条完整也可能是假的。 这也是对”区块链保证数据真实”这一误解的正面回应：链解决不了采集端的真，采集端可信要靠边缘可信环境、签名与审计日志。
第五，”先固化、后优化、再重组”是一条有立场的推进策略，不是保守。 一家连准确数据都拿不到的企业，直接推 BPR 是在流沙上盖楼；一期用 BPI 把流程搬到线上并把数据采集可信化，二期才有重组的依据。选型的勇气不在于敢用最新技术，而在于敢对不合适的技术说”现在不是时候”，并把这句话连同触发条件一起写进 ADR。
Q2 与 Q3 至此完成第三次深化：S06 给方法（质量属性场景 + ATAM + ADR），S11 给新技术时代的素材（云/大/物/智/链的取舍），S05 给数据侧的判据（范式与反范式），S11 再把它扩展到分布式（CAP/BASE/分布式事务）。四个基本问题只剩最后一件事：把 12 周的答案装进 240 分钟和 2500 字里——这是 S12 要做的事。
