一、SOA 的概念与定义 ⭐⭐⭐

• ▪▪ ▪ ▪ ▪ ▪ ▪ 服务(Service) ：由服务提供者提供的、满足使用者请求的 业务单元 ；提供者和使用者都是软件代理。

：由服务提供者提供的、满足使用者请求的 业务单元 ；提供者和使用者都是软件代理。

• ▪▪ ▪ ▪ ▪ ▪ ▪ SOA 概念的延伸 ：在 SOA 中，服务概念被泛化， 泛指系统对外提供的功能集 。例：企业实施 SOA 后，财务系统（资金运作的重要环节）向整个企业信息化系统提供财务处理服务，其开放接口即可看作一个服务。

：在 SOA 中，服务概念被泛化， 泛指系统对外提供的功能集 。例：企业实施 SOA 后，财务系统（资金运作的重要环节）向整个企业信息化系统提供财务处理服务，其开放接口即可看作一个服务。

• ▪▪ ▪ ▪ ▪ ▪ ▪ SOA（Service-Oriented Architecture，面向服务的体系结构） 两种公认定义
• ▪▪ ▪ ▪ ▪ ▪ ▪ 应用角度 ：一种 应用框架 ，将业务应用划分为单独的业务功能与流程（即服务），无需依赖应用程序及运行平台即可构建/部署/整合，提高业务灵活性，实现资产重用、便于管理、加快开发与部署。

：一种 应用框架 ，将业务应用划分为单独的业务功能与流程（即服务），无需依赖应用程序及运行平台即可构建/部署/整合，提高业务灵活性，实现资产重用、便于管理、加快开发与部署。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 软件原理角度 ：一个 组件模型 ，将应用的不同功能单元（服务）通过 定义良好的接口与契约 联系起来；接口采用 中立方式 定义，独立于硬件平台、操作系统和编程语言。

：一个 组件模型 ，将应用的不同功能单元（服务）通过 定义良好的接口与契约 联系起来；接口采用 中立方式 定义，独立于硬件平台、操作系统和编程语言。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 架构师视角 ：从软件原理角度（组件模型）定义对日常工作更具指导性。

：从软件原理角度（组件模型）定义对日常工作更具指导性。

考点提示： SOA 两种定义（应用=应用框架；原理=组件模型）是选择题高频点，务必区分。

1.1 业务流程与 BPEL ⭐⭐⭐

• ▪▪ ▪ ▪ ▪ ▪ ▪ 业务流程 ：为实现某种业务目的而进行的一系列动作/流程。

：为实现某种业务目的而进行的一系列动作/流程。

• ▪▪ ▪ ▪ ▪ ▪ ▪ BPEL （Business Process Execution Language for Web Services，面向 Web 服务的业务流程执行语言，亦写 BPEL4WS）：用 Web 服务 定义和执行业务流程 的语言；通过 组合、编排、协调 Web 服务自上而下实现 SOA，将多个 Web 服务组合为一个新的 复合服务（业务流程） 。

（Business Process Execution Language for Web Services，面向 Web 服务的业务流程执行语言，亦写 BPEL4WS）：用 Web 服务 定义和执行业务流程 的语言；通过 组合、编排、协调 Web 服务自上而下实现 SOA，将多个 Web 服务组合为一个新的 复合服务（业务流程） 。

二、SOA 的发展历史 ⭐⭐⭐

起源脉络 ：SOA 概念最初由 Gartner 公司提出，因当时技术与市场条件不具备而未受广泛关注、沉寂了一段时间。为把公司业务打包成独立的、高伸缩性的基于因特网的服务，人们提出了 Web 服务的概念——这可以说是 SOA 的起源 ；后续大量不同平台/语言开发的 Web 服务组件需要有效管理（相互学习交互、安全、复用与可管理性），又推动人们重新找回面向服务的架构并赋予其时代特征。

• ▪▪ ▪ ▪ ▪ ▪ ▪ XML 是 SOA 的基石 ⭐⭐⭐
• ▪▪ ▪ ▪ ▪ ▪ ▪ XML 系 W3C 创建，源自 SGML （标准通用标记语言）；SGML 比较复杂、实施成本很高，长期只用于大公司之间； XML 实施成本几乎和 HTML 一样 ，可将任何文档转换为 XML 格式跨越因特网传输。
• ▪▪ ▪ ▪ ▪ ▪ ▪ XSD（Schema） ：保障消息数据的 完整性和有效性 。

：保障消息数据的 完整性和有效性 。

• ▪▪ ▪ ▪ ▪ ▪ ▪ XSLT ：使不同数据表达能通过 Schema 映射互相通信，接收方可容易地解析和抽取 XML 数据。

：使不同数据表达能通过 Schema 映射互相通信，接收方可容易地解析和抽取 XML 数据。

• ▪▪ ▪ ▪ ▪ ▪ ▪ Web 服务三剑客 ⭐⭐⭐：简单对象访问协议 SOAP 、Web 服务描述语言 WSDL 、统一描述、发现和集成协议 UDDI 。

⭐⭐⭐：简单对象访问协议 SOAP 、Web 服务描述语言 WSDL 、统一描述、发现和集成协议 UDDI 。

• ▪▪ ▪ ▪ ▪ ▪ ▪ SCA / SDO ：构成 SOA 编程模型的基础 ； WS-Policy 建立 SOA 组件之间安全交互的规范。

：构成 SOA 编程模型的基础 ； WS-Policy 建立 SOA 组件之间安全交互的规范。

考点提示： 三阶段标志（XML → Web 服务三剑客 → SCA/SDO/WS-Policy）及"XML 是 SOA 基石"为选择题考点 ⭐⭐。

2.1 国内 vs 国外对比 ⭐⭐

• ▪▪ ▪ ▪ ▪ ▪ ▪ IDC 2007 年《SOA 中国路线图》 ：国际研究机构首次基于中国 IT 背景做的权威解读。
• ▪▪ ▪ ▪ ▪ ▪ ▪ 美国 ：SOA 关键任务是 对已有系统功能提取与包装 成标准服务。
• ▪▪ ▪ ▪ ▪ ▪ ▪ 中国 ：近 30 年多为生产型系统，服务型系统未大规模建设， 大量"服务"需全新构造 。
• ▪▪ ▪ ▪ ▪ ▪ ▪ 指出 中美 IT 系统根本性问题不同 ：国内以"构建支撑某业务的应用系统"为主，配"三阶段"多还处于第一阶段，第二阶段也才起步。
• ▪▪ ▪ ▪ ▪ ▪ ▪ 为国内大型集团化企业指明如何解决 系统集成与系统构建的融合性问题 （基于 SOA 方式的解决方案）。

三、SOA 与微服务 ⭐⭐⭐⭐

结构说明： 本节为教材两处内容的合并整理—— 「SOA 的微服务化发展」 （SOA vs 微服务区别）与 「微服务架构模式」 （概述/优势/设计模式/挑战）。

3.1 SOA vs 微服务区别

核心结论： 微服务架构是 SOA 架构思想的扩展，更加强调服务个体的独立性、拆分粒度更小。应用系统架构演进路线：为适应日益增长的用户访问量和产品快速更新迭代，经历 从单体架构 → SOA 架构 → 微服务架构 的演进（SOA 向更细粒度、更通用化方向发展即为微服务）。

3.2 微服务架构概述 ⭐⭐⭐

微服务架构将一个大型的单个应用或服务拆分成多个微服务， 可扩展单个组件而不是整个应用程序堆栈 ，从而满足 服务等级协议（SLA） ；围绕业务领域将服务拆分，每个服务可独立开发、管理和迭代，彼此使用统一接口交流，实现分散组件中的部署、管理与服务功能，使产品交付更简单，达到有效拆分应用、实现敏捷开发与部署的目的。 Amazon、Netflix 等互联网巨头 的成功案例表明微服务架构在大规模企业应用中具有明显优势。

3.3 微服务架构五大优势 ⭐⭐⭐⭐

• ▪▪ ▪ ▪ ▪ ▪ ▪ 复杂应用解耦 ：按业务逻辑分解为多个可管理的分支或服务，避免复杂度不断积累；每个服务专注单一功能、通过良好接口清晰表述服务边界，小规模团队即可掌握，易于保持较高开发效率并易于维护。

：按业务逻辑分解为多个可管理的分支或服务，避免复杂度不断积累；每个服务专注单一功能、通过良好接口清晰表述服务边界，小规模团队即可掌握，易于保持较高开发效率并易于维护。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 独立 ：在软件生命周期中独立开发、测试及部署；具备独立运行进程与独立测试机制（无需建立大范围回归测试）；变更无需编译/部署整个系统应用，可并行发布，降低系统变更给生产环境造成的风险。

：在软件生命周期中独立开发、测试及部署；具备独立运行进程与独立测试机制（无需建立大范围回归测试）；变更无需编译/部署整个系统应用，可并行发布，降低系统变更给生产环境造成的风险。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 技术选型灵活 ：去中心化选型，各团队按业务需求发展状况选择体系架构与技术；功能单一、结构简单，架构转型或技术栈升级面临较低风险，不被长期限制在某个体系架构/技术栈上。

：去中心化选型，各团队按业务需求发展状况选择体系架构与技术；功能单一、结构简单，架构转型或技术栈升级面临较低风险，不被长期限制在某个体系架构/技术栈上。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 容错 ：单体架构中某模块故障极易在整个应用内扩散、造成全局瘫痪；微服务相互独立， 故障隔离在单个服务内 ，其他服务通过 重试、平稳退化 等机制实现应用层容错。

：单体架构中某模块故障极易在整个应用内扩散、造成全局瘫痪；微服务相互独立， 故障隔离在单个服务内 ，其他服务通过 重试、平稳退化 等机制实现应用层容错。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 松耦合、易扩展 ：传统水平扩展需将整个应用完整复制到不同节点、成本高；微服务间松耦合，可按实际需求 独立扩展 ，体现灵活性。

：传统水平扩展需将整个应用完整复制到不同节点、成本高；微服务间松耦合，可按实际需求 独立扩展 ，体现灵活性。

