SOA 与架构演化是系统架构设计师的高频主题——综合知识每年 2-4 道选择题（SOA 原则 / 服务粒度 / Web Service / SOA vs 微服务），案例分析常出”SOA 改造 / 单体→微服务 / 上云演化”大题，论文更是经典题（论 SOA 及其应用 / 论软件架构演化 / 论遗留系统的改造）。这篇把必背理论 + 高频选择题（自主命题，带 ✅ 答案 + 解析）+ 案例答题套路 + 完整模拟题 + 论文万能提纲打包在一起。内容来自开源仓库 PeterGuy326/senior-software-architect-review。回到 软考导览页 看完整专题清单。

一、必背：核心理论

SOA 定义与核心思想

面向服务架构（SOA，Service-Oriented Architecture）是一种以”服务“为基本单元构建分布式系统的架构风格。服务是可独立部署、可远程调用的业务能力单元，对外通过标准化契约暴露，由服务消费者 / 服务提供者 / 服务注册中心三方组成调用闭环。核心思想：松耦合、粗粒度、标准化接口、可复用、可组合（编排 / 编制）。

SOA 设计原则（教材必背）

原则 含义
服务松耦合 消费者只依赖契约，不感知提供者实现
服务契约（标准化接口） 契约（WSDL/OpenAPI）先行，描述操作、消息、绑定、端点
服务抽象 隐藏实现细节，只暴露契约约定的能力
服务可复用 一次设计、多处使用，构建企业服务目录
服务自治 服务独立开发、部署、运行、演进，自管资源
服务无状态 每次调用自包含，状态下沉到 DB/缓存，利于弹性
服务可发现 通过注册中心（UDDI）查找元数据与端点
服务可组合 通过编排 / 编制组合成更大的业务流程

速记口诀：”重松契抽复自无发组“——可重用·松耦合·契约·抽象·复用·自治·无状态·可发现·可组合（常考精简版”七大特性”：重用 / 松耦合 / 契约 / 无状态 / 可发现 / 自治 / 可组合）。

SOA 关键技术

技术 角色
Web Service SOA 经典实现，三件套 = SOAP（XML 消息协议，含 Envelope/Header/Body）+ WSDL（服务契约描述）+ UDDI（服务注册与发现，黄页）
REST 轻量实现，资源 + HTTP（无状态 / 统一接口 / 分层 / 可缓存）
ESB（企业服务总线） SOA 的核心基础设施，一身六艺：消息路由 / 协议转换（SOAP↔REST↔JMS）/ 消息变换（XSLT）/ 服务编排 / 监控治理 / 安全（WS-Security）
BPEL 业务流程执行语言，基于 XML 编排 Web Service 的顺序 / 并行 / 异常
UDDI 服务注册中心，支持白页（名称）/ 黄页（分类）/ 绿页（技术细节）查询

SOA 参考体系结构（5 层）：业务流程层（BPEL 编排 / BPMN 建模）→ 服务层（业务服务 / 企业服务）→ 服务组件层（EJB / Spring Bean）→ 应用层（现有应用系统）→ 资源层（数据库 / 消息 / 文件 / 遗留系统）。

服务编排（Orchestration）vs 服务编制 / 协同（Choreography）

维度 编排 Orchestration 编制 / 协同 Choreography
控制中心 集中（中央编排引擎，如 BPEL/BPMN） 去中心化（无中心，靠消息约定 / 事件协作）
视角 单一控制者视角 多方对等协作视角
可追溯性 强（流程实例全程可见） 弱（需事件日志拼接）
灵活性 控制者改流程图即可 需多方协商改接口
适用 跨部门企业内流程（如”开办企业一件事”） 跨企业 B2B 协同

服务粒度

  • 粗粒度（SOA 倾向）：业务级 / 企业级服务，一个服务对应一个完整业务能力闭环；
  • 细粒度（微服务更细）：围绕业务子域、单一职责拆分。
  • 粒度评估三维度：业务能力闭环度 + 复用度 + 自治度（独立数据 / 独立部署 / 独立演进）。
  • 陷阱：粒度过粗 → 失去复用与自治、变更面大；粒度过细 → 网络开销、一致性复杂度、运维复杂度暴增。粒度不是越小越好。

