18.1 SOA 的相关概念

（1）SOA 的定义。从软件的基本原理定义，可以认为 SOA 是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约
联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以一种统一和通用的
方式进行交互。

（2）业务流程与业务流程执行语言（Business Process Execution Language，BPEL）。业务流程是指为了实现某种业务目的行为所进行的流程或一系列动作。
使用 BPEL，用户可以通过组合、编排和协调 Web 服务自上而下地实现面向服务的体系结构。BPEL 目前用于整合现有的 Web Services，将现有的
Web Services
按照要求的业务流程整理成为一个新的 Web Services，在这个基 础上，形成一个从外界看来和单个 Service 一样的 Service。

18.2 SOA 的发展历史

（1）萌芽阶段：这种广泛使用的 XML，允许组织定义文档的元数据，实现企业内部和企业之间的电子数据交换，规定了服务之间以及服务内部数据交换的格式和结构。
（2）标准化阶段：国际标准和规范—简单对象访问协议（Simple Object Access Protocol，SOAP）、Web 服务描述语言（Web Services
Description
Language，WSDL）及通用服务发现和集成 协议（Universal Description, Discovery and Integration，UDDI）。
（3）成熟应用阶段：3 个重量级规范—SCA、SDO、WS-Policy。SCA 和 SDO 构成了 SOA编程模型的基础，而 WS-Policy 建立了 SOA
组件之间安全交互的规范。

2．SOA 与微服务的区别
（1）微服务相比于 SOA 更加精细，微服务更多地以独立的进程的方式存在，互相之间并无影响。SOA 架构与微服务架构的对比如图所示。

（2）微服务提供的接口方式更加通用化，例如 HTTP RESTful 方式，各种终端都可以调用，无关语言、平台限制。
（3）微服务更倾向于分布式去中心化的部署方式，在互联网业务场景下更适合。

18.3 SOA 的参考架构

IBM 的 Websphere 业务集成参考架构是典型的以服务为中心的企业集成架构，它可划分为 6 大类：

（1）业务逻辑服务（Business Logic Service）。用于实现业务逻辑的服务和执行业务逻辑的能力，其中包括业务应用服务（Business
Application Service）、
业务伙伴服务（Partner Service）以及应用和信息资产（Application and Information Asset）。
（2）控制服务（Control Service）。包括实现人（People）、流程（Process）和信息（Information） 集成的服务，以及执行这些集成逻辑的能力。
（3）连接服务（Connectivity Service）。通过提供企业服务总线，实现分布在各种架构元素中 服务间的连接性。
（4）业务创新和优化服务（Business Innovation and Optimization Service）。用于监控业务系统运行时服务的业务性能，并通过及时了解到的业务性能
和变化，采取措施适应变化的市场。
（5）开发服务（Development Service）。贯彻整个软件开发生命周期的开发平台，从需求分析到建模、设计、开发、测试和维护等全面的工具支持。
（6）IT 服务管理（IT Service Management）。支持业务系统运行的各种基础设施管理能力或服务，如安全服务、目录服务、系统管理和资源虚拟化。

18.4 SOA 主要协议和规范

Web 服务最基本的协议包括 UDDI、WSDL、SOAP，通过它们可以提供直接而又简单的 Web Service 支持，如图

（1）UDDI 协议：统一描述、发现和集成协议。包含了服务描述与发现的标准规范，它使得商业实体能够彼此发现；定义它们怎样在 Internet
上互相作用，
并在一个全球的注册体系架构中共享信息。
（2）Web 服务描述语言（Web Services Description Language，WSDL）：WSDL 是一个用来描述 Web 服务和说明如何与 Web 服务通信的 XML
语言。
描述了 Web 服务的 3 个基本属性。
1）服务做些什么—服务所提供的操作（方法）。
2）如何访问服务—和服务交互的数据格式以及必要协议。
3）服务位于何处—协议相关的地址，如 URL。
（3）SOAP 协议：SOAP 是在分散或分布式的环境中交换信息的简单的协议，是一个基于XML 的协议。
（4）REST 规范：为了让不同的软件或者应用程序在任何网络环境下都可以进行信息的互相传递。微服务对外就是以 REST API
的形式暴露给调用者。RESTful
即 REST 形式的，是对遵循REST 设计思想同时满足设计约束的一类架构设计或应用程序的统称，这一类都可称为 REST ful，
可以理解为资源表述性状态转移：
1）资源：将互联网中一切暴露给客户端的事物都可以看作是一种资源。
2）表述：REST 中用表述描述资源在 Web 中某一个时间的状态。
3）状态转移：分为两种，应用状态—对某个时间内用户请求会话相关信息的快照，保存在客户端。资源状态—在服务端保存，是对某个时间资源请求表述的快照。
4）超链接：通过在页面中嵌入链接和其他资源建立联系。

