软考专题 · 企业应用集成（EAI·ESB·中间件·集成模式｜选择题 18 + 案例答题套路 + 集成方案模拟题 + 论文提纲）
企业应用集成是系统架构设计师案例分析和论文的常客——论文里反复出现「论企业应用集成（EAI）」「论遗留系统的演化与集成」「论中间件技术及其应用」，案例分析常给一段「集团下几十套异构系统、点对点接口失控」的场景让你给集成方案，综合知识里也有中间件类型、集成方式选择题。这篇把必背理论（EAI 四层次 + ESB 能力 + 中间件分类 + EIP 集成模式 + 遗留系统演化策略）、高频选择题（18 题，带 ✅ 答案 + 解析）、案例答题套路、1 道完整集成方案模拟题、论文万能提纲打包在一起。内容来自开源仓库
PeterGuy326/senior-software-architect-review。回到 软考导览页 看完整专题清单。
一、必背：核心理论
企业应用集成 EAI 的层次与类型
EAI（Enterprise Application Integration，企业应用集成）的目标是把企业内部由不同厂商、不同时期、不同技术栈建设的异构系统连起来，消除”数据孤岛”和”业务断点”。教材按集成切入点把它分为四个层次：
| 层次 | 别名 | 集成在哪一层 | 典型技术 |
|---|---|---|---|
| 用户界面集成 | 表示集成 / 门户集成 | 表示层（屏幕抓取、Portal、iframe） | 企业门户 Portal、SSO 单点登录、iframe 嵌入 |
| 数据集成 | DB 级集成 | 数据库层（直接搬数据） | ETL（Kettle/DataX）、共享数据库、数据复制、CDC、数据仓库、MDM 主数据 |
| 应用接口集成 | 控制集成 / 功能集成 | 应用接口层（调对方暴露的 API/适配器） | API/适配器、消息中间件 MOM、ESB、RPC |
| 方法 / 业务过程集成 | 流程集成 | 跨系统的业务流程 | BPM/工作流编排（Camunda/Activiti）、BPEL、流程引擎 |
按耦合度从松到紧排序（高频考点）：
1 | 表示集成（最松） < 数据集成 < 控制集成（功能/应用集成） < 业务流程集成（最紧） |
口诀：表示层只共用界面，最松；数据集成搬数据，绕过应用逻辑，比控制集成还松一点；业务流程集成把多个系统的能力编排进同一条流程里，一处改动牵连最多，最紧。
集成拓扑：点对点 → 中心辐射 → 总线
| 拓扑 | 结构 | 连接数（N 个系统） | 优缺点 |
|---|---|---|---|
| 点对点 P2P | 每两个系统之间各拉一根线 | N×(N−1)/2 条（N=10 即 45 条） | 短期最快上线；系统多了变成”意大利面”，改一处牵全身，难维护，反模式 |
| 中心辐射 Hub-and-Spoke | 所有系统只连中心 Hub，Hub 负责转换路由 | N 条 | 连接数线性增长、集中管理；Hub 是单点瓶颈，早期 EAI Broker 形态 |
| 总线 Bus / ESB | 各系统接入一条服务总线，总线提供标准化的接入/路由/转换 | N 条 | Hub-and-Spoke 的演进形态，标准化、可分布式部署、可扩展；重量级，引入学习/运维成本 |
考试结论：系统一多，淘汰点对点，用 Hub-and-Spoke 或 ESB/消息总线收敛连接数。
ESB（企业服务总线）
ESB（Enterprise Service Bus）是 SOA 时代的集成基础设施，本质是”加了智能的消息总线”。
ESB 核心能力（必背）：① 协议转换（SOAP↔REST↔JMS↔FTP↔HTTP）② 消息路由（含基于内容的路由 Content-Based Router）③ 数据格式转换（XML↔JSON↔CSV，字段映射）④ 消息增强/补全（Message Enricher，从其它系统补字段）⑤ 服务编排与流程（BPEL/简单编排）⑥ 安全（统一鉴权、加密、签名、WS-Security）⑦ 监控与审计（消息日志、SLA、链路追踪）。
ESB 在 SOA 中的角色：连接服务消费者与服务提供者，让双方”互不知道对方在哪、用什么协议”，实现去中心化通信与位置透明；典型参考模型是「服务消费者 ⇄ 服务注册中心（UDDI）⇄ 服务提供者」，ESB 负责中间的传输、转换、路由、编排。
ESB vs API 网关 vs 微服务通信：
| 维度 | ESB（SOA） | API 网关 | 微服务（去 ESB 化） |
|---|---|---|---|
| 角色 | 企业内部系统间的”重型集成总线” | 对外/对内的统一入口（路由、鉴权、限流、聚合） | 服务间直连（REST/gRPC）+ 注册发现 + 服务网格 |
| 智能放哪 | 总线很”智能”（路由/转换/编排都在总线里） | 网关轻量，业务逻辑下沉到后端服务 | “智能终端，哑管道“——逻辑在服务里，通道只负责传 |
| 趋势 | 中心化、易成瓶颈；新建系统少用 | 边界治理的标准件 | 主流方向；ESB 的能力被网关 + 服务网格 + 轻量消息总线分解掉 |
考试常考一句话：微服务相对 SOA 的最大变化之一就是”用**哑管道（dumb pipe）+ 智能终端（smart endpoint）**取代了 ESB 这种重型智能管道”。
中间件分类速查表（呼应教材”中间件”章）
| 中间件类型 | 作用 | 代表产品 | 通信方式 |
|---|---|---|---|
| 远程过程调用 RPC | 像调本地函数一样调远程服务 | Dubbo、gRPC、Thrift、（早期）RMI | 同步 |
| 面向消息中间件 MOM | 异步收发消息，解耦、削峰、可靠投递 | Kafka、RabbitMQ、RocketMQ、ActiveMQ | 异步 |
| 对象请求代理 ORB | 分布式对象调用，屏蔽位置与语言 | CORBA（IIOP 协议）、（DCOM） | 同步 |
| 事务处理中间件 TPM | 跨资源的分布式事务协调（2PC/XA） | Tuxedo、CICS、JTA/JTS | 同步 |
| 数据访问中间件 | 统一访问异构数据库 | ODBC、JDBC、（数据虚拟化） | 同步 |
| 应用服务器中间件 | 运行/管理企业应用，提供事务/连接池/安全等容器服务 | Tomcat、WebLogic、JBoss/WildFly、WebSphere | — |
同步 vs 异步通信对比（高频）：
| 维度 | 同步（RPC/HTTP） | 异步（MOM/消息） |
|---|---|---|
| 调用方 | 阻塞等返回，时序强依赖 | 发完就走，不等结果 |
| 耦合度 | 高（双方必须同时在线） | 低（解耦，生产者/消费者独立伸缩） |
| 实时性 | 强，立即拿到结果 | 弱，最终一致 |
| 容错 | 下游挂了上游就挂（雪崩风险） | 削峰填谷，下游慢/挂消息先堆队列 |
| 适用 | 强一致、需要立即结果（查询、支付） | 解耦、批量、通知、跨系统集成（EAI 首选） |
企业集成模式 EIP（Hohpe）选讲
Hohpe 在《Enterprise Integration Patterns》里归纳了 65 个消息集成模式，软考常涉及这几个：
| 模式 | 一句话 |
|---|---|
| 消息通道 Message Channel | 系统之间通过逻辑通道收发消息（点对点队列 / 发布订阅主题） |
| 消息路由器 Message Router | 按规则把消息转发到不同目的地；基于内容的路由 Content-Based Router = 看消息内容（如订单金额、地区）决定走哪条路 |
| 消息转换器 Message Translator | 把一种数据格式/结构转成另一种（XML→JSON、字段重映射） |
| 聚合器 Aggregator | 把一组相关消息攒齐后合并成一条（如把订单的多个子查询结果拼成一个响应） |
| 分割器 Splitter | 把一条大消息拆成多条小消息分别处理（如一个批量订单拆成多个单订单） |
| 消息端点 Message Endpoint | 应用接入消息系统的适配点（发送/接收端点） |
| 死信通道 Dead Letter Channel | 处理不了/投递不了的消息丢到死信队列，人工或补偿处理 |
| 保证投递 Guaranteed Delivery | 消息持久化落盘，宕机不丢，最终一定送达（at-least-once） |
Hohpe 还把”集成方式”归纳为四种（教材也引用）：文件传输（简单、异步、粒度粗）、共享数据库（紧耦合、易冲突）、远程调用 RPC（同步、强耦合）、消息传递 Messaging（解耦、异步，业界推荐）。
数据交换标准
- XML：自描述、标准化、可校验（XSD），SOAP/WSDL 都基于 XML；缺点是冗长。
- JSON：轻量、易解析，REST/前后端交互首选。
- SOAP：基于 XML 的消息协议，配 WSDL（接口描述）+ UDDI（注册发现）= Web Service 三要素；支持 WS-Security 等企业级规范，但重。
- REST：架构风格（资源 + HTTP 动词 + 无状态），轻量、易缓存，主流；不是协议。
- EDI（电子数据交换）：企业间标准化报文（订单、发票），传统供应链/外贸常用。
SOAP vs REST 速记：SOAP 重、强契约（WSDL）、跨协议（不止 HTTP）、有 WS-*；REST 轻、用 JSON、基于 HTTP、靠约定。
遗留系统（Legacy System）的演化策略
教材按 “技术价值 × 业务价值”四象限给出演化决策：
| 象限 | 业务价值 | 技术价值 | 策略 | 做法 |
|---|---|---|---|---|
| 高业务 + 高技术 | 高 | 高 | 继承（封装/集成） | 系统还好，保留，做接口对接 |
| 高业务 + 低技术 | 高 | 低 | 改造 | 业务离不开但技术老旧 → 局部重构 + 数据迁移，逐步现代化 |
| 低业务 + 高技术 | 低 | 高 | 集成 | 技术不错但业务弱化 → 用 Wrapper/适配器封装，并入新平台 |
| 低业务 + 低技术 | 低 | 低 | 淘汰（替换重建） | 又老又没用 → 直接弃用、用新系统替代 |
四种策略关键词：淘汰（Replace，替换重建）/ 继承（Encapsulate/Wrap，封装包装 + 适配器）/ 改造（Refactor，局部重构 + 数据迁移）/ 集成（Integrate，接口对接）。其中 Wrapper（包装器）+ 适配器（Adapter） 是把遗留系统”裹一层标准接口”对外提供服务的常用手段——遗留系统内部不动，外面套一层 REST/消息接口。
iPaaS / API 管理 / 数据集成平台
- iPaaS（Integration Platform as a Service，集成平台即服务）：云上的集成中台，提供连接器、流程编排、API 管理、数据映射，把 ESB + ETL + API 网关的能力 SaaS 化（如 MuleSoft Anypoint、Boomi、阿里集成中台）。
- API 管理平台：API 全生命周期（设计、发布、网关、版本、配额、计费、开发者门户）。
- 数据集成平台：批量 ETL + 实时 CDC + 数据虚拟化 + 主数据 MDM，面向”数据层集成”。
二、高频选择题（18 题，✅ 为正确选项）
1. EAI（企业应用集成）按集成切入点划分，下列不属于其层次的是：
A. 用户界面集成（表示集成） B. 数据集成 C. 应用接口集成（控制集成） ✅ D. 网络协议集成
EAI 四层次 = 表示集成 / 数据集成 / 控制（应用）集成 / 业务流程集成；没有”网络协议集成”这一层。
2. 下列对各类集成方式按耦合度从松到紧排序正确的是：
✅ A. 表示集成 < 数据集成 < 控制集成 < 业务流程集成 B. 数据集成 < 表示集成 < 控制集成 < 业务流程集成 C. 表示集成 < 控制集成 < 数据集成 < 业务流程集成 D. 业务流程集成 < 控制集成 < 数据集成 < 表示集成
表示集成只共用界面最松；业务流程集成把多系统能力编排进同一流程最紧。
3. 某集团有 12 个系统全部采用点对点（P2P）方式两两集成，理论上的接口连接数约为：
A. 12 B. 24 ✅ C. 66 D. 144
N×(N−1)/2 = 12×11/2 = 66 条；这正是点对点”难维护、改一处牵全身”的根因。
4. 关于集成拓扑，下列说法错误的是：
A. 点对点拓扑连接数随系统数平方增长 B. 中心辐射（Hub-and-Spoke）把连接数降为线性 ✅ C. ESB 拓扑必然是单点、无法分布式部署 D. ESB 是中心辐射模式的演进，强调标准化接入
ESB 本身可集群/分布式部署，相比早期单一 Hub 更可扩展；”中心化易成瓶颈”是缺点但不等于”必然单点不可分布式”。
5. 关于企业服务总线 ESB 的核心能力，下列不属于的是：
A. 协议转换 B. 消息路由与基于内容的路由 C. 数据格式转换与消息增强 ✅ D. 业务数据的主数据建模与去重（MDM）
协议转换/路由/格式转换/编排/安全/监控是 ESB 的事；主数据建模、Golden Record、去重属于 MDM（数据集成层），不是 ESB 职责。
6. 在 SOA 架构中，ESB 的主要作用是：
✅ A. 连接服务消费者与提供者，屏蔽协议/位置/格式差异，实现松耦合通信 B. 存储所有服务的源代码 C. 替代数据库 D. 负责前端页面渲染
ESB = SOA 的通信枢纽，消费者和提供者互不感知对方实现细节。
7. 相比传统 SOA + ESB，微服务在服务间通信上的典型理念是：
A. 用更重的智能管道集中编排 ✅ B. “智能终端，哑管道”——逻辑放服务里，通道只负责传输 C. 必须共用一个数据库 D. 全部改用同步 RPC
微服务用轻量管道（REST/消息）+ 把路由/编排逻辑下沉到服务，去 ESB 化。
8. 下列中间件类型与代表产品对应错误的是：
A. 面向消息中间件 MOM —— RabbitMQ / Kafka B. 远程过程调用 RPC —— Dubbo / gRPC ✅ C. 对象请求代理 ORB —— Tomcat / WebLogic D. 事务处理中间件 TPM —— Tuxedo / CICS
Tomcat/WebLogic 是应用服务器中间件；ORB 的代表是 CORBA（IIOP）。
9. 关于同步通信与异步通信，下列说法错误的是：
A. 同步通信调用方阻塞等待结果，耦合度较高 B. 异步通信通过消息中间件解耦，可削峰填谷 C. 异步通信通常只能保证最终一致性 ✅ D. 企业应用集成（EAI）应优先采用同步 RPC 以保证强一致
EAI 跨系统集成首选**消息传递（异步）**实现解耦，避免 RPC 强依赖造成的雪崩。
10. Web Service 的三个核心标准（”三件套”）是：
A. HTTP / HTML / JSON ✅ B. SOAP / WSDL / UDDI C. REST / JSON / OpenAPI D. SOAP / XML / FTP
SOAP（消息协议）+ WSDL（接口描述）+ UDDI（服务注册发现）。
11. 关于 SOAP 与 REST 的对比，下列说法错误的是：
A. SOAP 基于 XML，REST 常用 JSON B. SOAP 有 WSDL 强契约，REST 多靠约定与文档 C. SOAP 可跨多种传输协议，REST 主要基于 HTTP ✅ D. REST 是一种通信协议，SOAP 是一种架构风格
恰好相反：SOAP 是协议，REST 是架构风格（资源 + HTTP 动词 + 无状态）。
12. CORBA 属于下列哪类中间件？
A. 面向消息中间件 B. 应用服务器中间件 ✅ C. 对象请求代理（ORB）中间件 D. 数据访问中间件
CORBA 通过 ORB + IIOP 协议实现跨语言、跨平台的分布式对象调用。
13. ESB 中”根据消息内容（如订单金额、地区、类型）把消息分发到不同处理服务”对应的集成模式是：
A. 聚合器 Aggregator B. 分割器 Splitter ✅ C. 基于内容的路由 Content-Based Router D. 死信通道 Dead Letter Channel
Content-Based Router 看消息体内容决定路由目的地。
14. 下列对企业集成模式（EIP）的描述错误的是：
A. 聚合器 Aggregator 把多条相关消息攒齐合并为一条 B. 分割器 Splitter 把一条大消息拆成多条小消息 C. 死信通道用于存放无法投递/处理的消息 ✅ D. 消息转换器 Translator 用于把同步调用改成异步调用
Message Translator 做的是数据格式/结构转换；”同步改异步”不是它的职责。
15. 关于”保证投递（Guaranteed Delivery）”，下列说法正确的是：
✅ A. 消息持久化落盘，即使节点宕机重启也不丢，最终一定送达 B. 消息只保存在内存中以追求性能 C. 保证消息绝不重复（exactly-once） D. 必须配合同步 RPC 使用
保证投递通常是 at-least-once（可能重复，需消费端幂等），靠持久化 + 重试实现。
16. 教材按”技术价值 × 业务价值”四象限给出遗留系统演化策略，对于”业务价值低、技术价值也低”的系统，应采取：
A. 改造（局部重构 + 数据迁移） B. 继承（封装包装） C. 集成（接口对接） ✅ D. 淘汰（替换重建）
又老又没用 → 直接弃用、用新系统替代；高业务低技术才”改造”，低业务高技术才”集成”。
17. 把遗留系统内部代码原样保留，在外面套一层标准 REST/消息接口对外提供服务，这种手法称为：
✅ A. Wrapper（包装器）/ 适配器封装 B. 重写（Rewrite） C. 数据迁移（Migration） D. 分库分表
Wrapper + Adapter 是遗留系统”继承/集成”策略的常用实现，内部不动、外面裹一层。
18. 关于 iPaaS（集成平台即服务），下列说法正确的是：
✅ A. 云上的集成中台，把 ESB/ETL/API 管理/连接器/流程编排等能力以服务方式提供 B. 一种数据库分片中间件 C. 一种容器编排引擎 D. 一种前端框架
iPaaS 代表如 MuleSoft Anypoint、Boomi、阿里集成中台，面向多云/混合集成场景。
原文 + 更多解析见仓库
exam-bank（企业集成 / 中间件相关章节）。
三、案例答题套路（25 分）
“企业应用集成 / 遗留系统改造”案例答题六步法
① 识别待集成系统与异构点 → ② 选集成拓扑 → ③ 选集成方式（数据/应用/流程） → ④ 技术手段（ESB/MOM/适配器/网关） → ⑤ 数据一致性 → ⑥ 安全与监控。
① 识别待集成系统与异构点
- 列出要集成的系统（ERP/CRM/OA/财务/自研订单……）。
- 找异构点：技术栈不同（Java/.NET/老 C/S）、协议不同（SOAP/REST/FTP/数据库直连）、数据格式不同（XML/JSON/CSV/私有报文）、数据库不同（Oracle/SQL Server/MySQL）、时序不同（实时 vs 批量）。
② 选集成拓扑
- 一句话：淘汰点对点（连接数 N×(N−1)/2、改一处牵全身），用 ESB / 消息总线（连接数线性、标准化接入、可分布式部署）；规模不大或预算紧可用 Hub-and-Spoke。
③ 选集成方式（按耦合度 + 实时性 + 数据量选）
- 数据集成：只需把数据搬过去/做报表 → ETL（批量）/ CDC（准实时），不打扰对方应用逻辑。
- 应用接口集成（控制集成）：需要调用对方业务能力 → 通过对方暴露的 API/适配器 + ESB 路由转换；首选异步消息解耦，强一致场景才用 RPC。
- 业务流程集成：跨系统的端到端流程（采购审批→财务挂账→供应链下单→入库→付款）→ BPM/工作流引擎编排（Camunda/Activiti，BPMN 2.0）。
- 通常四层叠加：门户 SSO（表示）+ ETL/MDM（数据）+ ESB/MQ（应用）+ BPM（流程）。
④ 技术手段
- ESB / MOM：协议转换（SOAP↔REST↔JMS↔FTP）+ 消息路由（含基于内容的路由）+ 格式转换（XML↔JSON 字段映射）+ 消息增强（补字段）。
- 适配器封装遗留系统：老系统内部不动，套 Wrapper/Adapter 暴露标准接口接入总线。
- API 网关对外：对外部合作伙伴/前端统一入口，做鉴权、限流、聚合（网关轻量，不塞业务逻辑）。
- 中间件选型有理由：日志/流处理量大 → Kafka；金融级事务消息 → RocketMQ；企业内异步解耦/路由灵活 → RabbitMQ。
⑤ 数据一致性
- 跨系统优先最终一致：消息可靠投递（持久化 + 重试 + 死信队列）+ 消费端幂等 + 定时对账兜底。
- 实时数据同步用 CDC（Canal/Flink CDC 监听 binlog）；主数据用 MDM 统一客户/产品/组织。
- 强一致只在必要的少数节点用（TCC/2PC），不要一把梭。
⑥ 安全与监控
- 统一鉴权：OAuth2 / SAML SSO，集成入口统一认证授权。
- 链路追踪：Trace ID 贯通跨系统调用（SkyWalking），消息加追踪头。
- 消息审计：ESB/MQ 留全量消息日志，可回放、可追溯；SLA 监控 + 告警。
万能高分句
- “原有 N 套系统采用点对点集成，接口数 N×(N−1)/2，改一处牵全身；本方案引入 ESB / 企业消息总线，将连接数收敛为 N，并标准化接入。”
- “按集成层次分层落地：门户层 SSO 单点登录 + Portal、数据层 ETL + Flink CDC + MDM 主数据、应用层 ESB（协议转换/路由/格式转换）+ Kafka 消息总线、流程层 Camunda BPMN 编排跨系统流程。”
- “遗留系统（如老 OA、老财务）不重写，采用 Wrapper/适配器封装出标准 REST/消息接口接入总线，按’技术价值×业务价值’四象限决定后续是改造还是淘汰。”
- “跨系统数据一致性采用消息可靠投递（持久化+重试+死信队列）+ 消费端幂等 + 定时对账实现最终一致，关键节点辅以 TCC。”
- “统一安全：集成入口 OAuth2/SAML 鉴权 + Trace ID 全链路追踪 + ESB 消息审计。”
常见陷阱
| ❌ | ✅ |
|---|---|
| 还在用点对点 P2P 集成 | 系统多了必须收敛——Hub-and-Spoke / ESB / 消息总线 |
| 不区分集成层次 | 表示 / 数据 / 应用 / 流程四层分别给方案 |
| ESB 里塞大量业务逻辑 | ESB 只做路由/转换/编排，业务逻辑留在各服务里 |
| 全部用同步 RPC 串起来 | 跨系统集成首选异步消息解耦，强一致才用 RPC |
| 不谈数据一致性 | 最终一致 + 幂等 + 对账 + CDC 必写 |
| 遗留系统直接重写 | 先 Wrapper 封装，再按四象限评估改造/淘汰 |
| 没有监控 | 统一鉴权 + Trace ID 链路追踪 + 消息审计必写 |
四、完整模拟案例题（25 分）
⚠️ 自主命题改编：题目为基于公开考点和历年真题方向改编的仿真模拟题，避免版权风险。建议严格 25 分钟限时作答，再对照参考答案要点复盘。
【题干】 某省属能源集团”华能盛达”经过 15 年信息化建设，目前在运行的核心系统有 8 套：SAP ERP（财务/采购/库存）、自研 OA（审批/公文）、Salesforce CRM（客户/商机）、自研订单管理系统（Java，对接终端门店）、电力调度系统（老 C/S，C++）、HR 系统（.NET）、供应商门户（PHP）、数据报表平台（基于 Oracle）。这 8 套系统由不同厂商在不同时期建设，技术栈、协议、数据格式各异：有的暴露 SOAP Web Service，有的只有 REST，有的靠定时 FTP 传文件，有的甚至只能直连数据库。多年来集成全靠”用到谁连谁”的点对点接口，目前已有 26 个两两接口，痛点：① 改一处接口常常影响多个下游，2025 年因接口变更引发的生产事故 5 起；② 跨系统流程（如”采购申请→财务审批→供应商下单→入库→付款”）要在 4 套系统间手工流转，平均 7 天；③ 客户、供应商主数据在 ERP/CRM/供应商门户里各存一份，口径冲突，报表对不上；④ 新建一个”绿电交易”业务，要打通 5 套系统，开发了 5 个月还没上线；⑤ 没有统一身份，员工要记 8 套账号；⑥ 跨系统出问题靠人肉排查，定位一次故障常常半天。集团决定建设统一企业集成平台。
问 1（6 分）：该平台应选择什么集成拓扑？说明理由，并与当前点对点方案对比（含连接数）。
问 2（7 分）：针对上述 8 套系统的集成需求，分别说明应采用 EAI 的哪个层次/哪种集成方式（表示/数据/应用接口/业务流程），各举例。
问 3（6 分）：给出 ESB / 中间件层面的技术方案：ESB 承担哪些能力？老 C/S 调度系统、只能直连数据库的报表平台分别怎么接入？消息中间件怎么选？
问 4（6 分）：给出跨系统数据一致性方案和统一安全/监控方案。
【参考答案要点】
问 1（拓扑选型）：选 ESB / 企业消息总线（总线拓扑），必要时配 API 网关对外。理由：① 当前点对点 8 套系统已有 26 个接口，理论上限 N×(N−1)/2 = 28，再加新业务会逼近”全互联”，连接数随系统数平方膨胀，改一处牵全身（已发生 5 起事故）；② 改为总线后每套系统只接入总线一次，连接数降为 N=8（线性），新增系统只需接一根线；③ 总线提供标准化接入 + 协议/格式转换 + 路由 + 编排 + 监控，相比早期单一 Hub 还可集群化部署、避免单点。对比表：点对点（连接数 28、强耦合、难维护、变更影响面大）vs 总线（连接数 8、松耦合、集中治理、可扩展）。
问 2（分层集成方式）：
- 用户界面集成（表示集成）：建企业门户 Portal + SSO 单点登录（CAS/OAuth2 + LDAP），把 OA、CRM、订单系统、HR、供应商门户等以菜单/iframe 集成，解决”8 套账号”。
- 数据集成（数据层）：报表平台只需数据 → 用 ETL（Kettle/DataX）批量 + Flink CDC 准实时从 ERP/订单系统抽数据进数仓；客户/供应商主数据冲突 → 建 MDM 主数据管理，统一客户、供应商、组织三类主数据的 Golden Record，各系统以 MDM 为准。
- 应用接口集成（控制集成）：CRM 商机转 ERP 订单、订单系统查 ERP 库存、绿电交易调多系统能力 → 通过各系统暴露/适配出的 API + ESB 路由 + 协议转换 + 格式转换；首选异步消息解耦（如”订单创建”事件广播给库存、财务、报表多消费者），强一致环节（如下单扣库存）才用同步/TCC。
- 业务流程集成（流程层）：跨 4 套系统的”采购申请→财务审批→供应商下单→入库→付款”流程 → 用 **BPM/工作流引擎（Camunda/Activiti，BPMN 2.0）**编排，每个节点调用对应系统的服务，流程可视化、可监控；目标把 7 天压缩到 1 天内。
问 3（ESB / 中间件技术方案）：
- ESB 承担：协议转换（SOAP↔REST↔JMS↔FTP↔HTTP，让 SAP 的 SOAP、CRM 的 REST、供应商门户的 FTP 文件互通）+ 消息路由（含基于内容的路由，按业务类型/地区分发）+ 数据格式转换（各系统字段映射，XML↔JSON↔CSV）+ 消息增强（路由时从 MDM 补全主数据）+ 简单服务编排 + 统一安全 + 消息审计。ESB 集群部署，不在 ESB 里写业务逻辑。
- 老 C/S 电力调度系统（C++）：无标准接口 → 开发 Wrapper/适配器（按”高业务+老技术=改造，或先集成”），把它的能力包装成 REST/消息接口接入总线，调度系统内部暂不改；后续按四象限评估是改造还是逐步替换。
- 只能直连数据库的报表平台：用数据集成方式——不让别的系统直连它的库，而是通过 ETL/CDC 把所需数据推/拉过去，或在总线侧用数据访问适配器（JDBC 适配器）封装；属于”数据集成”层而非”应用接口集成”。
- 消息中间件选型：企业内异步解耦、路由灵活、量级中等 → RabbitMQ（AMQP，路由能力强）；若有大量日志/流式数据进数仓 → 加 Kafka；若涉及资金类强可靠/事务消息（付款相关）→ RocketMQ（原生事务消息）。给出选型理由（业务特征/吞吐/可靠性/团队栈/成本）。
问 4（数据一致性 + 安全监控）：
- 数据一致性：跨系统优先最终一致——消息可靠投递（持久化落盘 + 失败重试 + 死信队列）+ 消费端幂等（唯一消息 ID + 状态表）+ 定时对账（如 ERP 库存 vs 订单系统库存每日核对，差异告警）；实时数据同步用 CDC（Canal/Flink CDC 监听 binlog）；主数据用 MDM 统一，避免口径冲突；关键资金/库存环节用 TCC 保强一致，不全局用 2PC。
- 统一安全：集成入口统一 OAuth2 / SAML SSO（配 LDAP），服务调用走令牌鉴权 + 最小权限；敏感数据（客户/供应商 PII）传输加密、脱敏、分级。
- 统一监控：Trace ID 全链路追踪（SkyWalking，消息带追踪头，跨 8 套系统贯通调用链）+ ESB/MQ 消息审计日志（可回放、可追溯）+ SLA 监控 + 告警（接口成功率、延迟、积压）+ 集成治理仪表盘。把”故障定位半天”降到分钟级。
五、论文万能提纲（约 2500 字）
典型题目：论企业应用集成（EAI）及其应用 / 论异构系统集成方案 / 论中间件技术及其应用 / 论遗留系统的演化与集成。
1 | 1. 背景（约 400 字） |
摘要模板：”我于 2023 年牵头了 {大型集团 / 省属企业 / 银行} 企业集成平台建设项目，担任 {集成架构师}。集团下 {25 套异构系统}，原靠点对点集成、接口数 {300 个}，跨系统流程手工流转、客户/供应商主数据口径冲突、新业务上线以月计。本文以该项目为背景，论述企业应用集成的方法与实践：拓扑上从点对点改为 ESB + Kafka 消息总线（连接数收敛为线性）；分四层落地——门户 SSO（表示）、ETL/Flink CDC/MDM（数据）、ESB 协议转换路由 + API 网关（应用）、Camunda BPMN 编排（流程）；遗留系统用 Wrapper/适配器封装接入；数据一致性靠消息可靠投递 + 幂等 + 对账 + CDC 实现最终一致；统一 OAuth2/SAML 鉴权 + SkyWalking 全链路追踪 + 消息审计。最终集成接口降为 50 个、跨系统流程从 7 天降至 1 天、新业务接入从 5 个月缩短到 3 周、数据一致率从 85% 提升到 99.5%、年集成事故归零。同时分析了 ESB 中心化瓶颈、强一致与性能的权衡，并规划了向轻量总线/服务网格演进的路线。”
加分关键词：EAI 四层次（表示/数据/应用/流程）、耦合度排序、点对点 N²、Hub-and-Spoke、ESB、协议转换、Content-Based Router（基于内容的路由）、Message Translator、Aggregator/Splitter、死信通道、保证投递、消息传递模式、MOM/RPC/ORB/CORBA/TPM、同步 vs 异步、Web Service（SOAP/WSDL/UDDI）、REST、EDI、遗留系统四象限、淘汰/继承/改造/集成、Wrapper/Adapter、防腐层 ACL、MDM/Golden Record、CDC（Canal/Flink CDC）、ETL/ELT、BPM/BPMN/DMN、SSO、OAuth2/SAML、Trace ID 全链路、iPaaS、Event Mesh；业界对标：IBM WebSphere ESB、Oracle SOA Suite、MuleSoft Anypoint、WSO2、SAP PI/PO、阿里集成中台、招行集中作业平台、Camunda。
避坑：①只讲 ETL → EAI 四层全（表示/数据/应用/流程）必写；②点对点集成 → 走总线/网关，强调连接数从 N² 收敛到 N；③不提主数据 → MDM 是集成成败关键；④ESB 塞业务逻辑 / ESB 成新单点 → ESB 只做路由转换编排、要集群化、新建系统优先轻量总线；⑤不分集成模式 → Hohpe 四模式比较、推荐消息传递；⑥遗留系统直接重写 → 先 Wrapper 封装、按四象限评估；⑦缺监控 → 跨系统全链路追踪 + Trace ID + 消息审计；⑧不谈权衡 → ESB 中心化 vs 微服务化、强一致 vs 性能要写到。
完整理论 + 模拟论文 + 提纲见仓库
past-papers/paper-topics/11-enterprise-integration.md；SOA/ESB 相关见past-papers/paper-topics/07-soa.md；中间件对比见cheatsheets/middleware-comparison.md。
软考专题系列第 13 篇。同组：DevOps 与 Serverless · 嵌入式系统架构 · SOA 与架构演化。完整专题清单见 软考导览页。发现题目错误欢迎到 仓库 开 issue。