SOA vs 微服务 vs 单体（必考对比表）

维度 单体 Monolith SOA 微服务 Microservices
服务粒度 无（一个进程） 粗粒度（企业级业务服务） 细粒度（围绕限界上下文 / 单一职责）
通信 进程内方法调用 ESB”智能管道”（SOAP/WS-* 重量级） 轻量 REST/gRPC/MQ”哑管道智能端点”
数据 单一共享库 常共享 / 集成数据库（也可服务私有） Database Per Service（红线，库私有，接口交换）
治理 无 集中（ESB 内置路由 / 编排 / 监控 / 安全） 去中心化（注册中心 + 客户端 + Service Mesh Sidecar）
部署 整体打包、整体上线 偏集中（重量级应用服务器） 独立部署（容器 / K8s，每服务独立发布）
技术栈 统一 偏统一 / 企业级（Java/.NET + WS-* + XML） 异构自由（每服务可选最合适技术）
组织 单团队 / 多职能 中心化架构组 + 总线团队 自治小团队（康威定律，Two-Pizza Team）
演进 — 自顶向下集中规划 自底向上演进
适用场景 小团队 MVP、事务边界强、变更频率低 企业级异构系统集成、跨部门流程编排、强协议适配 互联网规模、业务领域清晰、需独立部署 / 弹性扩缩、团队较大

结论：微服务是 SOA”服务化”思想的延续，但走向”细粒度、去中心化、轻量化（哑管道）、技术异构、Database Per Service、容器化“——可以理解为微服务是 SOA 的一种实践演进。Service Mesh（Istio + Sidecar）则把治理能力下沉到基础设施层，相当于”分布式的、无单点的 ESB”。

单体架构（Monolith）

  • 优点：开发简单、调试方便、IDE 重构友好、跨模块本地事务天然强一致、部署单元少。
  • 缺点：模块强耦合、代码库膨胀、编译 / 测试 / 发布慢、任一模块故障拖垮全局、无法按模块独立扩展、技术栈被锁死、技术债累积。
  • 演化工具：
    • 绞杀者模式（Strangler Fig）：在新系统外面”长出”新功能逐步接管老系统能力，老系统功能逐个被”绞杀”直至退役，避免大爆炸式重写；
    • 防腐层（ACL，Anti-Corruption Layer）：在新服务与老系统 / 异构系统之间加一层翻译，把老系统的数据模型转换为新服务的领域模型，保持新服务”领域纯净”。

架构演化的路径与策略

① 演化路径：单体 → 模块化单体（先把模块边界理清）→ SOA / 微服务 → 云原生（容器 + Service Mesh + Serverless）。

② 上云路径（6R 框架）：

策略 含义 代价 / 收益
Rehost 搬迁（lift-and-shift），原样迁到云上虚拟机 最快、改动最小、不享云原生红利
Replatform 小修改上云（如换托管数据库 RDS、托管 MQ） 中等改动，部分享受托管服务红利
Repurchase 换 SaaS（如自建 CRM → 改用 Salesforce） 不再自维护，受限于 SaaS 能力
Refactor / Re-architect 重构为云原生（微服务 + 容器 + Serverless） 改动最大、周期长、彻底享云红利
Retire 淘汰（评估发现已无价值的系统直接下线） 减负
Retain 保留（暂不动，待时机 / 合规约束） 维持现状

③ 演化原则：先共性后差异、先冷数据后热数据、先边缘后核心（先无状态服务后有状态服务、先读后写）、增量演化（绞杀者，不要 big bang）、双写 / 灰度迁移（新老并行、老系统为权威源，灰度 1%→10%→50%→100%）、数据迁移与一致性校验（CDC 同步 + 每日全量比对 + 差异告警 + 修复脚本）、可回滚（一键回到老路径、RPO=0）。

遗留系统（Legacy）评估与策略（”业务价值 × 技术价值”四象限）

