⬆︎
×
TOC
CHAT
分类 软考高级　6452字　22分钟📤 🖨 📝

系统架构设计理论与实践（5）：面向服务架构

作者

案例分析专题——面向服务架构

在面向服务的体系结构（SOA）中，服务的概念有了延伸，泛指系统对外提供的功能集。例如在一个大型企业内部，可能存在进销存、人事档案和财务等多个系统，在实施SOA后，每个系统用于提供相应的服务，财务系统作为资金运作的重要环节，也向整个企业信息化系统提供财务处理的服务，那么财务系统的开放接口可以看成是一个服务。

1 SOA的相关概念

1.1 面向服务

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

SOA

1.2 服务构件

服务（Service）是一种为了满足某项业务需求的操作、规则等的逻辑组合，它包含一系列有序活动的交互，为实现用户目标提供支持。

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

服务构件

服务构件与传统构件的区别：

  • 服务构件粗粒度；传统构件细粒度居多
  • 服务构件的接口是标准的，主要是WSDL接口；传统构件常以具体API形式出现
  • 服务构件的实现与语言无关；传统构件绑定某种特定语言
  • 服务构件可以通过构件容器提供QoS；传统构件完全由程序代码直接控制

1.3 Web服务（Web Service）

Web Service是对面向服务架构的具体实现，其中的重要角色有：

  1. 服务请求者
  2. 服务提供者
  3. 服务注册中心

Web Service

1.4 业务流程、业务流程执行语言（BPEL）

业务流程（Business Process）是指为了实现某种业务目的行为所进行的流程或一系列动作。

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

2 SOA的发展历史

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

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）：支持业务系统运行的各种基础设施管理能力或服务，如安全服务、目录服务、系统管理和资源虚拟化。

4 主要协议与规范

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

相关功能及其协议如下表所示：

功能 协议
发现服务 UDDI、DISCO
描述服务 WSDL、XML Schema
消息格式层 SOAP、REST
编码格式层 XML（DOM、SAX）
传输协议层 HTTP、TCP/IP、SMTP等
  1. UDDI（Universal Description, Discovery and Integration，统一描述、发现和集成协议）：用于Web服务注册和服务查找。包含了服务描述与发现的标准规范，使得商业实体能够彼此发现；定义它们怎样在Internet上相互作用，并在一个全球的注册体系架构中共享信息。
  2. WSDL（Web Service Description Language，Web服务描述语言） ：用于描述Web服务的接口和操作功能，说明如何与Web服务通信的XML语言，WSDL文件可视为WebService的接口文档（使用说明书）。描述了Web服务的3个基本属性——
    • 服务做些什么——服务所提供的操作（方法）
    • 如何访问服务——和服务交互的数据格式以及必要协议
    • 服务位于何处——协议相关的地址，如URL
  3. SOAP（Simple Objec Access Protocol，简单对象访问协议）：为建立Web服务和服务请求之间的通信提供支持。在分散或分布式的环境中交换信息的简单协议，是一个基于XML的协议。
  4. REST（REpresentational State Transfer，表述性状态转移）规范：为了让不同的软件或者应用程序在任何网络环境下都可以进行信息的互相传递。微服务对外以REST API的形式暴露给调用者。RESTful（REST形式的）是对遵循REST设计思想同时满足设计约束的一类架构设计或应用程序的统称，可理解为资源表述性状态转移——
    1. 资源：将互联网中一切暴露给客户端的事物都可以看做是一种资源。
    2. 表述：REST中用表述描述资源在Web中某一个时间的状态。
    3. 状态转移：分为两种——
      • 应用状态：对某个时间内用户请求会话相关信息的快照，保存在客户端。
      • 资源状态：在服务端保存，是对某个时间资源请求表述的快照。
    4. 超链接：通过在页面中嵌入链接和其他资源建立联系。
  5. BPEL（Business Process Execution Language For Web Services，面向Web服务的业务流程执行语言，BPEL4WS）：一种使用Web服务定义和执行业务流程的语言。使用BPEL，用户可以通过组合、编排和协调Web服务自上而下地实现面向服务的体系结构（SOA）。BPEL提供了一种相对简单易懂的方法，可将多个Web服务组合到一个新的复合服务（称作业务流程）中。（详见下文SOA设计的标准要求-服务质量（QoS）-控制）

REST

REST的5个原则：

  1. 网络上的所有事物都被抽象为资源。
  2. 每个资源对应一个唯一的资源标识。
  3. 通过通用的连接件接口对资源进行操作。
  4. 对资源的各种操作不会改变资源标识。
  5. 所有的操作都是无状态的。

5 SOA设计的标准要求

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

6 SOA的作用与设计原则

SOA的主要作用：打破信息孤岛，把应用和资源转换成服务。以及把这些服务变成标准的服务，形成资源的共享。

SOA的设计原则主要有：

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

7 SOA的设计模式

7.1 服务注册表模式

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

  1. 服务注册：应用开发者，也叫服务提供者，向注册表公布它们的功能。
  2. 服务位置：也就是服务应用的开发者，帮助他们查询注册服务，寻找符合自身要求的服务。
  3. 服务绑定：服务的消费者利用检索到的服务合同来开发代码，开发的代码与注册的服务绑定、调用注册的服务以及它们实现互动。

7.2 企业服务总线（ESB）模式

