15. 面向服务架构设计理论与实践

发表于 更新于 分类于

1 SOA 的相关概念

1.1 SOA 的定义

  • 面向服务的体系结构 (Service-Oriented Architecture,SOA)是一种应用框架，将应用划分为独立的业务功能单元，称为服务。
  • 服务是软件代理，为满足使用者请求的业务单元，服务提供者和使用者都是软件代理。

1.2 业务流程与 BPEL

  • 业务流程指为实现业务目的行为进行的流程或一系列动作。
  • BPEL（Business Process Execution Language）是面向 Web 服务的业务流程执行语言。

2 SOA 的发展历史

2.1 SOA 的发展历史

  • SOA 概念最初由 Gartner Group 提出，随着因特网的浪潮，企业将业务转移到因特网领域。
  • SOA 的发展最初始于国外，其经历了如下三个阶段：萌芽阶段、标准化阶段、成熟应用阶段。

2.2 国内 SOA 的发展现状与国外对比

2007 年， IDC 发布了 《SOA 中国路线图》。报告中指出在中国过去近 30 年的IT建设多为生产型系统，服务型系统普遍未开始建设，大量“服务”需要全新构造才是中国 SOA 的主要任务。

2.3 SOA 的微服务化发展

应用系统架构也经历了从简到繁、从单体架构到 SOA 架构再至微服务架构的演进过程。这导致 SOA 架构向更细粒度、更通用化程度发展，就成了所谓的微服务了。

SOA 与微服务的区别在于如下几个方面：

  • 微服务架构是 SOA 架构的进一步优化，去除了 ESB 企业服务总线。
  • 微服务架构是分布式架构，服务独立，数据独立，应用极易扩展和维护。

总而言之，微服务架构是 SOA 架构思想的一种扩展，更加强调服务个体的独立性、拆分粒度更小。

3 SOA 参考架构

IBM 的 Websphere 业务集成参考架构为典型的以服务为中心的企业集成架构。

架构组成

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

1.开发服务

开发环境和工具中为不同开发者的角色提供的功能被称为开发服务。根据开发过程中开发者角色和职责的不同，有如下 4 类服务。

  1. 建模服务 (ModelService): 用于构建可视化的业务流程模型
  2. 设计服务 (Design Service): 根据业务模型，进一步分解为服务组件，设计服务用于设计和开发这些服务组件。
  3. 实现服务 (Implementation Service): 用于将设计和开发的服务组件部署到生产环境中。
  4. 测试服务 (Test Service): 支持服务组件的单元测试和系统的集成测试。

2.业务创新和优化

业务创新和优化服务以业务性能管理 (Business Process Management,BPM) 技术为核心提供业务事件发布、收集和关键业务指标监控能力。具体而言，业务创新和优化服务由以下服务组成。

  1. 公共事件框架服务 (Common Event Infrastructure Service): 通过一个公共事件框架提供IT和业务事件的激发、存储和分类等。
  2. 采集服务 (Collection Service): 通过基于策略的过滤和相关性分析检测感兴趣的服务。
  3. 监控服务 (Monitoring Service): 通过事件与监控上下文间的映射，计算和管理业务流程的关键性能指标 (Key Performance Indicators,KPI)。

3.控制服务

数据整合——信息服务
流程整合——流程服务
用户访问整合——交互服务

4.连接服务-企业服务总线

ESB 是过去消息中间件的发展，采用“总线”模式来管理和简化应用之间的集成拓扑结构。

ESB 的基本特征和能力包括：描述服务的元数据和服务注册管理；在服务请求者和提供者之间传递数据，以及对这些数据进行转换的能力，并支持由实践中总结出来的一些模式如同步模式、异步模式等；发现、路由、匹配和选择的能力，以支持服务之间的动态交互，解耦服务请求者和服务提供者。

5.业务逻辑服务

  • 整合已有应用——应用和信息访问服务
    • 以服务为中心的企业集成通过应用和信息访问服务 (Application and Information Access Service) 来实现对已有应用和信息的集成。
  • 整合新开发的应用——业务应用服务
  • 整合客户和业务伙伴 (B2C/B2B)——伙伴服务
    • 以服务为中心的企业集成通过伙伴服务提供与企业外部的 B2B 的集成能力。

6.IT 服务管理

为业务流程和服务提供安全、高效和健康的运行环境，也是以服务为中心的企业集成重要的部分，它由IT服务管理来完成。 IT 服务管理包括如下两部分。

  1. 安全和目录服务 (Security and Directory Service): 企业范围的用户、认证和授权管理，如单点登录 (SSO)。
  2. 系统管理和虚拟化服务 (System Management and Virtualization Service): 用于管理服务器、存储、网络和其他 IT 资源。

4 SOA主要协议和规范