3.4 微服务设计模式 ⭐⭐⭐

3.5 微服务架构面临的挑战 ⭐⭐⭐

• ▪▪ ▪ ▪ ▪ ▪ ▪ 分布式复杂性 ：基于 RPC/消息通信实现微服务间调用， 服务发现与服务调用链跟踪 困难。

：基于 RPC/消息通信实现微服务间调用， 服务发现与服务调用链跟踪 困难。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 分区数据库 ：不同服务拥有不同数据库；受 CAP 原理约束及 NoSQL 数据库高扩展性影响，放弃传统数据库强一致性、转而追求 最终一致性 ，对开发人员提出更高要求。

：不同服务拥有不同数据库；受 CAP 原理约束及 NoSQL 数据库高扩展性影响，放弃传统数据库强一致性、转而追求 最终一致性 ，对开发人员提出更高要求。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 测试挑战 ：可能涉及多个服务，需启动其依赖的 所有服务 （非单体单 API 测试），复杂性不可低估。

：可能涉及多个服务，需启动其依赖的 所有服务 （非单体单 API 测试），复杂性不可低估。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 部署/监控/管理/分发及扩容挑战 。
• ▪▪ ▪ ▪ ▪ ▪ ▪ 取舍原则 ：结合企业开发团队规模、业务需求变化、系统用户群体规模综合评估；当架构已无法再扩展、数据库增长速度过快，且整个团队（产品、设计、研发、测试、运维）都具备微服务思维时，收益才大于成本；若现有架构还能很好地工作，采用微服务不会有太多收益。

：结合企业开发团队规模、业务需求变化、系统用户群体规模综合评估；当架构已无法再扩展、数据库增长速度过快，且整个团队（产品、设计、研发、测试、运维）都具备微服务思维时，收益才大于成本；若现有架构还能很好地工作，采用微服务不会有太多收益。

四、SOA 的参考架构（IBM WebSphere）⭐⭐⭐

IBM WebSphere 业务集成参考架构 ：典型的以 服务为中心 的企业集成架构，采用" 关注点分离 (Separation of Concern) "方法规划企业集成中的各种架构元素；架构元素提供的服务既包括狭义的服务（WSDL 描述），也包括广义的服务（某种能力）。划分为 6 大类

4.1 连接服务-企业服务总线 ESB ⭐⭐⭐⭐

• ▪▪ ▪ ▪ ▪ ▪ ▪ ESB（Enterprise Service Bus，企业服务总线） ：过去消息中间件的发展，以" 总线 "模式管理和简化应用之间的集成拓扑结构，以广为接受的开放标准为基础支持应用在 消息、事件和服务 级别上动态互联互通。

：过去消息中间件的发展，以" 总线 "模式管理和简化应用之间的集成拓扑结构，以广为接受的开放标准为基础支持应用在 消息、事件和服务 级别上动态互联互通。

• ▪▪ ▪ ▪ ▪ ▪ ▪ ESB 是一种架构模式，不能简单地等同于特定的技术或产品 （实现 ESB 需要各种产品在运行时和工具方面的支持）。

（实现 ESB 需要各种产品在运行时和工具方面的支持）。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 描述服务的元数据和 服务注册管理 ；
• ▪▪ ▪ ▪ ▪ ▪ ▪ 在服务请求者和提供者之间 传递数据并对其进行转换 （支持同步、异步等实践中总结出的模式）；
• ▪▪ ▪ ▪ ▪ ▪ ▪ 发现、路由、匹配和选择 的能力，支持服务间动态交互，解耦服务请求者与提供者；

的能力，支持服务间动态交互，解耦服务请求者与提供者；

• ▪▪ ▪ ▪ ▪ ▪ ▪ 高级能力： 安全支持、服务质量保证、可管理性、负载均衡 。
• ▪▪ ▪ ▪ ▪ ▪ ▪ 提供 位置透明 的消息路由和寻址服务；
• ▪▪ ▪ ▪ ▪ ▪ ▪ 支持多种消息传递范型（请求/响应、发布/订阅等）；
• ▪▪ ▪ ▪ ▪ ▪ ▪ 支持多种数据格式及其相互转换；
• ▪▪ ▪ ▪ ▪ ▪ ▪ 典型交互过程 ：服务请求者触发交互、产生服务请求消息并按 ESB 要求标准化 → 发送给服务总线 → ESB 根据请求消息中的 服务名或接口名 查找目的组件并转发 → 处理结果逆向返回请求者。该过程不再是点对点直接交互，而是 事件驱动的消息交互 模式。

：服务请求者触发交互、产生服务请求消息并按 ESB 要求标准化 → 发送给服务总线 → ESB 根据请求消息中的 服务名或接口名 查找目的组件并转发 → 处理结果逆向返回请求者。该过程不再是点对点直接交互，而是 事件驱动的消息交互 模式。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 作用 ：最大限度解耦组件依赖、降低软件系统互连的复杂性；实现 位置透明与协议透明 （连接在总线上的组件无需了解其他组件和应用系统的位置及交互协议）；以中间件方式提供服务容错、负载均衡、QoS 保障和可管理功能。

：最大限度解耦组件依赖、降低软件系统互连的复杂性；实现 位置透明与协议透明 （连接在总线上的组件无需了解其他组件和应用系统的位置及交互协议）；以中间件方式提供服务容错、负载均衡、QoS 保障和可管理功能。

考点提示： ESB 的两套能力清单（基本特征和能力 + 核心功能 6 项）与"位置透明/协议透明"是案例/选择题高频 ⭐⭐⭐。

4.2 参考架构各子服务速记 ⭐⭐

• ▪▪ ▪ ▪ ▪ ▪ ▪ 业务逻辑服务 ：整合已有应用→ 应用和信息访问服务 （可接入服务 On-Ramp：通过 单向、请求/应答、轮询 三种消息通信模式将业务逻辑和数据包装成 ESB 可访问的功能；事件发现服务：将已有应用和数据中的变化通过事件框架发布到 ESB）；整合新开发应用→ 业务应用服务 （组件服务：对象持久化/组件安全管理/事务管理等运行时容器管理；核心服务：内存管理、对象实例化和对象池、性能管理和负载均衡、可用性管理；接口服务：与其他企业系统如应用、数据库、消息系统、管理框架的集成接口）；整合客户和业务伙伴(B2C/B2B)→ 伙伴服务 （社区服务：支持 以交易中心 Trade Hub 为主的集中式管理 和以伙伴为中心的自我管理；文档服务：支持 RosettaNet、EDI、AS1/AS2 等主流格式及交互流程/状态管理；协议服务：传输层支持，含 认证和路由 ）。

：整合已有应用→ 应用和信息访问服务 （可接入服务 On-Ramp：通过 单向、请求/应答、轮询 三种消息通信模式将业务逻辑和数据包装成 ESB 可访问的功能；事件发现服务：将已有应用和数据中的变化通过事件框架发布到 ESB）；整合新开发应用→ 业务应用服务 （组件服务：对象持久化/组件安全管理/事务管理等运行时容器管理；核心服务：内存管理、对象实例化和对象池、性能管理和负载均衡、可用性管理；接口服务：与其他企业系统如应用、数据库、消息系统、管理框架的集成接口）；整合客户和业务伙伴(B2C/B2B)→ 伙伴服务 （社区服务：支持 以交易中心 Trade Hub 为主的集中式管理 和以伙伴为中心的自我管理；文档服务：支持 RosettaNet、EDI、AS1/AS2 等主流格式及交互流程/状态管理；协议服务：传输层支持，含 认证和路由 ）。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 控制服务 ：数据整合→ 信息服务 （联邦：聚合各种类型数据，支持关系型与 XML/文本/内容等非关系型数据且各按自身方式管理；复制：自动实时复制和数据转换、在本地维护副本提供远程数据的本地访问；转换：数据源格式到目标格式的批量或基于记录的转换；搜索：查询检索结构化与非结构化（如 PDF）数据）；流程整合→ 流程服务 （编排：通过预定义流程逻辑控制业务活动执行并帮助从错误中恢复； 事务：保证流程执行中的 ACID 特性——短流程通常采用两阶段提交，长流程一般采用补偿方法 ；人工：将人工活动集成到流程中，管理任务分派、授权和监管）；用户访问整合→ 交互服务 （交付：同一交互逻辑可在图形界面/语音/普及计算消息及桌面/PDA/无线终端等多方式多设备上运行；体验：个性化、协作、单点登录等增强用户体验；资源：安全配置、界面皮肤等运行时交互组件管理）。

：数据整合→ 信息服务 （联邦：聚合各种类型数据，支持关系型与 XML/文本/内容等非关系型数据且各按自身方式管理；复制：自动实时复制和数据转换、在本地维护副本提供远程数据的本地访问；转换：数据源格式到目标格式的批量或基于记录的转换；搜索：查询检索结构化与非结构化（如 PDF）数据）；流程整合→ 流程服务 （编排：通过预定义流程逻辑控制业务活动执行并帮助从错误中恢复； 事务：保证流程执行中的 ACID 特性——短流程通常采用两阶段提交，长流程一般采用补偿方法 ；人工：将人工活动集成到流程中，管理任务分派、授权和监管）；用户访问整合→ 交互服务 （交付：同一交互逻辑可在图形界面/语音/普及计算消息及桌面/PDA/无线终端等多方式多设备上运行；体验：个性化、协作、单点登录等增强用户体验；资源：安全配置、界面皮肤等运行时交互组件管理）。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 开发服务 ：建模服务（构建可视化业务流程模型）、设计服务（将业务模型分解为服务组件并设计开发）、实现服务（部署到生产环境）、测试服务（单元测试 + 系统集成测试）；方法学/建模： SODA、IBM 的 SOMA（Service Oriented Modeling and Architecture） ；编程模型： WSDL、BPEL4WS、SCA、SDO 。