业务价值高 业务价值低
技术价值高 改造 / 演化（重构 + 渐进微服务化，价值最大） 集成 / 封装（用 Wrapper 包成服务对外暴露，原样保留）
技术价值低 改造或重建（业务关键但技术老旧，绞杀者逐步替换 / 必要时重写） 淘汰（业务和技术双低，下线退役）

四种处理手段（教材）：① 淘汰（Discard）；② 继承 / 封装（用 Wrapper / 适配器包成 Web Service，最快但难治本）；③ 改造 / 重构（Re-engineering）；④ 集成 / 接口对接（与新系统通过接口协作）。遗留系统 SOA 化路径还可”数据先行”——先建主数据 / 元数据 / 参考数据共享服务，统一数据再治应用。

架构演化的度量与时机

何时该演化？看信号：技术债积压（耦合度高、循环依赖多、发布失败率高）、变更频率热点（某模块改动远高于其它）、性能 / 可用性瓶颈（数据库扩容到顶、单点 ESB 接近 TPS 上限、故障频发）、新业务无法承载（新需求开发数月仍上不了线）、组织变化（团队扩张 → 康威定律倒逼架构调整）。

二、高频选择题（18 题，✅ 为正确选项）

1. 下列关于 SOA 核心思想描述错误的是：

A. 以”服务”为基本构建单元　B. 服务之间松耦合　C. SOA 倾向粗粒度服务　✅ D. 服务必须细粒度，越小越好

“越小越好”是常见误区；粗粒度才是 SOA 倾向，过细引发分布式复杂度。

2. 下列不属于 SOA 设计原则的是：

A. 服务无状态　B. 服务契约标准化　C. 服务自治　✅ D. 服务强耦合以提升性能

SOA 强调松耦合；强耦合违背 SOA 根本理念。

3. Web Service 三要素是：

A. HTTP / JSON / REST　✅ B. SOAP / WSDL / UDDI　C. XML / XSLT / XSD　D. gRPC / Protobuf / Etcd

SOAP 传输、WSDL 描述契约、UDDI 注册发现，是 SOA 经典实现的三件套。

4. WSDL 在 SOA 中的作用是：

✅ A. 描述服务契约（操作、消息、绑定、端点），实现跨语言互通　B. 加密 SOAP 消息　C. 注册服务到目录　D. 编排业务流程

WSDL 是契约描述语言；加密是 WS-Security，注册是 UDDI，编排是 BPEL。

5. ESB（企业服务总线）在 SOA 中的核心作用不包括：

A. 消息路由　B. 协议转换　C. 服务编排与监控治理　✅ D. 承载核心业务逻辑实现

ESB 是”管道 + 中介”，不应塞业务逻辑；业务逻辑在服务里。

6. 关于服务编排（Orchestration）与服务编制 / 协同（Choreography），描述正确的是：

✅ A. 编排是中心化指挥（如 BPEL 引擎），编制是去中心化协作（靠消息 / 事件约定）　B. 二者完全等价　C. 编排没有中央控制者　D. 编制可追溯性比编排强

编排集中、可追溯性强、适合企业内流程；编制去中心、适合跨企业 B2B 协同。

7. BPEL 是用于：

A. 描述服务契约　✅ B. 业务流程编排（基于 XML 编排 Web Service 的顺序 / 并行 / 异常）　C. 服务注册　D. 消息加密

BPEL = Business Process Execution Language，运行在编排引擎上。

8. 关于 SOA 与微服务的服务粒度，描述正确的是：

A. SOA 粒度比微服务更细　✅ B. SOA 倾向粗粒度（企业级业务服务），微服务围绕限界上下文更细　C. 二者粒度完全一致　D. 微服务必须比 SOA 粗

微服务的服务粒度通常细于 SOA。

9. 下列关于 SOA、微服务、单体的通信方式对比正确的是：

A. 单体靠 ESB 通信　✅ B. SOA 靠 ESB”智能管道”，微服务靠轻量 REST/gRPC/MQ”哑管道智能端点”　C. 微服务强制使用 ESB　D. 单体使用 SOAP/WS-*

微服务核心理念之一就是”智能端点 + 哑管道”，去 ESB 化。

10. 关于数据策略，下列对比错误的是：

