系统构架师学习 第二十章

第二十章  面向服务的架构

服务是一个由服务提供者提供的，用于满足使用者请求的业务单元。

在 SOA中，服务的概念有了延伸，泛指系统对外提供的功能集。

20.1  SOA 的相关概念

20.1.1  SOA 的定义

面向服务的体系结构（Service-Oriented Architecture，SOA）

从应用的角度定义：是一种应用框架，着眼于日常的业务应用，并将它们划分为单独的业务功能和流程，即所谓的服务。

从软件的基本原理定义：是一个组件模型，将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。

20.1.2  业务流程 与 BPEL

由于业务流程来源于现实世界，传统上是通过复杂的语言进行描述。

BPEL（Bussess Process Execution Language For Web Services）面向Web服务的业务流程执行语言。

提供了一种相对简单易懂的方法，可将多个Web服务组合到一个新的服务服务（称作业务流程）中。

将现有的 Web Services 按照要求的业务流程整理成为一个新的 Web Services，形成一个从外界看来和单个 Service 一样的 Service。

20.2  SOA 的发展历史

为了能够将公司的业务打包成独立的、具有很强伸缩性的基于因特网的服务，人们提出了 Web服务的概念，这可以说是 SOA 的起源。

1、萌芽阶段

以 XML 技术为标志，XML 的出现无疑为 SOA 的兴起奠定了稳固的基石。

2、标准化阶段

2000年以后，出现了三个著名的 Web 服务标准和规范：简单对象访问协议（Simple Object Access Protocal，SOAP）、Web 服务描述语言（Web Services Descriptin Language，WSDL）、通用服务发现和集成协议（Universal Discovery Description and Integration，UDDI）。

Web 服务也是因特网 Web 2.0 时代的一项重要特征。

3、成熟阶段

从2005年开始，体现在三个重量级规范上：SCA/SDO/WS-Policy，标志着 SOA进入了实施阶段。

美国实现 SOA 架构的关键任务是：对已有系统中的功能进行提取和包装，形成标准的“服务”。

大量“服务”需要全新构造才是中国 SOA 的主要任务。

20.3  SOA 的参考架构

以服务为中心的企业集成采用“关注分离（Separation of Concern）”的方法规划企业集成中的各种架构元素。

从服务为中心的角度来看，企业集成的架构 分为 6大类：

1、业务逻辑服务（Business Logic Service）

2、控制服务（Control Service）

3、连接服务（Connectivity Service）

4、业务创新和优化服务（Business Innovation and Optimization Service）

5、开发服务（Development Service）

6、IT 服务管理（IT Service Management）

1、连接服务——企业服务总线（Enterprise Service Bus，ESB）

采用了“总线”这样一种模式 来管理和简化 应用之间的集成拓扑结构。

2、业务逻辑服务

1. 整合已有应用——应用和信息访问服务

2. 整合新开发的应用——业务应用服务

3. 整合客户和业务伙伴（B2C/B2B）——伙伴服务

3、控制服务

1. 数据整合——信息服务

2. 流程整合——流程服务

3. 用户访问整合——交互服务

4、开发支持

企业集成的开发工具需要有标准的工具框架，这些工具能够以即插即用方式支持来自多家厂商的开发工具，支持整个软件开发周期，以提高开发过程中各种角色的生产力。

5、业务创新和优化

业务创新和优化服务以业务性能管理（Business Process Management，BPM）技术为核心提供业务事件发布、收集、关键业务指标监控能力。

业务创新和优化服务与开发服务是紧密相连的。

6、管理支持

20.4  SOA 主要技术和标准

Web 服务作为实现 SOA 中服务的最主要手段。

20.4.1  UDDI 协议

UDDI（统一描述、发现和集成协议）计划是一个广泛的、开放的行业计划，它使得商业实体能够彼此发现；定义它们怎样在 Internet 上互相作用，并在一个全球的注册体系架构中共享信息。

UDDI 规范利用了 W3C 和 Internet 工程任务组织的很多标准作为其实现基础，如 XML、HTTP、DNS 等协议。

20.4.2  WSDL 规范

WSDL（Web Services Description Language，Web 服务描述语言），用来描述 Web 服务 和 说明如何与 Web服务通信的 XML 语言。

通过 WSDL，可描述的三个基本属性：

1、服务做些什么

2、如何访问服务

3、服务位于何处

WSDL 文档被分为两种类型：服务接口（Service Interface）和服务实现（Service Implementations）

20.4.3  SOAP 协议

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

20.5  SOA 的特性

20.5.1  文档标准化

20.5.2  通信协议标准

20.5.3  应用程序统一登记与集成

20.5.4  服务品质（Quality of Service，QoS）