：建模服务（构建可视化业务流程模型）、设计服务（将业务模型分解为服务组件并设计开发）、实现服务（部署到生产环境）、测试服务（单元测试 + 系统集成测试）；方法学/建模： SODA、IBM 的 SOMA（Service Oriented Modeling and Architecture） ；编程模型： WSDL、BPEL4WS、SCA、SDO 。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 业务创新和优化 ：以 业务性能管理 (BPM) 技术为核心：公共事件框架服务（IT 和业务事件的激发、存储和分类）、采集服务（基于策略的过滤和相关性分析检测感兴趣的服务）、监控服务（通过事件与监控上下文间的映射计算和管理 关键性能指标 KPI ）。 迭代闭环 ：建模阶段确定的 KPI 转为事件标志构建进业务流程 → 执行中由公共事件框架捕获 → 经采集服务过滤传给监控服务计算 KPI → KPI 用于重构或优化业务流程，使流程处于不断优化中。

：以 业务性能管理 (BPM) 技术为核心：公共事件框架服务（IT 和业务事件的激发、存储和分类）、采集服务（基于策略的过滤和相关性分析检测感兴趣的服务）、监控服务（通过事件与监控上下文间的映射计算和管理 关键性能指标 KPI ）。 迭代闭环 ：建模阶段确定的 KPI 转为事件标志构建进业务流程 → 执行中由公共事件框架捕获 → 经采集服务过滤传给监控服务计算 KPI → KPI 用于重构或优化业务流程，使流程处于不断优化中。

• ▪▪ ▪ ▪ ▪ ▪ ▪ IT 服务管理 ⭐⭐：① 安全和目录服务 ：企业范围的用户、认证和授权管理（如单点登录 SSO ）；② 系统管理和虚拟化服务 ：管理服务服务器、存储、网络和其他 IT 资源。其中相当一部分服务面向软硬件管理；另一部分（特别是安全和目录服务，以及操作系统和中间件管理）会通过 ESB 与其他服务集成在一起 ，实现性能、可用性和安全性等非功能性需求。

⭐⭐：① 安全和目录服务 ：企业范围的用户、认证和授权管理（如单点登录 SSO ）；② 系统管理和虚拟化服务 ：管理服务服务器、存储、网络和其他 IT 资源。其中相当一部分服务面向软硬件管理；另一部分（特别是安全和目录服务，以及操作系统和中间件管理）会通过 ESB 与其他服务集成在一起 ，实现性能、可用性和安全性等非功能性需求。

五、SOA 主要协议和规范 ⭐⭐⭐

Web 服务基本三协议 ： UDDI（注册）+ WSDL（描述）+ SOAP（连接） ，通过它们提供直接而简单的 Web Service 支持；Web 服务相关标准大多以 "WS-" 作为名字前缀，统称 "WS-*" 。

5.1 UDDI 协议 ⭐⭐⭐

一个广泛的、开放的 行业计划 ：使商业实体能够彼此发现，定义它们怎样在 Internet 上互相作用，并在全局的注册体系架构中共享信息；是商业实体快速方便地发现合适商业对等实体并实施电子化商业贸易的基础系统构筑模块。 UDDI 规范利用了 W3C 和 IETF（Internet 工程任务组织）的很多标准作为其实现基础（如 XML、HTTP、DNS 等协议） ；在跨平台的设计特性中主要采用了已提议给 W3C 的 SOAP 规范的早期版本 。

5.2 WSDL 规范 ⭐⭐⭐

WSDL（Web Services Description Language，Web 服务描述语言） ：用来描述 Web 服务和说明如何与 Web 服务通信的 XML 语言，由 Ariba、Intel、IBM、MS 等共同提出 ；可描述 Web 服务的三个基本属性：① 服务做些什么（所提供的操作/方法）；② 如何访问服务（交互的数据格式以及必要协议）；③ 服务位于何处（协议相关的地址，如 URL）。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 两种文档类型 ⭐： 服务接口（Service Interface） 与 服务实现（Service Implementations） ；WSDL 文档以端口集合的形式描述 Web 服务（包含对一组操作和消息的抽象定义、绑定到这些操作和消息的具体协议、以及该绑定的网络端点规范）。

⭐： 服务接口（Service Interface） 与 服务实现（Service Implementations） ；WSDL 文档以端口集合的形式描述 Web 服务（包含对一组操作和消息的抽象定义、绑定到这些操作和消息的具体协议、以及该绑定的网络端点规范）。

5.3 SOAP 协议 ⭐⭐⭐

在分散或分布式的环境中交换信息的简单协议，基于 XML。 4 个部分

• ▪▪ ▪ ▪ ▪ ▪ ▪ Envelope（封装） ：定义描述消息中的内容是什么、是谁发送的、谁应当接收并处理它以及如何处理它们的框架；

：定义描述消息中的内容是什么、是谁发送的、谁应当接收并处理它以及如何处理它们的框架；

• ▪▪ ▪ ▪ ▪ ▪ ▪ Encoding Rules（编码规则） ：用于表示应用程序需要使用的数据类型的实例；

：用于表示应用程序需要使用的数据类型的实例；

• ▪▪ ▪ ▪ ▪ ▪ ▪ RPC Representation（RPC 表示） ：远程过程调用和应答的协定；
• ▪▪ ▪ ▪ ▪ ▪ ▪ Binding（绑定） ：使用底层协议交换信息。
• ▪▪ ▪ ▪ ▪ ▪ ▪ 4 个部分作为 SOAP 的整体定义，但功能上相交、彼此独立： 信封和编码规则被定义在不同的 XML 命名空间 (Namespace) 中 ，使定义更加简单。
• ▪▪ ▪ ▪ ▪ ▪ ▪ 两个主要设计目标 ⭐： 简单性 与 可扩展性 。因此某些传统消息系统或分布式对象系统的性质（如 分布式垃圾收集、成批传送消息、对象引用和对象激活 等）不是 SOAP 规范的一部分。

⭐： 简单性 与 可扩展性 。因此某些传统消息系统或分布式对象系统的性质（如 分布式垃圾收集、成批传送消息、对象引用和对象激活 等）不是 SOAP 规范的一部分。

5.4 REST 规范 ⭐⭐⭐

由 Roy Thomas Fielding 博士 在其论文中提出的一种新型互联网软件架构风格；REST 的设计不只是适用于互联网环境，而是一个普遍的设计理念，目的是让不同的软件/应用程序在任何网络环境下都可以进行信息的互相传递。 RESTful 即 REST 式的，是对遵循 REST 设计思想同时满足设计约束的一类架构设计或应用程序的统称（借助 HTTP、JSON、URI、HTML 等广泛使用的标准和协议实现）； 微服务对外就是以 REST API 形式暴露给调用者 。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 资源(Resource) ：以资源为中心构建，互联网中一切暴露给客户端的事物都可看作资源（如订单、图片）；借助 URI（统一资源标识符） 标识 Web 上的资源；URI 和资源不是一一映射—— 一个资源可以设计多个 URI，但一个 URI 只能对应一种资源 。

：以资源为中心构建，互联网中一切暴露给客户端的事物都可看作资源（如订单、图片）；借助 URI（统一资源标识符） 标识 Web 上的资源；URI 和资源不是一一映射—— 一个资源可以设计多个 URI，但一个 URI 只能对应一种资源 。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 表述(Representational) ：描述资源在 Web 中某一时间的状态；客户端和服务端借助 RESTful API 传递数据实际就是资源表述的交互；常用表现形式有 HTML、JSON、XML、纯文本等，返回客户端的形式是统一格式（开发阶段按实际需求设计）。

：描述资源在 Web 中某一时间的状态；客户端和服务端借助 RESTful API 传递数据实际就是资源表述的交互；常用表现形式有 HTML、JSON、XML、纯文本等，返回客户端的形式是统一格式（开发阶段按实际需求设计）。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 状态转移(State Transfer) ：状态分两种—— 应用状态 （某时间内用户请求会话相关信息的快照，保存在客户端、由客户端维护，可与缓存配合降低服务端并发请求压力）和 资源状态 （保存在服务端，保证一段时间内未对资源状态改变时，客户端对同一资源请求返回的表述一致）；状态转移还要借助 HTTP 方法 （GET/POST/DELETE 等）实现。

：状态分两种—— 应用状态 （某时间内用户请求会话相关信息的快照，保存在客户端、由客户端维护，可与缓存配合降低服务端并发请求压力）和 资源状态 （保存在服务端，保证一段时间内未对资源状态改变时，客户端对同一资源请求返回的表述一致）；状态转移还要借助 HTTP 方法 （GET/POST/DELETE 等）实现。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 超链接 ：通过在页面中嵌入链接和其他资源建立联系（资源可以是文本、图片、文件等）；在资源表述中除处理当前请求资源信息外，还会添加一些相关资源 URI，将资源接口暴露给客户端便于用户请求、实现状态转移；这些超链接包含在应用状态中、由客户端维护保存，是服务请求过程中添加进去的而非服务端提前设定。

：通过在页面中嵌入链接和其他资源建立联系（资源可以是文本、图片、文件等）；在资源表述中除处理当前请求资源信息外，还会添加一些相关资源 URI，将资源接口暴露给客户端便于用户请求、实现状态转移；这些超链接包含在应用状态中、由客户端维护保存，是服务请求过程中添加进去的而非服务端提前设定。

核心结论： REST 是一种 设计风格而不是一个架构 ；RESTful 不可能摒弃 REST 而独立存在。

六、SOA 设计的标准要求 ⭐⭐

6.1 QoS 相关规范 ⭐⭐

• ▪▪ ▪ ▪ ▪ ▪ ▪ 可靠性 ：典型 SOA 环境中消费者与提供者间会有几种不同的文档进行交换，WS-Reliability / WS-Reliable Messaging（OASIS）解决此类问题；关键任务 (Mission-critical) 系统中"仅且仅传送一次""最多传送一次""重复消息过滤""保证消息传送"等特性十分重要。