A. 微服务强调 Database Per Service　B. SOA 中常见共享 / 集成数据库　C. 单体使用单一共享库　✅ D. 微服务倾向多服务共用一个数据库

Database Per Service 是微服务的红线，服务间通过接口交换数据，不共享库。

11. 关于治理模式，下列描述正确的是：

✅ A. SOA 集中治理（ESB 内置路由 / 监控 / 安全），微服务去中心化治理（注册中心 + Sidecar）　B. SOA 去中心化、微服务集中化　C. 二者都依赖 ESB　D. 微服务不需要任何治理

微服务把治理下沉到客户端 / Service Mesh Sidecar，避免 ESB 单点。

12. 下列关于单体架构描述错误的是：

A. 开发调试简单，跨模块本地事务天然强一致　B. 模块强耦合，发布慢　C. 任一模块故障可能拖垮全局　✅ D. 可以按模块独立扩展、独立部署

单体只能整体扩展、整体部署，这正是它的缺点。

13. **绞杀者模式（Strangler Fig）**的核心思想是：

A. 一次性重写整个老系统　✅ B. 在新系统外逐步接管老系统功能，老系统功能逐个被替换直至退役　C. 永远保留老系统不动　D. 直接删除老系统

绞杀者 = 渐进式增量演化，避免”大爆炸式重写”风险。

14. **防腐层（ACL，Anti-Corruption Layer）**的作用是：

✅ A. 在新服务与老 / 异构系统之间做模型翻译，隔离老系统数据模型，保持新服务领域纯净　B. 加密系统间通信　C. 做服务注册发现　D. 替代 API 网关

ACL 是 DDD 中处理遗留 / 外部系统集成的模式。

15. 上云 6R 框架中，”Rehost”指的是：

✅ A. 搬迁（lift-and-shift），原样迁移到云上虚拟机，改动最小　B. 重构为云原生微服务　C. 换成 SaaS 产品　D. 直接淘汰下线

Refactor/Re-architect 才是重构云原生；Repurchase 才是换 SaaS；Retire 是淘汰。

16. 下列关于架构演化原则描述错误的是：

A. 增量演化（绞杀者），不要 big bang 重写　B. 先冷数据后热数据、先边缘后核心　C. 灰度迁移 1%→10%→50%→100% 并保证可回滚　✅ D. 先迁核心交易再迁边缘业务，一次切流到 100%

应”先边缘后核心、灰度递增、可回滚”，一次切 100% 风险极高。

17. 按”业务价值 × 技术价值”四象限评估遗留系统，业务价值低、技术价值高的系统应：

A. 直接淘汰　B. 全面重写　✅ C. 集成 / 封装（用 Wrapper 包成服务对外暴露，原样保留）　D. 立即迁移上云重构

技术尚可、业务不重要 → 封装集成最划算；业务和技术双低才淘汰。

18. 单体拆分微服务做数据库拆分时，下列做法正确的是：

A. 直接停机一次性切库　✅ B. 双写过渡（老库为权威源）+ CDC 同步 + 每日数据一致性校验 + 可回滚　C. 新老服务继续共用一个库　D. 不做任何一致性校验

双写 + CDC（如 Canal 监听 binlog）+ 对账兜底 + 一键回滚是数据迁移的标准套路。

原文 + 解析：exam-bank/10-architecture-styles.md 与 exam-bank/15-microservice-cloud-native.md

三、案例答题套路（25 分）