关键元素有：安全需求（例如认证和授权）、可靠通信。

1、可靠性

仅且仅仅传送一次（Once-and-only-once Delivery）

最多传送一次（At-most-once Delivery）

重复消息过滤（Duplicate Message Elimination）

保证消息传送（Guaranteed Message Delivery）

2、安全性

认证交换、消息完整性、消息保密性，它借助现有的安全标准。

3、策略

服务提供者有时候会要求服务消费者与某种策略通信。

这些要求被定义为策略断言（Policy Assertions），一项策略可能会包含多个断言。

4、控制

整合应用意味着 像 异步通信、并行处理、数据转换，以及校正等进程请求必须被标准化。

5、管理

随着企业服务端增长，所使用的服务和业务进程的数量也随之增加，一个用来让系统管理员管理所有，运行在多种环境下的服务的管理系统就显得尤为重要。

20.6  SOA 的作用

在一个企业内部，可能存在不同的应用系统，由于开发的时间不同，开发工具不同，这些已有应用系统是孤立的，也就是我们常说的“信息孤岛”。

从头建立一个新的基础环境是不可能的。

SOA 凭借其松耦合的特性，使得企业可以按照模块化的方式来添加新服务或更新现有服务，以解决新的业务需要。

在 SOA 得以普及之前，解决企业内部信息系统“信息孤岛”的问题通常采用 EAI（企业应用整合）的方式。

EAI Server 就好像一个“翻译”，让每两个应用之间可以对话，会带来 EAI Server 呈几何倍数的增长。

SOA 对实现企业资源共享，打破“信息孤岛”的步骤如下：

1、把应用和资源转换成服务。

2、把这些服务变成标准的服务，形成资源的共享。

SOA 不仅仅是 一个技术，而是一个软件架构。

20.7 SOA 设计原则

SOA 架构中，继承了来自对象和组件设计的各种原则，如 封装、自我包含等。保证服务的灵活性、松散耦合、重用能力的设计原则。

常见和讨论的设计原则如下：

1、无状态。以避免服务请求着依赖与服务提供者的状态。

2、单一实例。避免功能冗余。

3、明确定义的接口。服务的接口由 WSDL 定义，用于指明服务的公共接口与其内部专用实现之间的界限。

XML 模式（Schema）用于定义所交换的消息格式（即服务的公共数据）。服务定义必须长时间稳定，一旦发布，不能随意更改，服务的定义应尽可能明确，减少使用者的不适当使用。

4、自动包含和模块化。封装了那些业务上稳定、重复出现的活动和组件，实现服务的功能实体是完全独立自主的。

5、粗粒度。服务数量不应该太大。

6、服务之间的松耦合性。其位置、实现技术和当前状态等对使用者是不可见的，服务私有数据对服务使用者是不可见的。

7、重用能力。

8、互操作性、兼容和策略声明。

20.8  SOA 的设计模式

20.8.1  服务注册表模式

服务注册表（Service Registry）主要在 SOA 设计时段使用，虽然它们常常也具有运行时段的功能。

注册表支持驱动 SOA 治理的服务合同、策略、元数据 的开发、发布、管理。

因此，他们提供一个主控制点，或者称为策略执行点（Policy Enforcement Point，PEP）。在这个点上，服务可以在 SOA 中注册和发现。

注册表可以包括有关服务和相关软件组件的配置、遵从性和约束配置文件。任何帮助注册、发现和检索服务合同、元数据和策略的信息库、数据库、目录或其他节点都可以被认为是一个注册表。

主要的服务注册厂商：

一个阵营是提供服务、策略、元数据 注册表 及 信息库的纯 SOA 厂商。

另一个阵营是 SOA 平台厂商，这些厂商将注册表作为集成产品套件的一个组件。

1、注册服务：应用开发者，也叫服务提供者，向注册表公布他们的功能。

2、服务位置：也就是服务应用开发者，帮助他们查询注册服务，寻找符合自身要求的服务。

3、服务绑定：服务的消费者利用检索到的服务合同来开发代码，开发代码将与注册的服务绑定、调用注册的服务以及与他们实现互动。

20.8.2  企业服务总线模式

采用点对点的集成方式存在着复杂度高，可管理性差，复用度差，系统脆弱 等问题。

企业服务总线（Enterprise Service Bus，ESB）提供一种标准的软件底层架构，各种程序组件能够以服务单元的方式“插入”到该平台上运行，并且组件之间能够以标准的消息通信方式来进行交互。

支持异构环境中的服务以基于消息和事件驱动模式的交互，并且具有适当的服务质量和可管理性。

本质上是以中间件形式支持服务单元之间进行交互的软件平台。