18.5 SOA 设计的标准要求

（1）文档标准化。SOA 服务具有平台独立的自我描述 XML 文档。Web 服务描述语言是用于描述服务的标准语言。
（2）通信协议标准。SOA 服务用消息进行通信，该消息通常使用 XML Schema 来定义（也称作 XML Schema Definition，XSD）。
（3）应用程序统一登记与集成。在一个企业内部，SOA 服务通过一个扮演目录列表 （Directory Listing）角色的登记处（Registry）来进行维护。
应用程序在登记处（Registry）寻找并 调用某项服务。统一描述、定义和集成是服务登记的标准。
（4）服务质量（QoS）主要包括：
1）可靠性：服务消费者和服务提供者之间传输文档时的传输特性（且仅仅传送一次、最多传送一次、重复消息过滤、保证消息传送）。
2）安全性：Web 服务安全规范用来保证消息的安全性。
3）策略：服务提供者有时候会要求服务消费者与某种策略通信。例如，服务提供商可能会要求消费者提供 Kerberos 安全标示才能取得某项服务。
4）控制：在 SOA 中，进程是使用一组离散的服务创建的。BPEL4WS 或者 WSBPEL（Web Service Business Process Execution
Language）是用来控制
这些服务的语言。
5）管理：针对运行在多种环境下的所有服务，必须有一个统一管理系统，以便系统管理员能够有效管理。任何根据 WSDM 实现的服务都可以由一个
WSDM 适应
（WSDM-compliant）的管理方案来管理。

18.6 SOA 的作用与设计原则

（1）SOA 的主要作用：打破信息孤岛，把应用和资源转换成服务。以及把这些服务变成标准的服务，形成资源的共享
（2）SOA 的设计原则主要有：
1）无状态。以避免服务请求者依赖于服务提供者的状态。
2）单一实例。以高内聚的实现方法，来避免功能冗余。
3）明确定义的接口。服务的接口由 WSDL 定义，用于指明服务的公共接口与其内部专用实现之间的界线。
4）自包含和模块化。服务封装了那些在业务上稳定、重复出现的活动和组件，实现服务的功能实体是完全独立自主的，独立进行部署、版本控制、自我管理和恢复。
5）粗粒度。服务数量不应该太大，依靠消息交互而不是远程过程调用（Remote Procedure Call， RPC），通常消息量较大，但是服务之间的交互频度较低。
6）服务之间的松耦合性。服务使用者看到的是服务的接口，其位置、实现技术和当前状态等对使用者是不可见的，服务私有数据对服务使用者是不可见的。
7）重用能力。服务应该是可以复用的。
8）互操作性、兼容和策略声明。为了确保服务规约的全面和明确，利用策略来定义可配置的互操作语义，来描述特定服务的期望、控制其行为。利用策略声明
确保服务期望和语义兼容性方面的完整和明确。

18.7 SOA 的设计模式