“SOA 改造 / 单体→微服务 / 上云 / 遗留系统演化”案例题的七步答题套路：

  1. 现状与痛点分析：耦合度高、发布慢需停机、无法弹性扩展、技术债累积、数据库 / ESB 扩容到顶、新业务数月上不了线——逐条引用题干的数字（代码行数、发布频率、QPS、连接数）。
  2. 目标架构选型：为什么选微服务 / SOA / 上云？给量化目标（QPS 从 5k→50k、发布从月级→小时级、可用性 99.95%、MTTR 从小时→分钟）。异构集成多 → SOA 主干 + ESB；互联网规模 / 团队大 → 微服务；并存复杂 → 混合架构。
  3. 演化路径设计：绞杀者模式增量迁移——先共性服务（用户 / 主数据）→ 边缘业务 → 核心业务；模块拆分顺序与依据 = DDD 限界上下文；给三阶段路线图（短期稳定 / 中期拆分 / 长期演化）。
  4. 数据迁移与一致性：Database Per Service 垂直拆库；双写 + 灰度 + CDC（Canal）同步 + 每日数据校验 + 差异修复 + 可回滚；老库为权威源直至切换完成。
  5. 过渡期共存：防腐层 ACL 隔离新老数据模型；ESB / API 网关桥接新旧系统（新功能走新服务、老功能继续老系统）；CDC 让新老数据近实时同步。
  6. 治理与可观测：注册中心（Nacos）+ 网关（Spring Cloud Gateway）+ 熔断限流（Sentinel）+ 链路追踪（SkyWalking）+ 日志 / 指标（ELK + Prometheus）；SOA 场景叠加 SLA 监控、服务目录、契约版本治理。
  7. 风险与回滚预案：双写不一致 → 对账 + 修复脚本；组织阻力 → 先调团队（康威定律）；演化 ROI 不可见 → DORA 四指标 + 月度演化汇报；一键回滚（3 分钟回老路径）。

万能高分句

  • “采用**绞杀者模式（Strangler Fig）**渐进式替换，避免’大爆炸’式重写风险，每阶段评审 ROI”
  • “依据 DDD 限界上下文拆分服务，遵循’先共性后差异、先边缘后核心、先冷数据后热数据’”
  • “数据库拆分采用 Database Per Service，迁移期’双写 + CDC（Canal）+ 每日对账 + 一键回滚‘保证 RPO=0”
  • “过渡期通过**防腐层（ACL）**隔离老系统数据模型、API 网关 / ESB 桥接新旧路由”
  • “遵循康威定律，先调组织（组建领域团队、任命 Tech Lead）再调架构”
  • “对遗留系统按’业务价值 × 技术价值’四象限分类，分别采取淘汰 / 封装 / 改造 / 集成”
  • 上云不要一刀切重构——按 6R（Rehost/Replatform/Repurchase/Refactor/Retire/Retain）分批迁移

常见陷阱

❌ ✅
一把梭重写（big bang） 绞杀者模式渐进演化
不给演化顺序 明确”先共性 → 边缘 → 核心“+ 三阶段路线图
不谈数据迁移一致性 双写 + CDC + 对账 + 可回滚必写
ESB / 网关里塞业务逻辑 ESB / 网关只做路由 / 适配 / 编排，业务在服务里
只改技术不调组织 康威定律：先调组织
把 SOA 和微服务画等号 讲清粒度 / 通信 / 数据 / 治理 / 部署五维差异
改造完直接退役老系统 双轨期共存 + 灰度切流，确认稳定再退役
不引题干数字 引用 QPS / 代码行数 / 发布频率 / 连接数

四、完整模拟案例题（25 分）

⚠️ 自主命题改编，题干为基于公开考点改编的虚构案例，技术参数贴合真实工程实践。建议严格 25 分钟限时作答。相关延伸：case-types/03-style-comparison.md（含 SOA vs 微服务选型）与 paper-topics/09-architecture-evolution.md。

【题干】 某省级国资集团下属”惠通供应链服务平台”于 2012 年建成，承接集团 23 家成员单位的采购、招标、合同、供应商管理业务，年交易额 380 亿，注册供应商 6.2 万家，日均订单 14 万笔。技术现状：基于 .NET Framework 4.0 + WCF + Oracle 11g 的集中式单体（约 320 万行代码、2800 个接口、960 张表，3 台物理机本地机房），早期为对接成员单位老 ERP 引入过一套 Oracle Service Bus（OSB）做 SOA 集成，现已老化。痛点：① 任一模块改动都要整体编译（单次 50 分钟）+ 回归测试 2 天，仅每月最后一个周日凌晨停机上线，年发布 12 次；② 招标模块旺季高并发常拖垮整个平台，2024 年 OOM 故障 6 次、单次影响 3.5 小时；③ Oracle 单库连接数常态 900 / 峰值 1600，CPU 80%+，已无扩容空间；④ 集团要求新上线”供应链金融”和”碳排放溯源”两条新业务，研发了 7 个月仍上不了线；⑤ 集团 IT 战略要求”两年内迁移到政务云、核心系统去 .NET 化、采用信创栈”；⑥ 成员单位 ERP 异构（11 家 SAP、6 家用友、4 家 Oracle EBS、2 家自研），协议有 SOAP/REST/文件交换混杂。项目周期 24 个月，团队 48 人（含 18 名成员单位对接专员，A 公司主导 + B/C 分包）。