这种交互过程不再是点对点的直接交互模式，而是由事件驱动的消息交互模式。

ESB最大限度上解耦了组件之间的依赖关系，降低了软件系统互联的复杂性。

ESB 以中间件的方式，提供服务容错、负载均衡、QoS保障和可管理功能。

ESB 的核心功能如下：

1、提供位置透明性的消息路由和寻址服务。

2、提供服务注册和命名的管理功能。

3、支持多种消息传递泛型（如 响应/请求、发布/订阅 等）。

4、支持多种可以广泛使用的传输协议。

5、支持多种数据格式及其相互转换。

6、提供日志和监控功能。

由于采用了基于标准的互联技术，ESP 使得企业内部以及外部系统之间可以很容易地进行异步或同步交互。具有很强的灵活性和扩展性。

服务总线层为整个 EAI 应用环境提供底层支持。

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

20.9.1  原有系统架构中的集成需求

一定要注意对原有系统架构中集成需求进行细致的分析和整理。

可以在系统的开发和维护中缩短产品上市时间，因而可以降低企业系统开发的成本和风险。

因此，当SOA 架构师遇到一个十分复杂的企业系统时，首先考虑的应该是如何重用已有的投资而不是替换遗留系统。

当 SOA 架构师分析原有系统中的集成需求时，不应该只限定为基于组件构建的已有应用程序的集成，必须考虑一些更加具体的集成的类型，主要包括：

应用程序集成的需求；终端用户界面集成的需求；流程集成的需求；已有系统信息集成的需求。

因而，SOA 架构师在着手设计新的体系结构框架时，必须要全面地考虑所有可能的集成需求。

20.9.2  服务粒度的控制以及无状态服务的设计

构建一个企业级的 SOA 系统架构时，关于系统中最重要的元素，首先是：服务粒度的控制；其次是：无状态服务的设计。

1、服务粒度的控制

通常来说，对于将暴露在整个系统外部的服务推荐使用粗粒度的接口，而相对较细粒度的服务接口通常用于企业系统架构的内部。

粗粒度服务接口保证了服务请求着将以一致的方式使用系统中所暴露出的服务。

2、无状态服务的设计

SOA 系统架构中的具体服务应该都是独立的、自包含的请求，在实现这些服务的时候不需要前一个请求的状态，也就是说服务不应该依赖于其他服务的上下文和状态。

当负载增加时，可以向群集中增加机器。（无状态就可以热插拔）

20.10  SOA 实施的过程

20.10.1  选择 SOA 解决方案

选择最佳的解决方案，是保证 SOA 实施成功的前提条件。

总体来说，必须从以下三个方面进行选择：

1、尽量选择能进行全面规划的方案

既需要选择适当的工具，还需要有专业的技术人才。

2、选择时充分考虑企业自身的需求

必须认识到，用于构建 SOA 项目的前期投资将产生巨大效益。

3、从 平台、实施 等技术方面进行考察

首先要考虑的是平台的开放性和对标准的支持。

以往的成功经验总结有6个方面：业务战略和流程、基础架构、构件模块、项目和应用、成本和效益、规划和管理。

20.10.2  业务流程分析

1、建立服务模型

1. 自顶向下分解法

自上而下的领域分解方式从业务着手进行分析，选择端到端的业务流程进行逐层分解至业务活动，并对其间涉及的业务活动和业务对象进行变化分析。

2. 业务目标分析法

通过关键性能指标分析来验证已有业务候选者以及发现遗漏的服务候选者，这可以叫做“目标服务建模（Goal Service Modeling）”。

它的思想是：从企业的业务目标触发，目标分解为子目标，子目标再分派给相关的服务来实现，这样就形成了一颗“目标服务树”。

3. 自底向上分析法

利用已有资产来实现服务，已有资产包括已有系统、套装或定制应用、行业规范或业务模型等。

这也叫做“遗留资产分析”，可以方便地发现哪些在不同的系统中被重复实现的功能模块以及可以复用的功能模块。

2、建立业务流程

1. 建立 业务对象（Business Object，BO）是对数据进行检索和处理的组件，是简单的真实世界的软件抽象。通常位于中间层或业务逻辑层。

业务对象的分类如下：

a. 实体业务对象。表达了一个人、地点、事物或者概念。

b. 过程业务对象。

c. 事件业务对象。

2. 建立服务接口

服务之间的交换可以为有状态、也可以为无状态。

在构建 SOA 的过程中，将无状态接口视为最好的选择，可以方便地供很多服务者应用程序重用。

3. 建立业务流程

流程是指定的活动顺序，包含明确确定的用于提供业务值的输入和输出。

对流程进行建模应当确保捕获的相关信息的一致性及完整性。