：典型 SOA 环境中消费者与提供者间会有几种不同的文档进行交换，WS-Reliability / WS-Reliable Messaging（OASIS）解决此类问题；关键任务 (Mission-critical) 系统中"仅且仅传送一次""最多传送一次""重复消息过滤""保证消息传送"等特性十分重要。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 安全性 ：Web 服务安全规范保证消息的安全，主要包括认证交换、消息完整性和消息保密；借助现有安全标准如 SAML（Security Assertion Markup Language） 实现；OASIS 致力于该规范的制定。

：Web 服务安全规范保证消息的安全，主要包括认证交换、消息完整性和消息保密；借助现有安全标准如 SAML（Security Assertion Markup Language） 实现；OASIS 致力于该规范的制定。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 策略 ：服务提供者有时要求消费者与某种策略通信（如提供 Kerberos 安全标示才能取得某项服务）；这些要求被定义为 策略断言 (Policy Assertions) ，一项策略可能包含多个断言； WS-Policy 用来标准化服务消费者和提供者之间的策略通信。

：服务提供者有时要求消费者与某种策略通信（如提供 Kerberos 安全标示才能取得某项服务）；这些要求被定义为 策略断言 (Policy Assertions) ，一项策略可能包含多个断言； WS-Policy 用来标准化服务消费者和提供者之间的策略通信。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 控制 ：SOA 中进程是采用一组离散的服务创建的， BPEL4WS / WSBPEL 是用来控制这些服务的语言；整合数据仓库 (Silos of Data)、应用程序和组件意味着异步通信、并行处理、数据转换、校正等进程请求必须被标准化。

：SOA 中进程是采用一组离散的服务创建的， BPEL4WS / WSBPEL 是用来控制这些服务的语言；整合数据仓库 (Silos of Data)、应用程序和组件意味着异步通信、并行处理、数据转换、校正等进程请求必须被标准化。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 管理 ：随着服务和业务进程数量增长，需要让系统管理员管理运行在多种环境下的服务； WSDM（Web Services for Distributed Management） 使任何根据 WSDM 实现的服务都可以由一个 WSDM 适应 (WSDM-compliant) 的管理方案来管理。

：随着服务和业务进程数量增长，需要让系统管理员管理运行在多种环境下的服务； WSDM（Web Services for Distributed Management） 使任何根据 WSDM 实现的服务都可以由一个 WSDM 适应 (WSDM-compliant) 的管理方案来管理。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 多方事务 ⭐： WS-Coordination 与 WS-Transaction （OASIS 制定），描述合作方之间通信与多个服务之间的事务处理。

⭐： WS-Coordination 与 WS-Transaction （OASIS 制定），描述合作方之间通信与多个服务之间的事务处理。

七、SOA 的作用 ⭐⭐

• ▪▪ ▪ ▪ ▪ ▪ ▪ 打破"信息孤岛" ⭐⭐：不同种类的操作系统、应用软件、系统软件和应用基础结构相互交织是"信息孤岛"的表现症状；现存应用被用来处理当前业务流程，从头建立新的基础环境是不可能的。SOA 凭借 松耦合 特性，使企业可按模块化方式添加新服务或更新现有服务、通过不同的渠道提供服务、把现有/已有应用作为服务，从而 保护现有的 IT 基础建设投资 ，呈现一个可以支持有机业务 (Organic Business) 的架构。

⭐⭐：不同种类的操作系统、应用软件、系统软件和应用基础结构相互交织是"信息孤岛"的表现症状；现存应用被用来处理当前业务流程，从头建立新的基础环境是不可能的。SOA 凭借 松耦合 特性，使企业可按模块化方式添加新服务或更新现有服务、通过不同的渠道提供服务、把现有/已有应用作为服务，从而 保护现有的 IT 基础建设投资 ，呈现一个可以支持有机业务 (Organic Business) 的架构。

• ▪▪ ▪ ▪ ▪ ▪ ▪ SOA vs EAI ⭐⭐：SOA 普及前通常用 EAI（企业应用整合） 解决"信息孤岛"——每两个应用之间需要一个 EAI Server 作"翻译"，n 个应用互通需要 n(n−1)/2 个（2 个应用需 1 个、3 个需 3 个、4 个需 6 个、5 个需 10 个……），呈 几何倍数 增长，显然不是妥善办法；SOA 以 ESB 统一集成更优。

⭐⭐：SOA 普及前通常用 EAI（企业应用整合） 解决"信息孤岛"——每两个应用之间需要一个 EAI Server 作"翻译"，n 个应用互通需要 n(n−1)/2 个（2 个应用需 1 个、3 个需 3 个、4 个需 6 个、5 个需 10 个……），呈 几何倍数 增长，显然不是妥善办法；SOA 以 ESB 统一集成更优。

• ▪▪ ▪ ▪ ▪ ▪ ▪ SOA 打破信息孤岛步骤 ：(1) 把应用和资源转换成服务；(2) 把这些服务变成标准的服务，形成资源共享。

：(1) 把应用和资源转换成服务；(2) 把这些服务变成标准的服务，形成资源共享。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 重要结论 ⭐⭐⭐： SOA 不仅仅是一个技术，而是一个软件架构 。企业的决策者只需要根据企业的策略来制定流程，把应用作为服务"拿来就用"、无需考虑底层的集成，这样就可以实现 IT 和企业业务之间的同步。

⭐⭐⭐： SOA 不仅仅是一个技术，而是一个软件架构 。企业的决策者只需要根据企业的策略来制定流程，把应用作为服务"拿来就用"、无需考虑底层的集成，这样就可以实现 IT 和企业业务之间的同步。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 案例：服装零售（业务的水平改变） ⭐⭐：某服装零售组织拥有 500 家国际连锁店，常常需要更改设计以赶上时尚潮流（可能更换布料、制造商和可交付产品）；通过利用 WSDL 接口在操作方面的灵活性 ，每个公司可将现有系统保持现状，仅匹配 WSDL 接口并制订新的服务级协定，不必完全重构软件系统——改变的是合作伙伴，而所有业务操作基本上都保持不变（内部操作不需要改变）。

⭐⭐：某服装零售组织拥有 500 家国际连锁店，常常需要更改设计以赶上时尚潮流（可能更换布料、制造商和可交付产品）；通过利用 WSDL 接口在操作方面的灵活性 ，每个公司可将现有系统保持现状，仅匹配 WSDL 接口并制订新的服务级协定，不必完全重构软件系统——改变的是合作伙伴，而所有业务操作基本上都保持不变（内部操作不需要改变）。

八、SOA 的设计原则 ⭐⭐⭐

SOA 架构继承了来自对象和组件设计的各种原则（如封装、自我包含等）；结构上， 服务总线是 SOA 的架构模式之一 。保证服务的灵活性、松散耦合和重用能力的设计原则对 SOA 同样重要。

考点提示： SOA 八项设计原则是 选择题/多选题高频 ，重点记忆"无状态、单一实例、明确接口、自包含模块化、粗粒度(消息交互非 RPC)、松耦合、重用、策略声明"。

九、SOA 的设计模式 ⭐⭐⭐

• ▪▪ ▪ ▪ ▪ ▪ ▪ 服务注册表模式(Service Registry) ⭐⭐⭐：主要在 设计时段 使用（也常具有运行时段功能）；支持驱动 SOA 治理的服务合同、策略和元数据的开发、发布和管理，提供一个主控制点即 策略执行点 (Policy Enforcement Point, PEP) ——服务在此注册和被发现。任何帮助注册、发现和检索服务合同/元数据/策略的信息库、数据库、目录或其他节点都可被视为注册表（可含相关软件组件的配置、遵从性和约束配置文件）。
• ▪▪ ▪ ▪ ▪ ▪ ▪ 四类 SOA 治理功能 ⭐⭐：① 服务注册 （应用开发者/服务提供者向注册表公布服务合同，含服务身份、位置、方法、绑定、配置、方案和策略等描述性属性；实现治理最有效的方法之一是 限制哪类新服务可向主注册表发布、由谁发布以及谁批准和根据什么条件批准 ）；② 服务位置 （帮助消费者查询符合自身要求的已注册服务并检索服务合同；对谁可访问注册表、什么服务属性通过注册表暴露的控制也是有效治理手段）；③ 服务绑定 （消费者利用检索到的服务合同开发代码，与注册的服务绑定、调用并互动；工具驱动对服务绑定的控制，有效管理服务在 ESB 上的互动）；④ 配置文件 (Profile) 管理 （说明服务当前的生命周期阶段和该阶段的相关策略；可为某服务创建多个配置文件，任意时间将不同配置文件与服务建立联系，即可在其生命周期不同阶段之间移动）。

⭐⭐：① 服务注册 （应用开发者/服务提供者向注册表公布服务合同，含服务身份、位置、方法、绑定、配置、方案和策略等描述性属性；实现治理最有效的方法之一是 限制哪类新服务可向主注册表发布、由谁发布以及谁批准和根据什么条件批准 ）；② 服务位置 （帮助消费者查询符合自身要求的已注册服务并检索服务合同；对谁可访问注册表、什么服务属性通过注册表暴露的控制也是有效治理手段）；③ 服务绑定 （消费者利用检索到的服务合同开发代码，与注册的服务绑定、调用并互动；工具驱动对服务绑定的控制，有效管理服务在 ESB 上的互动）；④ 配置文件 (Profile) 管理 （说明服务当前的生命周期阶段和该阶段的相关策略；可为某服务创建多个配置文件，任意时间将不同配置文件与服务建立联系，即可在其生命周期不同阶段之间移动）。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 两大注册厂商阵营 ⭐：① 纯 SOA 厂商 （提供服务、策略和元数据注册表及信息库）：Flashline、Infravio、LogicLibrary、SOA Software、Systinet；② SOA 平台厂商 （注册表作为集成产品套件的一个组件，套件常含应用服务器、门户、数据库管理系统、BI 工具、集成中间件等）：BEA、IBM、Microsoft、Novell、Oracle、SAP、Sun、WebMethods。

⭐：① 纯 SOA 厂商 （提供服务、策略和元数据注册表及信息库）：Flashline、Infravio、LogicLibrary、SOA Software、Systinet；② SOA 平台厂商 （注册表作为集成产品套件的一个组件，套件常含应用服务器、门户、数据库管理系统、BI 工具、集成中间件等）：BEA、IBM、Microsoft、Novell、Oracle、SAP、Sun、WebMethods。