问 1（7 分）：给出目标架构定位与选型理由——是纯微服务、纯 SOA 升级、还是混合架构？为什么？给量化目标。

问 2（7 分）：设计演化路径与服务拆分顺序——用绞杀者模式怎么走？先拆什么、后拆什么、依据什么？给三阶段路线。

问 3（6 分）：设计数据库拆分与迁移一致性方案——怎么从 Oracle 单库拆到 Database Per Service？迁移期如何保证数据一致、如何回滚？

问 4（5 分）：设计过渡期新旧系统共存方案与回滚预案——新服务怎么和老 .NET 单体 / 成员单位异构 ERP 共存？

【参考答案要点】

问 1 —— 混合架构 = 微服务主干 + SOA/ESB 集成层 + 事件驱动旁路。

  • 微服务主干：自身业务（采购 / 招标 / 合同 / 供应商 / 供应链金融 / 碳排放溯源）按 DDD 限界上下文拆为细粒度微服务，跑在政务云容器（K8s）上，技术栈 Java + Spring Cloud Alibaba（信创 ARM + 麒麟兼容），去 .NET 化。
  • SOA/ESB 集成层：保留并升级一套轻量 ESB（如 Apache ServiceMix + Camel）专门对接 23 家成员单位异构 ERP（SAP/用友/Oracle EBS/自研，SOAP/REST/文件混杂）——异构集成正是 SOA/ESB 的强项，微服务每家加 Sidecar 反增复杂度。
  • 事件驱动旁路：订单状态变更、审计日志、对账走 RocketMQ，高并发查询走 CQRS 读写分离。
  • 量化目标：发布频率月级→日级（≥10 次/日）；招标旺季 QPS 承载 3 万（独立扩缩、不拖垮全局）；可用性 99.95%；MTTR 3.5h→15min；新业务上线周期 7 个月→2 周；Oracle 单库压力下降到拆库后各库 < 300 连接。

问 2 —— 绞杀者模式 + DDD 限界上下文，先共性后差异、先边缘后核心：

  • 阶段一（0-6 月，稳定 + 抽公共）：上线 API 网关（Spring Cloud Gateway）作为流量切换枢纽，所有新请求经网关路由；完善监控（SkyWalking + Prometheus）+ 自动化回归；先把共性服务（用户 / 权限 / 供应商主数据 / 通知 / 文件）拆出来上云（无状态、被多场景复用、风险低）。
  • 阶段二（6-18 月，绞杀边缘 + 核心域）：按 DDD 限界上下文，先绞杀边缘业务（供应商门户、报表、消息中心），再绞杀核心域（采购单、招标、合同）——网关按功能灰度切流（新功能走新服务、老功能继续老 .NET 单体），灰度 1%→10%→50%→100%，每周切 1-2 个功能；同步上线新业务（供应链金融、碳排放溯源）直接以微服务建设。
  • 阶段三（18-24 月，收尾 + 退役）：剩余功能全部迁移，老 Oracle 单库 + .NET 单体逐步退役；ESB 集成层稳定运行专做成员单位对接；引入 Service Mesh（可选）做精细流量治理。
  • 拆分依据：限界上下文 + 业务能力闭环 + 复用度 + 自治度；强事务、变更频率低的（如合同盖章 + 财务挂账）可先包成”合同核心”模块，二期再评估是否拆——避免一上来就把强事务边界硬拆成分布式事务。