1．服务注册表模式
服务注册表支持驱动 SOA 治理的服务合同、策略和元数据的开发、发布和管理。
（1）服务注册：应用开发者，也叫服务提供者，向注册表公布它们的功能。
（2）服务位置：也就是服务应用开发者，帮助它们查询注册服务，寻找符合自身要求的服务。
（3）服务绑定：服务的消费者利用检索到的服务合同来开发代码，开发的代码将与注册的服务绑定、调用注册的服务以及与它们实现互动。
2．企业服务总线模式
企业服务总线模式提供一种标准的软件底层架构，各种程序组件能够以服务单元的方式“插入” 到该平台上运行，并且组件之间能够以标准的消息通信方式来进行交互。
其核心功能如下：
（1）提供位置透明性的消息路由和寻址服务。程序组件之间无须关注对方的路由和寻址。
（2）提供服务注册和命名的管理功能。
（3）支持多种消息传递范型（如请求/响应、发布/订阅等）。
（4）支持多种可以广泛使用的传输协议。
（5）支持多种数据格式及其相互转换。
（6）提供日志和监控功能。
3．微服务模式
微服务架构将一个大型的单个应用或服务拆分成多个微服务，可扩展单个组件而不是整个应用程序堆栈，从而满足服务等级协议。微服务架构围绕业务领域将服务进行拆分，
每个服务可以独立进行开发、管理和迭代，彼此之间使用统一接口进行交流，实现了在分散组件中的部署、管理与服务功能，使产品交付变得更加简单，从而达到
有效拆分应用，实现敏捷开发与部署的目的。微服务模式的特点如下：
（1）复杂应用解耦：微服务架构将单一模块应用分解为多个微服务，同时保持总体功能不变。
（2）独立：微服务在系统软件生命周期中是独立开发、测试及部署的。
（3）技术选型灵活：微服务架构下系统应用的技术选型是去中心化的，每个开发团队可根据自身应用的业务需求发展状况选择合适的体系架构与技术。
（4）容错：由于各个微服务相互独立，故障会被隔离在单个服务中，并且系统其他微服务可通过重试、平稳退化等机制实现应用层的容错，从而提高系统应用的容错性。
（5）松耦合，易扩展：微服务架构中每个服务之间都是松耦合的，可以根据实际需求实现独立扩展，体现微服务架构的灵活性。单体应用架构与微服务架构的示意如图

4．微服务架构模式方案
微服务架构模式方案主要包括：
（1）聚合器微服务：聚合器充当流程指挥者，调用多个微服务实现系统应用程序所需功能。
（2）链式微服务：客户端或服务在收到请求后，会发生多个服务间的嵌套递归调用，返回经过合并处理的响应。
（3）数据共享微服务：该模式适用于在单体架构应用到微服务架构的过渡阶段，服务之间允许存在强耦合关系，例如存在多个微服务共享缓存与数据库存储的现象。
（4）异步消息传递微服务：对于一些不必要以同步方式运行的业务逻辑，可以使用消息队列 代替 REST 实现请求、响应，加快服务调用的响应速度。
5．微服务架构面临的问题与挑战
（1）服务发现与服务调用链跟踪变得困难。
（2）很难实现传统数据库的强一致性，转而追求最终一致性。

18.8 构建 SOA 架构时应该注意的问题

（1）原有系统架构中的集成需求包括：应用程序集成的需求、终端用户界面集成的需求、流程集成的需求以及已有系统信息集成的需求。
（2）服务粒度的控制以及无状态服务的设计的表述如下。
1）服务粒度的控制：对于将暴露在整个系统外部的服务推荐使用粗粒度的接口，而相对较细粒度的服务接口通常用于企业系统架构的内部。
2）无状态服务的设计：SOA 系统架构中的具体服务应该都是独立的、自包含的请求，在实现这些服务的时候不需要前一个请求的状态，也就是说服务不应该依赖于其他
服务的上下文和状态，即 SOA 架构中的服务应该是无状态的服务。

18.9 SOA 实施的过程

（1）选择 SOA 解决方案主要从以下 3 个方面进行：
1）尽量选择能进行全局规划的方案。
2）选择时充分考虑企业自身的需求。
3）从平台、实施等技术方面进行考察。
（2）业务流程分析主要关注：
1）建立服务模型：自顶向下分解法、业务目标分析法、自底向上分析法。
2）建立业务流程：建立业务对象（实体、过程、事件等业务对象）、建立服务接口、建立服务流程。