原子标签索引：[概念×13 | 机制×4 | 流程×4 | 决策×1 | 分类体系×12 | 判据×3 | 案例×2 | 数据×1] 上游：第2章（构件与中间件）、第5章（软件架构风格） 下游：第14章（SOA 的微服务化发展）
标准表述
- 服务：由服务提供者提供、用于满足使用者请求的业务单元；在 SOA 中泛指系统对外提供的功能集。
- SOA 应用角度定义：一种应用框架，把日常业务应用划分为单独的业务功能和流程（即服务），可构建、部署、整合服务而无需依赖应用程序及其运行平台。
- SOA 原理角度定义（对架构师更具指导性）：一个组件模型，将应用程序的不同功能单元（服务）通过定义良好的接口和契约联系起来；接口采用中立方式定义，独立于硬件平台、操作系统和编程语言。
- BPEL：面向 Web 服务的业务流程执行语言（亦写作 BPEL4WS），通过组合、编排和协调 Web 服务自上而下实现 SOA。
- SOA 发展三阶段：萌芽阶段（XML 为标志）→ 标准化阶段（SOAP、WSDL、UDDI 三剑客）→ 成熟应用阶段（2005 年起，SCA/SDO/WS-Policy 三大规范，标志 SOA 进入实施阶段）。
- SCA 和 SDO 构成 SOA 编程模型的基础；WS-Policy 建立 SOA 组件间安全交互的规范。
- Web 服务三剑客：SOAP（简单对象访问协议）、WSDL（Web 服务描述语言）、UDDI（通用服务发现和集成协议）。
- WSDL 描述服务三个基本属性：做什么（操作）、如何访问（数据格式与协议）、位于何处（协议相关地址如 URL）。
- SOAP 四部分：封装（Envelop）、编码规则（Encoding Rules）、RPC 表示（RPC Representation）、绑定（Binding）。
- SOAP 两个主要设计目标：简单性和可扩展性。
- REST = 表述性状态转移，四要素：资源、表述、状态转移、超链接；REST 是一种设计风格而不是架构。
- ESB 核心功能：位置透明的消息路由寻址、服务注册和命名管理、多消息传递范型、多传输协议、多数据格式及转换、日志和监控。
- ESB 是一种架构模式，不能简单等同于特定技术或产品。
- SOA 设计原则（8 条）：无状态、单一实例、明确定义的接口、自包含和模块化、粗粒度、服务间松耦合、重用能力、互操作性/兼容和策略声明。
- 微服务与 SOA 三区别：微服务更精细、以独立进程存在；接口更通用化（HTTP RESTful）；倾向分布式去中心化部署。
- 微服务架构是 SOA 的进一步优化：去除 ESB，真正去中心化，服务独立、数据源唯一。
蒸馏笔记
概念
- SOA：面向服务的体系结构；系统整体拆分为多个独立功能模块，模块间通过接口交互、松耦合。
- 业务流程：为实现某种业务目的的行为所进行的流程或一系列动作。
- BPEL：将多个 Web 服务组合成新的复合服务（业务流程）；用于整合现有 Web Services 形成外界看来如同单个 Service。
- ESB：由中间件技术实现的、支持 SOA 的基础软件平台；支持异构环境中服务以消息和事件驱动模式交互；是过去消息中间件的发展。
- UDDI：统一描述、发现和集成协议；全球注册体系，实现服务描述与发现；基于 XML、HTTP、DNS，采用 SOAP 早期版本。
- WSDL：Web 服务接口定义语言；文档分服务接口与服务实现两类。
- SOAP：分散或分布式环境中基于 XML 的信息交换简单协议。
- REST：表述性状态转移；微服务对外以 REST API 形式暴露。
- RESTful：遵循 REST 设计思想并满足其设计约束的一类架构/应用的统称。
- SCA/SDO：SOA 编程模型基础（构件模型/数据模型）。
- 服务注册表：SOA 设计时段使用，提供服务合同、策略和元数据的开发、发布与管理，是策略执行点（PEP）。
- EAI：企业应用整合；SOA 普及前解决信息孤岛的方式，需为每对应用配 EAI Server。
- QoS：每项 SOA 服务关联的服务质量；关键元素含安全需求（认证授权）、可靠通信、调用策略。
机制
- ESB 解耦机制：请求者发标准化消息 →(按服务名/接口名查找目的组件) ESB 转发消息 → 结果逆向返回；实现位置透明与协议透明。
- ESB 中介过程依靠服务注册管理及问题域知识自动进行，请求者与提供者无需介入，双方接口不变即可独立演变。
- EAI 之弊：n 个应用互通需 n(n-1)/2 个"翻译"（EAI Server）→ 几何级增长 → 不可持续；SOA 以"应用资源转成服务→服务标准化共享"两步替代。
- BPM 闭环：建模阶段确定 KPI → 构建为事件标志 → 运行时事件被公共事件框架截获 → 采集服务过滤 → 监控服务计算 KPI → 用于重构优化流程（持续迭代）。
流程
- SOA 实施三选择：①尽量选能全局规划的方案（全面评估系统→选工具技术→边学边实践开发）②充分考虑企业自身需求（SOA 通过共享服务优化业务流程，"价值机会"超传统项目）③从平台、实施等技术考察（平台看开放性和标准支持；实施经验 6 方面：业务战略和流程、基础架构、构建模块、项目和应用、成本和效益、规划和管理；供应商看产品匹配度、成功案例、专业服务能力）。
- 建立服务模型三法：①自顶向下分解——从端到端业务流程逐层分解至业务活动，业务活动树上每个节点都是服务候选者，划分到业务组件后形成层次化服务目录；变化分析分离易变与稳定部分 ②业务目标分析——KPI 分解为子目标再分派给服务，形成"目标服务树"，叶子节点服务可回溯业务目标 ③自底向上——遗留资产分析，建立已有系统功能模块目录，发现重复/可复用模块包装为服务。
- 建立业务流程三步：①建立业务对象（实体/过程/事件三类）②建立服务接口（操作应语义相关；无状态接口最好，请求消息应含完成操作的所有必要信息）③建立业务流程（BP 分成子流程→分析确定组件、服务、输入输出、策略、测量→用流程元素等可复用构件编码）。
- 打破信息孤岛两步：①把应用和资源转换成服务 ②把服务标准化，形成资源共享。
决策
| 决策点 | 结论 | 理由 |
|---|---|---|
| 服务粒度（对外） | 粗粒度接口 | 保证请求者以一致方式使用服务，避免暴露易变的交互模式 |
| 服务粒度（对内） | 细粒度接口 | 灵活性高，供内部组合；可用 BPEL 将细粒度操作组成粗粒度服务接口 |
| 无状态服务实现 | 无状态 Session Bean（EJB 端点） | EJB 容器自动提供并发、安全、事务支持与集群/池化管理，可伸缩性强 |
| Web 服务可访问的 EJB | 仅无状态 Session Bean | 不能访问有状态 Session Bean、实体 Bean、消息驱动 Bean |
分类体系
- SOA 发展三阶段：萌芽（20 世纪 90 年代末~21 世纪初，XML 为基石：规定数据交换格式结构，XSD 保障消息完整性，XSLT 使不同数据表达经 Schema 映射互通）；标准化（2000 年后，SOAP/WSDL/UDDI）；成熟应用（2005 年起，SCA/SDO/WS-Policy）。
- 国内 SOA 现状（2007 年 IDC《SOA 中国路线图》）：美国关键任务=对已有系统功能进行提取和包装成标准服务；中国主要任务=大量"服务"需要全新构造（IT 建设多为生产型系统，服务型系统普遍未建）。
- IBM WebSphere 业务集成参考架构六大类服务：①业务逻辑服务（业务应用服务、业务伙伴服务、应用和信息资产）②控制服务（人、流程、信息的集成）③连接服务（ESB 提供连接性）④业务创新和优化服务（监控运行时业务性能）⑤开发服务（覆盖全生命周期的开发平台）⑥IT 服务管理（安全目录、系统管理、资源虚拟化）。
- 业务逻辑服务细分：应用和信息访问服务（可接入服务 On-Ramp——单向/请求应答/轮询包装；事件发现服务 Event Detect——变化经事件框架发布）；业务应用服务（组件服务——运行时容器：持久化/安全/事务；核心服务——内存管理/对象池/负载均衡/可用性；接口服务——与其他企业系统集成）；伙伴服务（社区服务——伙伴管理，集中式/自我管理；文档服务——RosettaNet、EDI、AS1/AS2；协议服务——传输层认证路由）。
- 控制服务细分：信息服务（联邦/复制/转换/搜索）；流程服务（编排——预定义流程逻辑控制与恢复；事务——短流程两阶段提交、长流程补偿；人工——人参与流程+任务分派授权监管）；交互服务（交付——多渠道多设备同一交互逻辑；体验——个性化/协作/单点登录；资源——运行时交互组件管理）。
- 开发服务四类：建模（可视化业务流程模型）、设计（业务模型分解为服务组件）、实现（部署到生产环境）、测试（单元测试+集成测试）；方法学如 SODA、SOMA；编程模型如 WSDL、BPEL4WS、SCA、SDO。
- 业务创新和优化服务三类：公共事件框架（IT 和业务事件的激发、存储、分类）、采集（基于策略的过滤和相关性分析）、监控（计算管理 KPI）；以 BPM 技术为核心。
- WSDL 服务接口文档七元素：types（数据类型集合）、message（消息数据结构抽象定义）、operation（操作抽象描述，通常为请求/响应消息对）、portType（访问入口点所支持操作的抽象集合）、binding（抽象接口到具体协议/数据格式的绑定）、port（绑定与网络地址组合的单个服务访问点）、service（端口集合）。
- QoS 相关标准五方面：可靠性（WS-Reliability、WS-Reliable Messaging，OASIS 负责）；安全性（认证交换、消息完整性、消息保密，借助 SAML）；策略（WS-Policy，策略断言 Policy Assertions）；控制（BPEL4WS/WSBPEL）；管理（WSDM）；事务另见 WS-Coordination、WS-Transaction。
- 微服务设计模式六种：①聚合器（调用多个微服务，处理数据直接展示或组合成更高层组合微服务）②代理（聚合器的变种，不聚合数据，仅委派请求+数据转换）③分支（聚合器的扩展，允许同时调用两条相互独立的微服务链）④链式（请求沿链依次传递并合并结果；全部同步调用，链未完成前调用方阻塞，链不宜过长）⑤数据共享（单体→微服务过渡阶段，强耦合服务间共享缓存与数据库）⑥异步消息（消息队列代替 REST 实现异步，加快响应；常用 ActiveMQ、RabbitMQ、RocketMQ、Kafka；可能降低可用性、增加复杂性）。
- 微服务五大优势：复杂应用解耦、独立（独立开发/测试/部署）、技术选型灵活（去中心化）、容错（故障隔离+重试/平稳退化）、松耦合易扩展（按需独立扩展）。
- 微服务四类挑战：分布式复杂性（RPC/消息调用，服务发现与调用链跟踪难）；分区数据库体系（受 CAP 约束，弃强一致转最终一致）；测试（需启动所有依赖服务）；大规模部署的监控、管理、分发、扩容。
判据
- 服务粒度恰当性：单接口仅含单个或少量操作 → 粒度可能不当；用很少的服务（或单个服务）包含大量操作 → 同样不当；操作应语义相关。
- 服务定义稳定性：服务定义一旦公布不能随意更改（使用者依赖服务规约调用）；应减少使用者的不适当使用，不暴露私有数据。
- 是否采用微服务：现有架构无法再扩展、数据库增长过快、整个团队（产品/设计/研发/测试/运维）都具备微服务思维 → 收益大于成本；现有架构还能很好工作 → 收益甚微。
案例
- SynchroESB（15.8.3）：西安协同时光与西北工业大学联合研发的协同企业服务总线，四层结构——服务总线层（底层支持）→ 数据转换与适配器层（接入）→ 流程整合层（流程设计/监控/规划）→ 用户交互层（统一信息入口）；"粗颗粒"组件编程模型，事件驱动。
- 服装零售 500 家国际连锁店（15.6）：借 WSDL 接口操作灵活性，换供应商时保持现有系统不动，仅匹配 WSDL 接口并制定新的服务级协定——业务水平改变而内部操作不变。
数据
| 数据项 | 数值 | 含义 |
|---|---|---|
| EAI 翻译器数量 | 2 应用→1；3→3；4→6；5→10 | n 个应用互通需 n(n-1)/2 个 EAI Server，几何倍数增长 |
| IDC《SOA 中国路线图》 | 2007 年发布 | 首份针对中国企业实施 SOA 的权威报告 |
易错点 / 边界情况
- 两种 SOA 定义辨析：应用角度=应用框架；软件原理角度=组件模型——后者对架构师日常工作更具指导性。
- 接口"中立"的含义：独立于实现服务的硬件平台、操作系统和编程语言。
- ESB 的中介转换可"简单到什么也没有"，也可含动态查找选择、消息传递/路由/转换、协议转换。
- WSDL 与 UDDI 分工：WSDL 描述单个服务；UDDI 负责注册与发现；UDDI 并非唯一注册环境。
- SOAP 功能上相交但彼此独立；信封和编码规则定义在不同 XML 命名空间中；分布式垃圾收集、成批传送消息、对象引用、对象激活不属于 SOAP 规范。
- REST 四要素辨析：URI 与资源非一一映射——一个资源可设计多个 URI，一个 URI 只能对应一种资源；应用状态保存在客户端（可与缓存配合降服务端压力），资源状态保存在服务端；超链接包含在应用状态中由客户端维护，是请求过程中添加的而非服务端预设。
- SOAP 基本协议组合是 UDDI+WSDL+SOAP；别与成熟阶段 SCA/SDO/WS-Policy 混淆。
- 事务服务：短流程用两阶段提交，长流程用补偿——判分高频点。
- 服务总线是 SOA 的架构模式之一；SOA 继承了封装、自我包含等对象/组件设计原则。
- 微服务模式辨析：代理不做聚合；分支是聚合器的扩展（两条独立链）；链式全程同步易阻塞；数据共享仅用于过渡阶段；异步消息注意队列选型与可用性代价。
- SOA 与微服务对比题眼：SOA 集中式（ESB 总线）、依赖导致部署复杂；微服务去中心化、去 ESB、数据源唯一。