ESB（Enterprise Service Bus，企业服务总线）是由中间件技术实现并支持SOA的一组基础架构，可与Web Service技术相容。它提供了一种标准的软件底层架构，各种程序组件能够以服务单元的方式“插入”到该平台上运行，并且组件之间能够以标准的消息通信方式来进行交互。

ESB的优势在于消除了服务请求者与服务提供者之间的直接链接，即服务请求者与服务提供者之间解耦。

ESB

ESB的作用：

  1. 提供位置透明性的消息路由和寻址服务，程序组件之间无须关注对方的路由和寻址。
  2. 提供服务注册和命名的管理功能。
  3. 支持多种消息传递范型（如请求/响应、发布/订阅等）。
  4. 支持多种可以广泛使用的传输协议。
  5. 支持多种数据格式及其相互转换。
  6. 提供日志和监控功能。

【拓展】常用于企业应用集成——当企业中各业务系统的运行平台和开发语言差异较大，而且系统所使用的通信协议和数据格式各不相同时，常使用基于总线的集成框架。当需要集成并灵活定义系统功能之间的协作关系时，应该采用基于工作流的功能关系定义方式。

7.3 微服务

微服务（Microservice）是面向服务架构的一种（雕版印刷 vs 活字印刷）

7.3.1 微服务与SOA的区别

微服务实为SOA的派生，但存在如下重大区别（故亦经常称微服务不属于SOA）：

  1. 微服务比SOA更精细，可以独立进程方式存在，互相之间并无影响（架构对比图如下所示）
  2. 微服务提供的接口更通用化，如用HTTP RESTful方式，各种终端均可调用，语言无关，平台无关。
  3. 微服务更倾向于分布式去中心化部署，在互联网场景下更适合。

微服务与SOA

7.3.2 微服务的思想与特点

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

微服务模式的优点：

  1. 复杂应用解耦：微服务架构将单一模块应用分解多个微服务，同时保持总体功能不变——小服务（且专注于做一件事情）、化整为零，易于小团队开发。
  2. 独立：微服务在系统软件生命周期中独立开发、独立测试及独立部署（简单部署）、独立运行（每个服务独立在其独立进程中）。
  3. 技术选型灵活：微服务架构下系统应用的技术选型是去中心化的，每个开发团队可根据自身应用的业务需求发展状况选择合适的体系架构与技术——支持异构（例如每个服务使用不同数据库）。
  4. 容错：由于各个微服务相互独立，故障被隔离在单个服务中，并且系统其他微服务可通过重试、平稳退化等机制实现应用层容错，从而提高系统应用的容错性。
  5. 松耦合、易扩展：微服务架构中每个服务之间都是松耦合的，可根据实际需求独立扩展，体现微服务架构的灵活性。

单体架构与微服务架构对比图如下所示：

微服务

面临的问题与挑战：

  • 分布式环境下的数据一致性【更复杂】
  • 测试的复杂性【服务间依赖测试】
  • 运维的复杂性

7.3.3 微服务架构模式方案

此处介绍以下4种微服务模式方案：

  1. 聚合器微服务：客户端通过API网关访问聚合器，聚合器充当流程指挥者，调用多个微服务实现系统应用程序所需功能。
  2. 链式微服务：客户端通过API网关嵌套递归调用多个微服务，数据沿链条传递，返回经过合并处理的响应。
  3. 数据共享微服务：该模式适用于在单体架构应用到微服务架构的过渡阶段，多个微服务通过读写共享数据库进行数据交互。服务之间允许存在强耦合关系（存在多个微服务共享缓存与数据库存储的现象）。
  4. 异步消息传递微服务：对于一些不必要以同步方式运行的业务逻辑，可以使用消息队列（Kafka、ActiveMQ、RabbitMQ、RocketMQ等）代替REST实现异步通信。以此加快服务调用的响应速度，实现解耦和流量控制。

架构图如下所示：

微服务架构模式方案

8 构建SOA架构时应注意的问题

原有系统架构中的集成需求：应用程序集成的需求、终端用户界面集成的需求、流程集成的需求、已有系统信息集成的需求。

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

  • 服务粒度的控制 ：对于将暴露在整个系统外部的服务推荐使用粗粒度的接口，而相对较细粒度的服务接口通常用于企业系统架构的内部。
  • 无状态服务的设计 ：SOA系统架构中的具体服务应该都是独自的、自包含的请求，在实现这些服务的时候不需要前一个请求的状态，也就是说服务不应依赖于其他服务的上下文和状态，即SOA架构中的服务应是无状态服务。

8 SOA的实施过程

一、选择SOA解决方案：主要从以下3个方面进行——

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

二、业务流程分析：主要关注——

  1. 建立服务模型：自顶向下分解法、业务目标分析法、自底向上分析法。
  2. 建立业务流程：建立业务对象（实体、过程、事件等业务对象）、建立服务接口、建立服务流程。

《系统架构设计理论与实践（5）：面向服务架构》有3条评论

  1. Pingback： 系统架构设计理论与实践（2）：信息系统架构 – Hyperplasma
  2. Pingback： 系统架构核心知识（1）：系统工程与信息系统基础 – Hyperplasma
  3. Pingback： 系统架构设计理论与实践（5）：云原生架构 – Hyperplasma

发表评论