• ▪▪ ▪ ▪ ▪ ▪ ▪ UDDI（通用描述、发现与集成） 标准定义了 SOA 的一种主要注册环境（绝非唯一）；没有自己注册表的 SOA 厂商，常通过 UDDI v3 和其他开放标准与一个或多个第三方注册表产品进行集成。

标准定义了 SOA 的一种主要注册环境（绝非唯一）；没有自己注册表的 SOA 厂商，常通过 UDDI v3 和其他开放标准与一个或多个第三方注册表产品进行集成。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 企业服务总线模式(ESB) ⭐⭐⭐：在企业基于 SOA 实施 EAI、B2B 和 BPM 的过程中， 点对点集成方式存在复杂度高、可管理性差、复用度差和系统脆弱 等问题；ESB 是由中间件技术实现的支持面向服务架构的基础软件平台，支持异构环境中的服务以 基于消息和事件驱动模式 的交互（具有适当的服务质量和可管理性）。典型交互：请求者触发并标准化消息 → 发往服务总线 → 按服务名/接口名查找目的组件转发 → 结果逆向返回（详见 ESB 条目）。
• ▪▪ ▪ ▪ ▪ ▪ ▪ 结论 ⭐⭐：基于标准的互连技术使企业内部及外部系统之间很容易进行异步或同步交互，提高集成应用开发效率的同时降低成本；ESB 克服了传统应用集成技术的缺陷， 可以说是目前理想的 EAI、B2B 应用系统集成支撑平台 ；软件厂商以 ESB 中间件为基础，提供包含业务集成软件基础平台、各种预制服务组件、集成应用开发/部署/管理和监控工具为一体的整套立体企业应用软件集成平台。

⭐⭐：基于标准的互连技术使企业内部及外部系统之间很容易进行异步或同步交互，提高集成应用开发效率的同时降低成本；ESB 克服了传统应用集成技术的缺陷， 可以说是目前理想的 EAI、B2B 应用系统集成支撑平台 ；软件厂商以 ESB 中间件为基础，提供包含业务集成软件基础平台、各种预制服务组件、集成应用开发/部署/管理和监控工具为一体的整套立体企业应用软件集成平台。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 案例研究：SynchroESB（协同企业服务总线） ⭐⭐：基于 SOA 体系结构、以 ESB 为底层架构，包含丰富的预制程序组件、集中式管理工具和可视化应用程序开发界面的服务整合软件平台（西安协同时光软件公司与西北工业大学计算机学院联合研发）， 系统分为 4 个层次 （自上而下）
• ▪▪ ▪ ▪ ▪ ▪ ▪ 特点：采用 事件驱动架构 使企业能更快响应业务变化；以独创的"粗颗粒"组件编程模型技术构建可重用组件库；通过分布式架构和集中式管理解决集中式集成方式中的问题。
• ▪▪ ▪ ▪ ▪ ▪ ▪ 微服务架构模式 ⭐⭐⭐：见第三节（微服务架构模式，位于设计原则之后）。

十、构建 SOA 架构应注意的问题 ⭐⭐

10.1 两大关键点 ⭐⭐

• ▪▪ ▪ ▪ ▪ ▪ ▪ 原有系统架构的集成需求 ：SOA 本质上是一种具有特殊性质的体系结构，由具有 互操作性和位置透明 的组件集成构建并互连而成；企业 SOA 架构通常是在现有系统架构投资的基础上发展起来的，可复用当前系统已有资源（开发人员、软件语言、硬件平台、数据库和应用程序）来重复利用现有系统和资源，缩短产品上市时间、降低成本和风险。 首先考虑如何重用已有的投资而不是替换遗留系统 （有限预算下整体系统替换成本十分高昂）。集成需求不限于基于组件构建的已有应用程序的集成，还必须全面考虑四类更具体的集成类型： 应用程序集成的需求、终端用户界面集成的需求、流程集成的需求以及已有系统信息集成的需求 。例：航运系统中的 EDI（Electronic Data Interchange，电子数据交换）系统 会有大量的电子数据交换处理需求，存在很多不同的数据源类型，消息数据集成需求就会比较复杂。

：SOA 本质上是一种具有特殊性质的体系结构，由具有 互操作性和位置透明 的组件集成构建并互连而成；企业 SOA 架构通常是在现有系统架构投资的基础上发展起来的，可复用当前系统已有资源（开发人员、软件语言、硬件平台、数据库和应用程序）来重复利用现有系统和资源，缩短产品上市时间、降低成本和风险。 首先考虑如何重用已有的投资而不是替换遗留系统 （有限预算下整体系统替换成本十分高昂）。集成需求不限于基于组件构建的已有应用程序的集成，还必须全面考虑四类更具体的集成类型： 应用程序集成的需求、终端用户界面集成的需求、流程集成的需求以及已有系统信息集成的需求 。例：航运系统中的 EDI（Electronic Data Interchange，电子数据交换）系统 会有大量的电子数据交换处理需求，存在很多不同的数据源类型，消息数据集成需求就会比较复杂。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 重要结论 ⭐⭐：如果希望所构建的系统架构能够随着企业的发展和变化成功地继续得以保持，则 整个系统构架中的集成功能就应该由服务提供，而不是由特定的应用程序来完成 。

⭐⭐：如果希望所构建的系统架构能够随着企业的发展和变化成功地继续得以保持，则 整个系统构架中的集成功能就应该由服务提供，而不是由特定的应用程序来完成 。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 服务粒度控制与无状态服务设计 （SOA 系统中服务构建的两点特别注意）

（SOA 系统中服务构建的两点特别注意）

• ▪▪ ▪ ▪ ▪ ▪ ▪ EJB 实现机制 ⭐：在 J2EE（基于 WebSphere）环境下构建 Web 服务，客户可通过两种方式访问 J2EE 应用程序：① 访问用 JAX-RPC API （使用 Servlet 实现）创建的 Web 服务；② 通过 EJB 的服务端点接口访问无状态的 Session Bean。把 Web 服务模型化为 EJB 端点 可基于已有 EJB 组件利用现有的业务逻辑和流程。

⭐：在 J2EE（基于 WebSphere）环境下构建 Web 服务，客户可通过两种方式访问 J2EE 应用程序：① 访问用 JAX-RPC API （使用 Servlet 实现）创建的 Web 服务；② 通过 EJB 的服务端点接口访问无状态的 Session Bean。把 Web 服务模型化为 EJB 端点 可基于已有 EJB 组件利用现有的业务逻辑和流程。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 限制 ：Web 服务客户 不能 访问其他类型的企业 Bean—— 有状态的 Session Bean、实体 Bean 和消息驱动 Bean 。

：Web 服务客户 不能 访问其他类型的企业 Bean—— 有状态的 Session Bean、实体 Bean 和消息驱动 Bean 。

• ▪▪ ▪ ▪ ▪ ▪ ▪ EJB 端点优势 ：使业务逻辑和端点位于同一层；EJB 容器自动提供 并发支持 （必须串行化对无状态会话 Bean 任何特定实例的请求，无需担心多线程访问）、 Security 与 Transaction 支持 （开发人员无需编写安全代码及事务处理代码）、 集群与池化 支持（负载增加时可向群集中增加机器，无状态 Session Bean 池改进资源利用和内存管理），从而增强服务的 可伸缩性 与系统整体的 可靠性 。

：使业务逻辑和端点位于同一层；EJB 容器自动提供 并发支持 （必须串行化对无状态会话 Bean 任何特定实例的请求，无需担心多线程访问）、 Security 与 Transaction 支持 （开发人员无需编写安全代码及事务处理代码）、 集群与池化 支持（负载增加时可向群集中增加机器，无状态 Session Bean 池改进资源利用和内存管理），从而增强服务的 可伸缩性 与系统整体的 可靠性 。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 粒度控制 ⭐⭐：对将暴露在整个系统 外部 的服务推荐 粗粒度 接口，相对较细粒度的服务接口通常用于企业系统架构的 内部 ；技术上，粗粒度接口可能是特定服务的完整执行，细粒度接口可能是实现该粗粒度服务接口的具体内部操作（例：基于 SOA 的网上商店——对外暴露的粗粒度服务是"提交购买表单"，内部细粒度服务是实现它的一系列操作，如创建购买记录、设置客户地址和更新数据库）。 原因 ：细粒度接口虽提供更细化、更多的灵活性，但会引入较难控制的 交互模式易变性 （服务的交互模式可能随不同服务请求者而不同），外部请求者将难于支持不断变化的细粒度接口；粗粒度接口保证请求者以一致的方式使用系统所暴露的服务。SOA 并不强制使用粗粒度接口，但建议作为外部集成接口；架构设计师通常可用 BPEL 创建由细粒度操作组成的业务流程的粗粒度服务接口。

⭐⭐：对将暴露在整个系统 外部 的服务推荐 粗粒度 接口，相对较细粒度的服务接口通常用于企业系统架构的 内部 ；技术上，粗粒度接口可能是特定服务的完整执行，细粒度接口可能是实现该粗粒度服务接口的具体内部操作（例：基于 SOA 的网上商店——对外暴露的粗粒度服务是"提交购买表单"，内部细粒度服务是实现它的一系列操作，如创建购买记录、设置客户地址和更新数据库）。 原因 ：细粒度接口虽提供更细化、更多的灵活性，但会引入较难控制的 交互模式易变性 （服务的交互模式可能随不同服务请求者而不同），外部请求者将难于支持不断变化的细粒度接口；粗粒度接口保证请求者以一致的方式使用系统所暴露的服务。SOA 并不强制使用粗粒度接口，但建议作为外部集成接口；架构设计师通常可用 BPEL 创建由细粒度操作组成的业务流程的粗粒度服务接口。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 无状态服务 ⭐⭐：SOA 中的具体服务应该都是独立的、自包含的请求，实现时不需要前一个请求的状态（不依赖其他服务的上下文和状态）；当某一服务需要依赖时，最好把它定义成具体的业务流程（ BPEL ）。可通过 EJB 组件 实现粗粒度服务：利用 无状态的 Session Bean 实现具体服务，基于 Web Service 技术就可将其暴露为外部用户可调用的 Web 服务（即把传统的 Session Facade 模型转化为 EJB 的 Web 服务端点），向 Web 服务客户提供粗粒度的服务。