问 3 —— Database Per Service 垂直拆库 + 双写 + CDC + 对账 + 可回滚：

  • 拆库：按限界上下文把 Oracle 单库的 960 张表垂直切分为各服务私有库（采购库 / 招标库 / 合同库 / 供应商库 / 金融库等），高并发库再做分库分表（如供应商库按 supplier_id 哈希 16 库 64 表）；服务间不共享库，跨库查询走 ES / 数据中台聚合。
  • 迁移：每个服务迁移期双写——新服务同时写新库和老 Oracle（老库为权威源）；用 **CDC（如 Canal/OGG 监听 binlog/redo log）**把老库增量同步到新库做兜底；每日全量比对新老库关键表，差异告警 + 自动修复脚本 + 必要时人工介入。
  • 切换：读流量先灰度切到新库（1%→100%），观察一周无差异后写流量切到新库为权威源，再下线双写。
  • 回滚：任一步异常，网关一键把路由切回老 .NET 单体 + 老 Oracle（3 分钟内），新库数据可丢弃重来，RPO=0。

问 4 —— API 网关桥接 + 防腐层 ACL + ESB 适配 + CDC 同步 + 一键回滚：

  • 新服务 ↔ 老 .NET 单体：API 网关做路由桥接（已迁的走新服务、未迁的走老单体）；新服务调用老单体能力时通过防腐层 ACL 把老单体的 WCF/数据模型翻译成新服务领域模型；老单体读新数据通过 CDC 反向同步或调新服务接口。
  • 新服务 ↔ 成员单位异构 ERP：统一走 ESB 集成层（ServiceMix + Camel）做协议转换（SOAP↔REST↔文件）+ 消息路由，新服务和老单体都只对接 ESB，不直接对接 23 家 ERP。
  • 数据双轨期一致性：双写 + CDC + 每日对账（同问 3）。
  • 回滚预案：① 功能级——网关路由开关，单功能 3 分钟回切老单体；② 数据级——新库可丢弃，老 Oracle 始终保权威；③ 整体级——保留老机房 .NET 单体热备至阶段三结束才退役；④ 演化看板——DORA 四指标 + 月度汇报，ROI 不达预期可暂停某域演化。

五、论文万能提纲（约 2500 字）

典型题目：论 SOA 及其应用 / 论企业服务总线（ESB）的应用 / 论软件架构的演化 / 论遗留系统的改造与迁移 / 论单体到微服务的架构演进 / 论系统迁移上云。

1
2
3
4
5
6
7
8
9
10
11
摘要（300 字，直接给"项目 + 角色 + 成果 + 量化"四要素）
1. 项目背景（350 字）— 老架构瓶颈（耦合高、发布慢需停机、无法弹性、数据库扩容到顶、新业务上不了线、IT 战略要求上云去 X 化）→ 演化目标
2. 核心理论（400 字）— SOA 设计原则 + SOA/微服务/单体三维对比 + 绞杀者模式 + 防腐层 ACL + 上云 6R + 遗留系统四象限 + 康威定律
3. 实践论述（1600 字，分 6 要点）⭐⭐⭐⭐⭐
   (1) 目标架构选型：为什么混合架构（微服务主干 + SOA/ESB 集成层 + 事件驱动旁路），给量化目标
   (2) 绞杀者增量演化路径：API 网关做切换枢纽，先共性服务 → 边缘业务 → 核心域，三阶段路线（短稳定 / 中拆分 / 长退役），拆分依据 DDD 限界上下文
   (3) Database Per Service 拆库 + 双写/灰度迁移 + CDC 同步 + 每日对账 + 一键回滚（RPO=0）
   (4) 过渡期共存：防腐层 ACL 隔离老系统数据模型 / API 网关 / ESB 桥接新旧 / CDC 同步
   (5) 治理与可观测：注册中心 + 网关 + 熔断限流 + 链路追踪 + 日志指标三支柱（SOA 场景叠加 SLA / 服务目录 / 契约版本治理）
   (6) 风险与回滚：双写不一致→对账兜底 / 组织阻力→康威定律先调团队 / ROI 不可见→DORA 指标 + 月度汇报 / 一键回滚
