本页目录 · 5 节
第 15 章 面向服务架构设计理论与实践
对应大纲：科目 1-14 面向服务架构设计理论与实践｜教材 P512–P540｜优先级 ★★★★｜综合知识估分 2～4 分
读法：先背「三角色＋三操作」地基图，再给 UDDI／WSDL／SOAP／REST 各配一句作用，最后用「注册表／ESB／微服务」三种模式去套案例题。
一、知识框架
面向服务架构 SOA
├─ 15.1 概念：定义｜服务特征｜三角色｜三操作｜BPEL
├─ 15.2 历史：Web 服务→ESB→微服务云原生｜国内现状
├─ 15.3 参考架构：业务流程｜服务｜服务组件｜应用｜基础设施＋横切
├─ 15.4 协议规范：UDDI｜WSDL｜SOAP｜REST
├─ 15.5 标准要求：文档｜协议｜统一登记集成｜QoS
├─ 15.6 作用：复用｜松耦合｜异构集成｜业务敏捷
├─ 15.7 原则：无状态｜粗粒度｜松耦合｜契约化｜自治
├─ 15.8 模式：服务注册表｜ESB｜微服务
├─ 15.9 注意：集成边界｜粒度｜无状态｜版本与事务
└─ 15.10 实施：选方案｜业务流程分析｜服务建模｜治理二、必背要点
15.1 SOA 相关概念
定义：SOA 是一种设计方式，把应用的功能单元（服务）通过良好定义的接口与契约组装起来；接口中立定义，独立于硬件平台、操作系统与编程语言，使异构系统以统一方式交互。
| 角色 | 职责 | 对应操作 |
|---|---|---|
| 服务提供者 | 实现并维护服务，承诺契约与质量 | 发布、响应调用 |
| 服务请求者 | 需要功能的一方，可为人或程序 | 查找、绑定调用 |
| 服务注册中心 | 保存服务描述，供检索 | 接收发布、提供查询 |
三操作连成一句：提供者发布 → 请求者查找 → 请求者绑定调用。绑定发生在请求者与提供者之间，注册中心不传业务数据。
BPEL：基于 XML 的流程编排语言，把多个已有 Web 服务按业务串成端到端流程，支持顺序、并行、分支、补偿，用 partnerLink 引用 WSDL 接口。一句话：WSDL 管单个服务长什么样，BPEL 管多个服务怎么串成业务。
15.2 发展历史与国内现状
| 阶段 | 特征 | 解决的问题 |
|---|---|---|
| 萌芽期 | XML、SOAP、WSDL、UDDI | 跨平台调用、接口标准化 |
| 集成期 | ESB、服务注册表、BPEL、治理 | 异构系统互联、协议与格式转换 |
| 深化期 | REST/JSON、微服务、容器、网关 | 敏捷交付、独立部署、去中心化 |
国内三条线：政企以 ESB 集成存量系统；服务治理建目录、定 SLA；存量 SOA 逐步微服务化。答题口径：SOA 是方法论，微服务是其轻量落地形态。
15.3 SOA 参考架构
| 层次 | 内容 | 作用 |
|---|---|---|
| 业务流程层 | 流程、编排、业务规则 | 把服务组合成业务流程 |
| 服务层 | 服务接口、契约、实现 | 暴露可复用业务能力 |
| 服务组件层 | 技术组件、适配器 | 支撑实现、屏蔽技术细节 |
| 应用层 | ERP、CRM、遗留系统 | 被复用与被集成对象 |
| 基础设施层 | 网络、主机、中间件、总线 | 运行支撑 |
横切：安全、管理、治理、QoS。规律：越往上越贴近业务、粒度越粗。
15.4 主要协议和规范
UDDI：基于 XML 的服务注册库。白页存机构名称与联系方式，黄页按行业分类索引，绿页存技术模型与访问点。作用是让请求者发现服务，是注册中心的标准实现。
WSDL：用 XML 描述服务「能做什么、怎么调、在哪调」。
| 元素 | 含义 | 归类 |
|---|---|---|
| types | 消息所用数据类型（XML Schema） | 抽象 |
| message | 一次交互的消息抽象 | 抽象 |
| portType | 操作集合，相当于接口 | 抽象 |
| binding | 绑定具体协议与消息格式 | 具体 |
| service | 端口集合，给出访问地址 | 具体 |
口径：前三个讲「接口长什么样」，后两个讲「怎么连、连到哪」；教材「四要素」指 types、message、portType、binding，service 一并写出不扣分。
SOAP：基于 XML 的调用协议，可承载于 HTTP。
| 部分 | 必需性 | 内容 |
|---|---|---|
| Envelope | 必需 | 根元素，标识 SOAP 消息 |
| Header | 可选 | 安全、事务、路由等扩展 |
| Body | 必需 | 调用内容，出错时放 Fault |
REST 六约束：客户端-服务器、无状态、可缓存、统一接口、分层系统、按需代码（可选）。它以资源为中心，URI 定位、HTTP 方法表动作、状态码表结果。
15.5 设计的标准要求
| 要求 | 做法 |
|---|---|
| 文档标准化 | 服务描述、接口文档、SLA 统一模板并随版本归档 |
| 通信协议标准 | 统一 SOAP/REST 版本、消息格式、编码与超时 |
| 统一登记与集成 | 建服务目录，登记归属、版本、依赖、责任人 |
| QoS | 明确响应时间、吞吐、可用性并纳入监控 |
15.6 SOA 的作用
复用存量、松耦合集成异构系统、流程可编排带来业务敏捷、集中监控降低运维成本。
15.7 设计原则
| 原则 | 含义 | 落地手段 |
|---|---|---|
| 无状态 | 服务不保存会话状态 | 状态外置到库/缓存，令牌传递 |
| 粗粒度 | 一次调用完成有业务意义的工作 | 按业务能力聚合 |
| 松耦合 | 依赖契约而非实现 | 接口实现分离、版本兼容 |
| 标准化契约 | 接口、消息、错误码统一 | 契约先行（WSDL/OpenAPI） |
| 服务自治 | 独立开发、部署、演化 | 独立数据与发布流水线 |
15.8 设计模式
| 维度 | 服务注册表模式 | ESB 模式 | 微服务模式 |
|---|---|---|---|
| 调用路径 | 查注册表后直连 | 全部经总线中转 | 经网关或直连 |
| 核心部件 | 注册中心 | 总线 | 网关、注册配置中心 |
| 耦合度 | 较低（须知地址） | 低（只认总线） | 最低（按域自治） |
| 适用 | 服务中等、异构少 | 大量遗留系统集成 | 新建互联网业务 |
| 风险 | 注册中心单点 | 总线瓶颈、厂商锁定 | 分布式事务、链路复杂 |
ESB 五项核心功能：消息路由、协议转换、数据格式转换、服务注册与发现、监控管理。
| 维度 | SOA | 微服务 |
|---|---|---|
| 粒度 | 粗，按业务能力 | 细，按业务域再拆 |
| 通信 | SOAP/WS，常经 ESB | REST/gRPC，轻量直连 |
| 治理 | 集中式（总线、注册表） | 去中心化，服务自治 |
| 部署 | 共享总线，整体发布 | 容器化独立部署 |
| 数据管理 | 常共享数据库 | 每服务独立数据库 |
15.9 构建时应注意的问题
先划集成边界：纳入哪些系统、集成在数据层/接口层/流程层、实时还是批量。边界不清会让总线承担过多职责。
| 粒度控制原则 | 说明 |
|---|---|
| 业务对齐 | 一个服务对应一个业务能力，不按表、不按技术层切 |
| 对外粗、对内细 | 外部接口聚合，内部用细粒度组件组合 |
| 高内聚低耦合 | 常一起变更的功能放在同一服务 |
| 事务可控 | 避免一次业务跨过多服务 |
| 可演进 | 先粗后细，允许随业务拆分 |
无状态好处：任一实例可处理任一请求，无需会话粘滞；实例故障可直接替换；易扩缩容、灰度与缓存。代价是每次请求多一次状态存取。
15.10 实施过程
选择解决方案：评估存量系统与集成需求，确定总线、注册中心、开发平台与治理工具；比较标准兼容性、厂商锁定风险、性能与成本、与既有中间件适配能力。
业务流程分析：业务建模 → 流程梳理与优化 → 服务识别（按业务能力/实体）→ 服务规约（接口、消息、SLA、异常）→ 实现与组装（可用 BPEL 编排）→ 部署与治理。
顺序不能颠倒：先理流程，再定服务；流程没理清就切服务，必然切错粒度。
三、易混淆概念对比
| A | B | 关键区别 |
|---|---|---|
| SOA | 微服务 | SOA 是方法论、可粗可细、常集中治理；微服务是轻量落地，细粒度、去中心化 |
| SOA | Web 服务 | SOA 是架构思想；Web 服务（SOAP/WSDL）只是其早期实现技术 |
| UDDI | 服务注册表 | UDDI 是注册规范；注册表是运行时组件，可用 UDDI 也可自建 |
| WSDL | SOAP | WSDL 描述接口与端点；SOAP 承载一次调用消息 |
| SOAP | REST | SOAP 重、契约强、靠 WSDL；REST 轻、面向资源、靠 HTTP 语义 |
| ESB | 服务注册表 | ESB 中介并转发调用；注册表只给地址描述，不转发数据 |
| 编排 | 编制 | 编排有中心控制者（BPEL 引擎）；编制无中心，各方按事件协作 |
| 粗粒度 | 细粒度 | 粗粒度调用少、复用好、灵活性差；细粒度灵活但链路长、事务难 |
| 有状态 | 无状态 | 有状态需会话粘滞、难扩展；无状态易扩展、状态须外置 |
| 服务 | 构件 | 服务是运行期可发现、可远程调用的业务单元；构件是开发期实现单元 |
四、常见考法与出题角度
| 题型 | 出题角度 | 典型问法 | 答题要点 |
|---|---|---|---|
| 单选 | 三角色职责 | 「谁负责发布服务」 | 提供者；注册中心只登记不调用 |
| 单选 | WSDL 元素 | 「描述操作集合的是」 | portType；binding 是绑协议 |
| 单选 | SOAP 结构 | 「SOAP 必需部分」 | Envelope 与 Body，Header 可选 |
| 单选 | REST 约束 | 「不属于 REST 约束的是」 | 排除「有状态会话」 |
| 单选 | ESB 功能 | 「ESB 核心功能不包括」 | 排除业务计算、数据持久化 |
| 简答 | 概念辨析 | 「SOA 与微服务区别」 | 粒度、通信、治理、部署、数据五维 |
| 简答 | BPEL 作用 | 「BPEL 解决什么问题」 | 多服务编排成流程，非单服务描述 |
案例题角度（四步骨架）
- 定性：抓「多异构系统、接口不一、流程跨部门、重复建设」等信号，判定为 SOA 集成题，写总纲：采用「服务层＋ESB＋注册中心」实现松耦合集成与复用。
- 说角色与调用链：列出提供者（哪些存量系统）、请求者（哪些前端/流程）、注册中心（统一目录）、ESB（协议与格式转换），并写出「发布—查找—绑定」。
- 按问题分点：接口统一（契约与版本）、粒度（按业务能力、对外粗）、集成层次（数据/接口/流程，实时或批量）、QoS（SLA、超时重试、监控）、一致性（避免长事务，用补偿或最终一致）。
- 补治理与演进：服务目录与责任人、上线评审、安全认证与报文加密、后续按业务域微服务化、用 API 网关承接部分总线职责。
论文可用角度：写「某省社保/银行渠道整合」可写：「针对 12 个异构系统接口不一，以 ESB 构建服务层，按业务能力划分 46 个粗粒度服务并登记入统一目录，接口用 WSDL 契约描述、由总线完成协议与报文转换，新渠道接入周期由 3 个月缩短到 3 周。」
五、速记与自测
速记
- 三角色：供、求、注册；三操作：发、查、绑
- 四规范：UDDI 登记、WSDL 描述、SOAP 传信、REST 轻量
- WSDL：类、消、口、绑、服
- SOAP：信封必带、头可选、体必带
- ESB 五功能：路由、协议、格式、注册、监控
- 三模式：注册表直连、总线中转、微服务自治
- 粒度：对外粗、对内细、按业务切
自测
- SOA 中「绑定」发生在哪两方之间？注册中心起什么作用？
- WSDL 的 portType 与 binding 分别描述什么？
- 为什么 SOA 强调服务无状态？
答案：1. 发生在请求者与提供者之间；注册中心只提供描述与地址，不参与调用与数据传输。2. portType 描述抽象操作集合（接口），binding 描述这些操作绑定到何种具体协议与消息格式。3. 任一实例可处理任一请求，便于水平扩展、故障转移、缓存与灰度，避免会话粘滞造成扩展瓶颈。