⭐⭐：SOA 中的具体服务应该都是独立的、自包含的请求，实现时不需要前一个请求的状态（不依赖其他服务的上下文和状态）；当某一服务需要依赖时，最好把它定义成具体的业务流程（ BPEL ）。可通过 EJB 组件 实现粗粒度服务：利用 无状态的 Session Bean 实现具体服务，基于 Web Service 技术就可将其暴露为外部用户可调用的 Web 服务（即把传统的 Session Facade 模型转化为 EJB 的 Web 服务端点），向 Web 服务客户提供粗粒度的服务。

十一、SOA 实施的过程 ⭐⭐

11.1 选择 SOA 解决方案（三方面）⭐⭐

选择最佳解决方案是保证 SOA 实施成功的前提条件，必须从以下三个方面进行选择

• ▪▪ ▪ ▪ ▪ ▪ ▪ 尽量选择能进行全局规划的方案 ：SOA 实施有很大技术因素，既需要选择适当的工具，还需要有专业技术人才；首先对自己的系统做全面评估（已有系统能用多少、有多少需要改造、还需上哪些新系统、将来如何满足需求、可能投入的资本等），整体规划是实施 SOA 最为基础的一步；其次选择适合的工具和技术（上什么系统、建什么平台、先改造哪个系统要心中有数）；最后开发对多数用户来说是边学习、边实践的过程。

：SOA 实施有很大技术因素，既需要选择适当的工具，还需要有专业技术人才；首先对自己的系统做全面评估（已有系统能用多少、有多少需要改造、还需上哪些新系统、将来如何满足需求、可能投入的资本等），整体规划是实施 SOA 最为基础的一步；其次选择适合的工具和技术（上什么系统、建什么平台、先改造哪个系统要心中有数）；最后开发对多数用户来说是边学习、边实践的过程。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 选择时充分考虑企业自身的需求 ：评估 SOA 项目的方式与评估传统软件项目有所不同——SOA 在企业范围内通过各种渠道表现优势，通过共享服务优化业务流程使全面创新成为可能，其"价值机会"远超传统软件项目；用于构建 SOA 项目前期投资将产生巨大效益且随时间越来越明显；具体实施进度和资金投入一方面取决于企业对 IT 应用的沉淀，另一方面取决于实行 SOA 的目标层次。

：评估 SOA 项目的方式与评估传统软件项目有所不同——SOA 在企业范围内通过各种渠道表现优势，通过共享服务优化业务流程使全面创新成为可能，其"价值机会"远超传统软件项目；用于构建 SOA 项目前期投资将产生巨大效益且随时间越来越明显；具体实施进度和资金投入一方面取决于企业对 IT 应用的沉淀，另一方面取决于实行 SOA 的目标层次。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 从平台、实施等技术方面进行考察 ：① 选择软件平台时首先要考虑 平台的开放性和对标准的支持 ；② 实施方法与途径——以往成功经验总结有 6 方面： 业务战略和流程、基础架构、构建模块、项目和应用、成本和效益以及规划和管理 （CIO 应综合考虑）；③ 供应商选择——首先看产品是否符合企业实际需求、是否已有许多成功应用案例、现有客户评价如何；其次还要仔细考察供应商的专业服务能力，是否能够帮助用户分析企业 IT 现状、提出建设性的意见。SOA 的实施涉及整个企业的 IT 系统以及业务流程的调整和改变，离不开相应的咨询和专业服务。

：① 选择软件平台时首先要考虑 平台的开放性和对标准的支持 ；② 实施方法与途径——以往成功经验总结有 6 方面： 业务战略和流程、基础架构、构建模块、项目和应用、成本和效益以及规划和管理 （CIO 应综合考虑）；③ 供应商选择——首先看产品是否符合企业实际需求、是否已有许多成功应用案例、现有客户评价如何；其次还要仔细考察供应商的专业服务能力，是否能够帮助用户分析企业 IT 现状、提出建设性的意见。SOA 的实施涉及整个企业的 IT 系统以及业务流程的调整和改变，离不开相应的咨询和专业服务。

11.2 业务流程分析 ⭐⭐

• ▪▪ ▪ ▪ ▪ ▪ ▪ 自顶向下 ：以 业务组件模型 （业务领域/执行层次/组件，含"热点视图"）和 端到端业务流程 为输入，逐层分解至业务活动（服务候选者）；经 变化分析 区分易变/稳定部分，剥离易变逻辑与规则以保证未来变化不破坏现有设计；服务候选者划分到业务组件后形成 层次化服务目录 。

：以 业务组件模型 （业务领域/执行层次/组件，含"热点视图"）和 端到端业务流程 为输入，逐层分解至业务活动（服务候选者）；经 变化分析 区分易变/稳定部分，剥离易变逻辑与规则以保证未来变化不破坏现有设计；服务候选者划分到业务组件后形成 层次化服务目录 。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 业务目标分析 ：从关键性能指标（KPI）出发，目标→子目标→服务，形成 "目标服务树" ，叶子节点服务可回溯到具体业务目标，用于验证/发现服务候选者。

：从关键性能指标（KPI）出发，目标→子目标→服务，形成 "目标服务树" ，叶子节点服务可回溯到具体业务目标，用于验证/发现服务候选者。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 自底向上（遗留资产分析） ：建立已有系统 功能模块目录列表 ，发现跨系统重复实现及可复用模块，包装成服务发布；来源多为原有系统设计文档，结果是 可复用服务列表 ，并可提前验证技术局限与实现决策可行性。

：建立已有系统 功能模块目录列表 ，发现跨系统重复实现及可复用模块，包装成服务发布；来源多为原有系统设计文档，结果是 可复用服务列表 ，并可提前验证技术局限与实现决策可行性。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 业务对象 （3 类）⭐：业务对象是对数据进行检索和处理的组件，是简单的真实世界的软件抽象，通常位于 中间层或者业务逻辑层 ；可以在一个应用中自动地加入一个特定功能来获得增值效应、使知识重用变为可能（如直接使用已开发完成的含所有多货币处理功能的业务对象来开始开发）。分类：① 实体业务对象 ——表达一个人、地点、事物或者概念，根据业务中的名词从业务域中提取（如客户、订单和物品）；② 过程业务对象 ——表达应用程序中业务处理过程或工作流程任务，通常依赖于实体业务对象，是业务的动词；③ 事件业务对象 ——表达应用程序中由于系统的一些操作造成或产生的一些事件。

（3 类）⭐：业务对象是对数据进行检索和处理的组件，是简单的真实世界的软件抽象，通常位于 中间层或者业务逻辑层 ；可以在一个应用中自动地加入一个特定功能来获得增值效应、使知识重用变为可能（如直接使用已开发完成的含所有多货币处理功能的业务对象来开始开发）。分类：① 实体业务对象 ——表达一个人、地点、事物或者概念，根据业务中的名词从业务域中提取（如客户、订单和物品）；② 过程业务对象 ——表达应用程序中业务处理过程或工作流程任务，通常依赖于实体业务对象，是业务的动词；③ 事件业务对象 ——表达应用程序中由于系统的一些操作造成或产生的一些事件。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 服务接口 ⭐⭐：在实现 SOA 解决方案的上下文中，服务接口的结构非常重要（设计糟糕的接口会使使用该接口的很多服务使用者应用开发变得复杂、使业务流程的开发和优化变得复杂；设计良好的接口可加速开发计划的执行并促进业务级别的灵活性）。服务接口通常应该包含 多个操作 ，定义为单个服务接口一部分的操作应该从 语义上相关 ：仅包含单个操作或少量操作的大部分服务都表明服务粒度不恰当；反过来，采用很少的服务（或单个服务）来包含大量操作也同样表明服务粒度不恰当。

⭐⭐：在实现 SOA 解决方案的上下文中，服务接口的结构非常重要（设计糟糕的接口会使使用该接口的很多服务使用者应用开发变得复杂、使业务流程的开发和优化变得复杂；设计良好的接口可加速开发计划的执行并促进业务级别的灵活性）。服务接口通常应该包含 多个操作 ，定义为单个服务接口一部分的操作应该从 语义上相关 ：仅包含单个操作或少量操作的大部分服务都表明服务粒度不恰当；反过来，采用很少的服务（或单个服务）来包含大量操作也同样表明服务粒度不恰当。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 有状态（对话型）交换 ：服务提供者保留之前操作调用期间使用者与提供者之间交换的数据信息。例：服务接口定义为 setCustomerNumber 和 getCustomerInfo ——请求者先调用 setCustomerNumber 传入客户编号（提供者在内存中保留），再调用 getCustomerInfo ，提供者返回与该客户编号对应的客户信息响应。

：服务提供者保留之前操作调用期间使用者与提供者之间交换的数据信息。例：服务接口定义为 setCustomerNumber 和 getCustomerInfo ——请求者先调用 setCustomerNumber 传入客户编号（提供者在内存中保留），再调用 getCustomerInfo ，提供者返回与该客户编号对应的客户信息响应。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 无状态接口是最佳选择 ：便于供很多服务使用者应用程序重用，可以采用最适合每个应用程序的方式管理状态； 传入操作的请求消息应该包含完成该操作所必要的所有信息，而不受到调用其他接口操作的顺序的影响 。