4. 权衡与展望（250 字）— 增量演化周期长 vs big bang 风险 / 强一致 vs 性能 / 保留合理单体 vs 全微服务；成效 + 教训

摘要模板：”我于 {2023} 年主导了 {国资集团供应链平台 / 银行核心外围 / 政务一网通办} 的架构演化与上云项目，担任 {演化架构师}。原系统 {.NET 单体 320 万行 / 月发布 1 次 / Oracle 单库 1600 连接到顶 / 新业务 7 个月上不了线}。本文以该项目为背景，论述演化实践：基于绞杀者模式 + API 网关流量切换 + DDD 重新拆分 + Database Per Service 拆库 + 双写/CDC 数据迁移 + 防腐层 ACL 过渡 + 保留 SOA/ESB 集成层对接异构 ERP，分三阶段（短期稳定 / 中期拆分 / 长期退役）渐进式演化上云。最终发布频率月级→日级、招标旺季 QPS 承载 3 万、MTTR 3.5h→15min、新业务上线 7m→2w、零停机演化、迁移代码 280 万行。”

4 段式提纲要点：

  • 背景段（350 字）：业务定位、用户规模（注册供应商 6.2 万 / 日均订单 14 万）、团队配置（48 人含 18 对接专员，跨 3 公司）、周期（24 个月）、关键质量属性（可修改性、可扩展性、可用性、零停机、信创合规）、老架构瓶颈与 IT 战略驱动。
  • 理论段（400 字）：SOA 设计原则（松耦合 / 契约 / 抽象 / 复用 / 自治 / 无状态 / 可发现 / 可组合）+ SOA/微服务/单体三维对比表（粒度 / 通信 / 数据 / 治理 / 部署）+ 绞杀者模式 + 防腐层 ACL + 上云 6R + 遗留系统四象限（业务价值 × 技术价值）+ 康威定律 + ESB 六艺。
  • 实践段（1600 字，六要点见上面框架）：每点都要落到本项目具体模块 + 给量化数字，别堆名词。
  • 权衡与展望段（250 字）：增量演化周期长（24 个月）但风险可控 vs big bang 重写快但风险极高 → 选增量；强一致（XA/TCC）稳但慢 vs 最终一致（MQ/本地消息表）快但需对账 → 核心交易强一致、辅助场景最终一致；保留合理单体（合同盖章 + 财务挂账事务边界强）vs 全微服务 → 保留；展望：Service Mesh + GitOps + AIOps。

加分关键词：SOA 设计原则、ESB、SOAP/WSDL/UDDI、BPEL、编排（Orchestration）/ 编制（Choreography）、限界上下文、Database Per Service、绞杀者模式（Strangler Fig）、防腐层 ACL、6R（Rehost/Replatform/Repurchase/Refactor/Retire/Retain）、双写迁移、CDC（Canal）、灰度发布、康威定律、DORA 四指标；业界对标：Oracle SOA Suite、IBM WebSphere ESB、Netflix Strangler、Amazon SOA→微服务、阿里中台、招行 6+1、政务一网通办。

避坑：①不要 big bang 重写 → 绞杀者渐进演化必写；②SOA = 微服务 → 讲清五维差异；③不提 ESB / 契约 → ESB 是 SOA 核心枢纽、WSDL/OpenAPI 契约是 SOA 根基；④不调组织只改技术 → 康威定律先调团队；⑤不谈数据迁移一致性与回滚 → 双写 + CDC + 对账 + 一键回滚是底线；⑥上云一刀切重构 → 按 6R 分批；⑦否定 SOA 价值 → 演进不是推翻，异构集成场景 SOA/ESB 仍有不可替代的价值。

完整理论 + 模拟论文 + 提纲：paper-topics/07-soa.md 与 paper-topics/09-architecture-evolution.md；范文参考：paper-samples/05-microservice-cloud-native.md

软考专题系列第 15 篇（”DevOps·Serverless / 企业集成 / 嵌入式 / SOA·演化”这一组收官）。同组：DevOps 与 Serverless · 企业应用集成 · 嵌入式系统架构。完整专题清单见 软考导览页。发现题目错误欢迎到 仓库 开 issue。