4.1 UDDI 协议

  • UDDI（统一描述、发现和集成协议）是一个全球性的行业计划，使商业实体能够彼此发现，定义它们怎样在 Internet 上互相作用。
  • UDDI 规范用于 W3C 和 Internet 工程任务组的很多标准作为其实现基础，如 XML、HTTP 和 DNS 等协议。
  • UDDI 服务位于某处——协议相关的地址，如 URL。

4.2 WSDL 规范

  • WSDL（Web Services Description Language）是一个用来描述 web 服务和说明如何与 web 服务通信的 XML 语言。
  • WSDL 文档基本结构包括 types、message、operation 和 binding 等元素。

4.3 SOAP 协议

  • SOAP 是在分散或分布式的环境中交换信息的简单协议，是一个基于 XML 的协议。
  • SOAP 协议包括4个部分：SOAP 封装（Envelope），定义了描述消息中的内容是什么，是谁发送的，谁应当接收并处理它们以及如何处理它们的框架；SOAP 编码规则（Encoding Rules），用于表示应用程序需要使用的编码的实例；SOAP RPC 表示（RPC Representation）是远程过程调用和应答的规范；SOAP 绑定（Binding），使用底层协议交换信息。

4.4 REST 规范

  • REST 是一种新的互联网软件架构风格，RESTful 即 REST 式的，为遵循 REST 设计思想同时满足设计约束的一类架构设计或应用程序的统称。
  • REST 定义中状态分为两种：应用状态和资源状态。
  • 资源是一切可通过网络访问的实体，REST 通过超链接实现资源的动态发现。

5 SOA 设计的标准要求

5.1 文档标准化

SOA 服务具有平台独立的自我描述 XML 文档。Web 服务描述语言用于描述服务的标准语言。

5.2 通信协议标准

SOA 服务用消息进行通信，通常使用 XML Schema 定义 ( 也称作 XSD , XML Schema Definition)。

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

在企业内部，SOA 服务通过一个扮演目录列表（Directory Listing）角色的注册处（Registry）来维护。

5.4 服务质量 (QoS)

  • 每个 SOA 服务都有一个与之相关的服务质量 (QoS)。
  • QoS 的关键元素有安全性需求（例如认证和授权）、可靠通信以及谁能调用服务的策略。

SOA 设计的标准要求

  • 可靠性
  • 安全性
  • 策略
  • 控制
  • 管理

7 SOA 的设计原则

  1. 无状态
  • 避免服务请求者依赖于服务提供者的状态。
  1. 单一实例
  • 避免功能冗余。
  1. 明确定义的接口
  • 服务的接口由 WSDL 定义，用于指明服务的公共接口与其内部专用实现之间的界线。
  1. 自包含和模块化
  • 服务封装了那些在业务上稳定、重复出现的活动和组件，实现服务的功能实体是完全独立自主的，独立进行部署、版本控制、自我管理和恢复。
  1. 粗粒度
  • 服务数量不应太大，依靠消息交互而不是远程过程调用（RPC），通常消息比较大，但服务之间的交互频度较低。
  1. 服务之间的松耦合性
  • 服务使用者看到的是服务的接口，其位置、实现技术和当前状态等对使用者是不可见的，服务私有数据对服务使用者是不可见的。
  1. 重用能力
  • 服务应该是可以重用的。
  1. 互操作性、兼容和策略声明
  • 为了确保服务规约的全面和明确，策略成为一个越来越重要的方面。

8 SOA 的设计模式

8.1 服务注册表模式

  • 服务注册表（Service Registry）主要用于 SOA 设计阶段使用。
  • 注册表支持服务合同、策略和元数据的开发、发布和管理。
  • 注册表可以包括有关服务和相关软件组件的配置、遵从性和约束配置文件。

8.2 企业服务总线模式

  • 企业服务总线（Enterprise Service Bus, ESB）是 SOA 治理的核心组件。
  • ESB 提供位置透明性的消息路由和寻址服务，支持多种消息传递范围和传输协议。

8.3 案例研究：SynchroESB

产品背景

  • 国家高新技术产业化计划支持，西安协同时光软件 + 西北工业大学联合研发。
  • 基于 SOA，以 ESB 为底层，提供预制组件、集中管理、可视化开发。

四层结构

  1. 服务总线层：底层连通，统一消息路由。
  2. 数据转换与适配器层：解决异构系统连接与接口差异。
  3. 流程整合层：编排跨系统业务流程，提供设计、监控、规划功能。
  4. 用户交互层：统一门户入口，聚合内外部信息。

核心特性

  • 粗颗粒组件编程模型，支持组件复用与拖拽式流程搭建。
  • 事件驱动架构，快速响应业务变化。
  • 分布式部署 + 集中式管理，避免单点瓶颈，保护现有投资。

8.4 微服务模式

8.4.1 微服务架构概述