：便于供很多服务使用者应用程序重用，可以采用最适合每个应用程序的方式管理状态； 传入操作的请求消息应该包含完成该操作所必要的所有信息，而不受到调用其他接口操作的顺序的影响 。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 业务流程(BP) 模型 ： 流程是指定的活动顺序，包含明确确定的用于提供业务值的输入和输出 （例：技术文档搜索流程从 Web 页面提取客户搜索请求并生成可选文档列表）；建模应确保捕获相关信息的一致性及完整性。分析员基于从业务需求所有者收集的需求构建 BP 模型（可借助 PowerPoint、Spreadsheets、IBM Rational Requisite Pro 或其他工具组合收集需求，对现有流程模型进行分析或通过修改现有模型创建新模型）。建模过程 通过将 BP 分成子流程 开始，随后对各子流程进行分析以确定组件、服务、输入输出数据、策略及测量，使用 WebSphere Business Integration Modeler 将这些元素编码到 BP 模型中。

： 流程是指定的活动顺序，包含明确确定的用于提供业务值的输入和输出 （例：技术文档搜索流程从 Web 页面提取客户搜索请求并生成可选文档列表）；建模应确保捕获相关信息的一致性及完整性。分析员基于从业务需求所有者收集的需求构建 BP 模型（可借助 PowerPoint、Spreadsheets、IBM Rational Requisite Pro 或其他工具组合收集需求，对现有流程模型进行分析或通过修改现有模型创建新模型）。建模过程 通过将 BP 分成子流程 开始，随后对各子流程进行分析以确定组件、服务、输入输出数据、策略及测量，使用 WebSphere Business Integration Modeler 将这些元素编码到 BP 模型中。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 流程元素 ⭐：一种定义流程段的 可复用构件资产 （建模构件），将已建立的一系列任务、决策、对数据对象的引用、策略、角色及测试合并起来（如"登录流程元素"包含一系列活动、登录证书数据以及完成用户登录过程的登录规则）；表示可接受的操作行为，类似需求可复用它们，可像子流程模型一样被检验和复用。

⭐：一种定义流程段的 可复用构件资产 （建模构件），将已建立的一系列任务、决策、对数据对象的引用、策略、角色及测试合并起来（如"登录流程元素"包含一系列活动、登录证书数据以及完成用户登录过程的登录规则）；表示可接受的操作行为，类似需求可复用它们，可像子流程模型一样被检验和复用。

• ▪▪ ▪ ▪ ▪ ▪ ▪ BP 建模工具与协作 ⭐：除 WebSphere Business Integration Modeler 外，还有 PowerPoint、Spreadsheets、IBM Rational Requisite Pro 等；BP 分析员与 BP 所有者及领域专家协作获取全部所需信息，使用适当工具收集角色、任务、序列信息、资源、数据、叙述和需求等作为构建 BP 模型的输入，所获取的信息可轻易 导出给工作流开发人员 （在 Application Developer 工具中使用）。

⭐：除 WebSphere Business Integration Modeler 外，还有 PowerPoint、Spreadsheets、IBM Rational Requisite Pro 等；BP 分析员与 BP 所有者及领域专家协作获取全部所需信息，使用适当工具收集角色、任务、序列信息、资源、数据、叙述和需求等作为构建 BP 模型的输入，所获取的信息可轻易 导出给工作流开发人员 （在 Application Developer 工具中使用）。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 流程建模任务 ：定义业务流程的细节，并为所有数据、资源及流程中所使用的其他元素建模；BP 包含一些由 控制流 相连接的活动步骤（活动之间通过控制流相连），这些控制流将活动与 决策点 相连；决策点遵循 业务规则（转换条件） 来确定流程应当依照什么路线进行；建模还包括将 BP 分解成子流程并将所需的流程元素添加到模型中，可利用现有模型构件（服务或流程元素）促进并加速模型构建。

：定义业务流程的细节，并为所有数据、资源及流程中所使用的其他元素建模；BP 包含一些由 控制流 相连接的活动步骤（活动之间通过控制流相连），这些控制流将活动与 决策点 相连；决策点遵循 业务规则（转换条件） 来确定流程应当依照什么路线进行；建模还包括将 BP 分解成子流程并将所需的流程元素添加到模型中，可利用现有模型构件（服务或流程元素）促进并加速模型构建。

考点提示： 构建 SOA 时应将 无状态接口视为最佳选择 （便于重用，传入请求含完成操作所需全部信息、不受调用顺序影响）。

核心协议与设计要点横向对比速查表

考试高频考点速记清单

选择题最高频

• ▪▪ ▪ ▪ ▪ ▪ ▪ Web 服务三剑客：SOAP / WSDL / UDDI⭐⭐⭐
• ▪▪ ▪ ▪ ▪ ▪ ▪ ESB 两套能力清单 ：基本特征和能力（注册管理/数据传输转换/同步异步模式/发现路由匹配选择/安全 QoS 可管理性负载均衡）+ 核心功能 6 项 + "位置透明 + 协议透明" ⭐⭐⭐

：基本特征和能力（注册管理/数据传输转换/同步异步模式/发现路由匹配选择/安全 QoS 可管理性负载均衡）+ 核心功能 6 项 + "位置透明 + 协议透明" ⭐⭐⭐

• ▪▪ ▪ ▪ ▪ ▪ ▪ SOA vs 微服务区别 （独立进程 / RESTful / 去中心化） ⭐⭐⭐⭐

（独立进程 / RESTful / 去中心化） ⭐⭐⭐⭐

• ▪▪ ▪ ▪ ▪ ▪ ▪ 微服务五大优势 （解耦/独立/技术灵活/容错/松耦合）+ 可扩展单个组件而非整个应用堆栈以满足 SLA ⭐⭐⭐⭐

（解耦/独立/技术灵活/容错/松耦合）+ 可扩展单个组件而非整个应用堆栈以满足 SLA ⭐⭐⭐⭐

• ▪▪ ▪ ▪ ▪ ▪ ▪ REST 四大概念 （资源/表述/状态转移/超链接） ⭐⭐⭐

（资源/表述/状态转移/超链接） ⭐⭐⭐

• ▪▪ ▪ ▪ ▪ ▪ ▪ SOAP 四部分 （封装/编码规则/RPC 表示/绑定）+ 两个设计目标 （简单性/可扩展性；信封与编码规则在不同的 XML 命名空间） ⭐⭐⭐

（封装/编码规则/RPC 表示/绑定）+ 两个设计目标 （简单性/可扩展性；信封与编码规则在不同的 XML 命名空间） ⭐⭐⭐

• ▪▪ ▪ ▪ ▪ ▪ ▪ WSDL 七元素 （types/message/operation/portType/binding/port/service）+ 两种文档类型 （服务接口/服务实现） ⭐⭐⭐

（types/message/operation/portType/binding/port/service）+ 两种文档类型 （服务接口/服务实现） ⭐⭐⭐

• ▪▪ ▪ ▪ ▪ ▪ ▪ XML 是 SOA 基石 （XSD 保完整有效、XSLT 促通信；源自 SGML） ⭐⭐⭐

（XSD 保完整有效、XSLT 促通信；源自 SGML） ⭐⭐⭐

• ▪▪ ▪ ▪ ▪ ▪ ▪ SOA 三阶段 （萌芽 XML → 标准化 Web 服务三剑客 → 成熟 SCA/SDO/WS-Policy） ⭐⭐

（萌芽 XML → 标准化 Web 服务三剑客 → 成熟 SCA/SDO/WS-Policy） ⭐⭐

• ▪▪ ▪ ▪ ▪ ▪ ▪ SOA 两种定义 （应用=应用框架；原理=组件模型） ⭐⭐⭐

（应用=应用框架；原理=组件模型） ⭐⭐⭐

• ▪▪ ▪ ▪ ▪ ▪ ▪ BPEL 的作用 （组合/编排/协调 Web 服务定义与执行业务流程，形成复合服务） ⭐⭐⭐

（组合/编排/协调 Web 服务定义与执行业务流程，形成复合服务） ⭐⭐⭐

选择题高频

• ▪▪ ▪ ▪ ▪ ▪ ▪ QoS 相关规范 ：WS-Reliability / WS-Reliable Messaging、SAML、WS-Policy（策略断言）、BPEL4WS/WSBPEL、WSDM、 WS-Coordination & WS-Transaction ⭐⭐

：WS-Reliability / WS-Reliable Messaging、SAML、WS-Policy（策略断言）、BPEL4WS/WSBPEL、WSDM、 WS-Coordination & WS-Transaction ⭐⭐

• ▪▪ ▪ ▪ ▪ ▪ ▪ SOA 的作用 ：打破信息孤岛，松耦合模块化复用； "SOA 不仅仅是一个技术，而是一个软件架构" ⭐⭐

：打破信息孤岛，松耦合模块化复用； "SOA 不仅仅是一个技术，而是一个软件架构" ⭐⭐

• ▪▪ ▪ ▪ ▪ ▪ ▪ EAI 的"翻译"问题 ：n 个应用需 n(n−1)/2 个 EAI Server，呈几何倍数增长 ⭐⭐

：n 个应用需 n(n−1)/2 个 EAI Server，呈几何倍数增长 ⭐⭐

• ▪▪ ▪ ▪ ▪ ▪ ▪ 参考架构 6 大类元素 （业务逻辑/控制/连接/创新优化/开发/IT 服务管理）+ 流程事务服务：ACID，短流程两阶段提交、长流程补偿方法 ⭐⭐

（业务逻辑/控制/连接/创新优化/开发/IT 服务管理）+ 流程事务服务：ACID，短流程两阶段提交、长流程补偿方法 ⭐⭐

• ▪▪ ▪ ▪ ▪ ▪ ▪ 服务注册表模式 ：设计时段使用，提供策略执行点(PEP)，四类治理功能（注册/位置/绑定/配置文件管理） ⭐⭐

：设计时段使用，提供策略执行点(PEP)，四类治理功能（注册/位置/绑定/配置文件管理） ⭐⭐

• ▪▪ ▪ ▪ ▪ ▪ ▪ 自顶向下 / 自底向上 / 业务目标分析 三种服务建模法 ⭐⭐
• ▪▪ ▪ ▪ ▪ ▪ ▪ 服务接口设计 ：无状态接口为最佳（请求消息含完成操作所需全部信息、不受调用顺序影响），操作应语义相关 ⭐⭐

：无状态接口为最佳（请求消息含完成操作所需全部信息、不受调用顺序影响），操作应语义相关 ⭐⭐

• ▪▪ ▪ ▪ ▪ ▪ ▪ 服务注册厂商两大阵营 （纯 SOA 厂商 vs SOA 平台厂商）+ UDDI/UDDI v3 集成 ⭐⭐

（纯 SOA 厂商 vs SOA 平台厂商）+ UDDI/UDDI v3 集成 ⭐⭐

• ▪▪ ▪ ▪ ▪ ▪ ▪ 无状态服务 EJB 实现 ：无状态 Session Bean 暴露为 Web 服务（EJB 端点；JAX-RPC API/Servlet 两种访问方式）；客户不能访问有状态/实体/消息驱动 Bean ⭐⭐

：无状态 Session Bean 暴露为 Web 服务（EJB 端点；JAX-RPC API/Servlet 两种访问方式）；客户不能访问有状态/实体/消息驱动 Bean ⭐⭐

• ▪▪ ▪ ▪ ▪ ▪ ▪ 《SOA 中国路线图》两点可取之处 （根本性问题不同 / 系统集成与构建融合性）+ 两类领域措施 ⭐

（根本性问题不同 / 系统集成与构建融合性）+ 两类领域措施 ⭐

• ▪▪ ▪ ▪ ▪ ▪ ▪ 集成功应由服务提供，而不是由特定的应用程序来完成 （架构可持续演化的关键） ⭐⭐

（架构可持续演化的关键） ⭐⭐

• ▪▪ ▪ ▪ ▪ ▪ ▪ UDDI 利用 W3C/IETF 标准（XML、HTTP、DNS）作为实现基础 ；Web 服务是 Web 2.0 时代重要特征 ⭐⭐

；Web 服务是 Web 2.0 时代重要特征 ⭐⭐

案例分析题高频

• ▪▪ ▪ ▪ ▪ ▪ ▪ 判断架构类型 ：给出场景判断是 SOA 还是微服务，说明 ESB 作用与松耦合性 ⭐⭐⭐

：给出场景判断是 SOA 还是微服务，说明 ESB 作用与松耦合性 ⭐⭐⭐

• ▪▪ ▪ ▪ ▪ ▪ ▪ 服务粒度判断 ：给出服务接口设计场景，判断粒度是否恰当（外部粗粒度/内部细粒度、操作语义相关） ⭐⭐⭐

：给出服务接口设计场景，判断粒度是否恰当（外部粗粒度/内部细粒度、操作语义相关） ⭐⭐⭐

• ▪▪ ▪ ▪ ▪ ▪ ▪ 协议匹配 ：给出协议描述，识别 SOAP/WSDL/UDDI/REST 的作用 ⭐⭐⭐

：给出协议描述，识别 SOAP/WSDL/UDDI/REST 的作用 ⭐⭐⭐

• ▪▪ ▪ ▪ ▪ ▪ ▪ ESB 功能应用 ：分析 ESB 如何实现解耦与位置/协议透明（含典型交互过程） ⭐⭐

：分析 ESB 如何实现解耦与位置/协议透明（含典型交互过程） ⭐⭐

• ▪▪ ▪ ▪ ▪ ▪ ▪ 服务粒度/无状态设计判断 ：外部粗粒度 + 无状态接口（EJB 无状态 Session Bean 暴露为 Web 服务） ⭐⭐

：外部粗粒度 + 无状态接口（EJB 无状态 Session Bean 暴露为 Web 服务） ⭐⭐

• ▪▪ ▪ ▪ ▪ ▪ ▪ 服务建模方法应用 ：给定业务场景选择自顶向下/自底向上/业务目标分析，识别服务候选者 ⭐⭐

：给定业务场景选择自顶向下/自底向上/业务目标分析，识别服务候选者 ⭐⭐

论文题高频

• ▪▪ ▪ ▪ ▪ ▪ ▪ 论面向服务架构(SOA)的设计与实现 — 论点框架：SOA 概念→"不仅是技术更是软件架构"→设计原则→ESB 集成→打破信息孤岛（含服装零售案例）→实践案例。⭐⭐⭐

— 论点框架：SOA 概念→"不仅是技术更是软件架构"→设计原则→ESB 集成→打破信息孤岛（含服装零售案例）→实践案例。⭐⭐⭐

• ▪▪ ▪ ▪ ▪ ▪ ▪ 论微服务架构的优势、挑战与选型 — 论点框架：微服务优势→设计模式→分布式挑战（CAP/测试/监控）→取舍决策。⭐⭐⭐

— 论点框架：微服务优势→设计模式→分布式挑战（CAP/测试/监控）→取舍决策。⭐⭐⭐

• ▪▪ ▪ ▪ ▪ ▪ ▪ 论企业服务总线(ESB)在企业集成中的应用 — 论点框架：ESB 核心功能→位置/协议透明→解耦→SynchroESB 案例。⭐⭐⭐

— 论点框架：ESB 核心功能→位置/协议透明→解耦→SynchroESB 案例。⭐⭐⭐

• ▪▪ ▪ ▪ ▪ ▪ ▪ 论 REST 架构风格在 Web 服务中的应用 — 论点框架：REST 四概念→HTTP 方法→资源表述→微服务 API 设计。⭐⭐

— 论点框架：REST 四概念→HTTP 方法→资源表述→微服务 API 设计。⭐⭐

关键时间轴与对比速记

20世纪90年代末～21世纪初 → XML 技术萌芽（SOA 基石：XSD/XSLT） ⭐⭐ 2000年后 → Web 服务概念提出，三剑客 SOAP/WSDL/UDDI ⭐⭐⭐ 2005年起 → SOA 成熟应用，SCA/SDO/WS-Policy 进入实施阶段 ⭐⭐ 2007年 → IDC 发布《SOA 中国路线图》 ⭐⭐ （演进） → 单体架构 → SOA 架构 → 微服务架构 ⭐⭐⭐⭐ SOA 两种定义：应用角度=应用框架；软件原理角度=组件模型 SOA vs 微服务： ESB集中式 → 去中心化分布式；远程通信 → RESTful；相对共享 → 数据源唯一 微服务四大挑战：分布式复杂性 / 分区数据库(CAP·最终一致) / 测试(需启动全部依赖服务) / 部署监控

关键术语中英文对照速查表

备考建议

这一章是系统架构设计师考试中架构设计板块的重中之重——面向服务架构（SOA）与微服务贯穿了现代系统架构演进的主线，选择题、案例分析题、论文题均有高频命中，是必须拿下的得分章。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 先拿下选择题最高频的 12 条 ：Web 服务三剑客（SOAP/WSDL/UDDI）、ESB 两套能力清单与"位置透明/协议透明"、SOA vs 微服务区别、微服务五大优势、REST 四概念、SOAP 四部分、WSDL 七元素、SOA 八项设计原则、XML 是 SOA 基石、SOA 三阶段、SOA 两种定义、BPEL 作用。这些是选择题的基本盘，务必看到题干即能应答。

：Web 服务三剑客（SOAP/WSDL/UDDI）、ESB 两套能力清单与"位置透明/协议透明"、SOA vs 微服务区别、微服务五大优势、REST 四概念、SOAP 四部分、WSDL 七元素、SOA 八项设计原则、XML 是 SOA 基石、SOA 三阶段、SOA 两种定义、BPEL 作用。这些是选择题的基本盘，务必看到题干即能应答。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 吃透两个"超级核心" ：SOA vs 微服务区别（架构形态/服务存在方式/接口/数据/耦合扩展五维度）、ESB（基本特征+核心功能 6 项+作用），它们选择题与案例题双线高频。

：SOA vs 微服务区别（架构形态/服务存在方式/接口/数据/耦合扩展五维度）、ESB（基本特征+核心功能 6 项+作用），它们选择题与案例题双线高频。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 案例题专项训练 ：重点练三类能力——① 结合场景判断 SOA 还是微服务；② 判断服务接口粒度是否恰当（外部粗粒度、内部细粒度、操作语义相关）；③ 根据描述识别 SOAP/WSDL/UDDI/REST 的作用。

：重点练三类能力——① 结合场景判断 SOA 还是微服务；② 判断服务接口粒度是否恰当（外部粗粒度、内部细粒度、操作语义相关）；③ 根据描述识别 SOAP/WSDL/UDDI/REST 的作用。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 论文题提前备好 4 篇框架 ：论 SOA 的设计与实现、论微服务架构的优势/挑战/选型、论 ESB 在企业集成中的应用、论 REST 架构风格。每篇按文中论点框架展开即可保证结构完整。

：论 SOA 的设计与实现、论微服务架构的优势/挑战/选型、论 ESB 在企业集成中的应用、论 REST 架构风格。每篇按文中论点框架展开即可保证结构完整。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 借助时间轴与中英文对照表辅助记忆 ：SOA 三阶段标志、架构演进路线（单体→SOA→微服务）、核心术语的中英文与关键含义对照，能高效巩固易混知识点。

：SOA 三阶段标志、架构演进路线（单体→SOA→微服务）、核心术语的中英文与关键含义对照，能高效巩固易混知识点。

• ▪▪ ▪ ▪ ▪ ▪ ▪ 牢记两条重要结论 ： "SOA 不仅仅是一个技术，而是一个软件架构" ；构建 SOA 时 集成功能应由服务提供而非特定应用程序 ，且 无状态接口是服务接口的最佳选择 （便于重用，传入请求含完成操作所需全部信息、不受调用顺序影响）。

： "SOA 不仅仅是一个技术，而是一个软件架构" ；构建 SOA 时 集成功能应由服务提供而非特定应用程序 ，且 无状态接口是服务接口的最佳选择 （便于重用，传入请求含完成操作所需全部信息、不受调用顺序影响）。

遇到场景分析题时，可以尝试从问题本质出发——"这是架构选型问题还是接口设计问题？是服务粒度不恰当还是耦合过高？是协议识别错误？"—这个思路或许能帮你快速锁定正确选项！