微服务架构将一个大型的单个应用或服务拆分成多个微服务，可扩展单个组件而不是整个应用程序堆栈，从而满足服务等级协议。微服务架构围绕业务领域将服务进行拆分，每个服务可以独立进行开发、管理和迭代，彼此之间使用统一接口进行交流，实现了在分散组件中的部署、管理与服务功能，使产品交付变得更加简单，从而达到有效拆分应用，实现敏捷开发与部署的目的。

特点：

  1. 复杂应用解耦
  2. 独立
  3. 技术选型灵活
  4. 容错
  5. 松耦合，易拓展

8.4.2 微服务架构模式方案

微服务是一种软件架构演变后的新型架构风格，是系统应用开发的一种设计思想，没有固定开发模式。

常见的微服务设计模式：

  1. 聚合器微服务：在聚合器微服务中，聚合器调用多个微服务实现系统应用程序所需功能
  2. 链式微服务：客户端或服务在收到请求后，会返回一个经过合并处理的响应
  3. 数据共享微服务：在该模式下，当服务之间存在强耦合关系时，可能存在多个微服务共享缓存与数据库存储的现象。
  4. 异步消息传递微服务：对于一些不必要以同步方式运行的业务逻辑，可以使用消息队列代替 REST 实现请求、响应，加快服务调用的响应速度
  5. 代理微服务设计模式
  6. 分支微服务设计模式

8.4.3 微服务架构面临的问题与挑战

其中一个主要缺点是微服务架构分布式特点带来的复杂性，开发过程中，需要基于 RPC 或消息实现微服务之间的调用与通信，使服务发现与服务调用链跟踪变得困难。

另一个挑战是微服务架构的分区数据库体系，不同服务拥有不同数据库。受限于 CAP 原理约束以及 NoSQL 数据库的高扩展性，使人们不得不放弃传统数据库的强一致性，转而追求最终一致性，因此对开发人员出了更高要求。

微服务架构给系统测试也带来了很大挑战，微服务架构可能涉及多个服务，传统的单体 Web 应用只需测试单一 API 即可，然而对于微服务架构测试，需要启动其依赖的所有服务，该复杂性不可低估。在大规模应用部署中，在监控、管理、分发及扩容等方面，微服务也存在着巨大挑战。

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

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

  • 基于 SOA 的企业架构通常在当前投资基础上演进，优先重用而非替换遗留系统，以降低成本与风险。
  • 集成需求类型：应用程序、终端界面、流程、已有系统信息集成四类；需全面识别，由服务统一提供集成能力。

9.2 服务粒度的控制与无状态服务设计

1. 服务粒度

  • 外部接口建议粗粒度，保证一致性并降低交互模式易变性；内部可用细粒度操作。
  • 可用 BPEL 将多个细粒度操作编排成粗粒度服务。

2. 无状态服务

  • 服务应自包含，不依赖上下文状态，提升可伸缩与可靠性。
  • J2EE场景下常用无状态 SessionBean 暴露 Web 服务，利用 EJB 容器提供的并发、安全、事务和集群能力。

10 SOA 实施过程

10.1 选择 SOA 解决方案

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

  1. 尽量选择能进行全局规划的方案
  2. 选择时充分考虑企业自身的需求
  3. 从平台、实施等技术方面进行考察

10.2 业务流程分析

10.2.1 建立服务模型

  1. 自顶向下分解法：从业务着手进行分析，选择端到端的业务流程进行逐层分解至业务活动，并对其间涉及的业务活动和业务对象进行变化分析。
  2. 业务目标分析法：通过关键性能指标分析来验证已有服务候选者以及发现遗漏的服务候选者。
  3. 自底向上分析法：目的是利用已有资产来实现服务，已有资产包括已有系统、套装或定制应用、行业规范或业务模型等。这也可以称为“遗留资产分析”。

10.2.2 建立业务流程

10.2.2.1 建立业务对象
  • 业务对象位于中间层，是对真实世界实体的软件抽象，支持知识重用。
  • 分类：
    • 实体业务对象：人、地点、事物或概念（客户、订单、物品）。
    • 过程业务对象：业务处理过程或工作流任务。
    • 事件业务对象：系统操作产生的事件。
10.2.2.2 建立服务接口
  • 接口应语义相关，避免单操作或过多操作；优先无状态设计，请求消息包含完成操作所需的全部信息。
  • 有状态示例：先 setCustomerNumber 再 getCustomerInfo；无状态更利于重用与扩展。
10.2.2.3 建立业务流程
  • 流程：指定活动顺序，含明确输入输出，可提取客户搜索请求并生成文档列表。
  • 建模步骤：
    1. 收集需求 → 划分子流程。
    2. 识别组件、服务、数据、策略、测量。
    3. 用流程元素（可复用构件）定义可复用段，如登录、定价。
    4. 通过控制流连接活动与决策点，按业务规则决定路径。
  • 工具：WebSphere Business Integration Modeler 导出给工作流开发人员，实现模型到代码无缝衔接。