❮
❯
TOC
KINA

KINA-0

Start having fun with KINA right now!
分类 软考高级

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

作者

面向服务架构（SOA）。

1 SOA基本概念

1.1 面向服务的定义

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

SOA

1.2 服务构件

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

服务构件

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

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

1.3 Web Service

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

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

3 SOA的参考架构

IBM的Websphere业务集成参考架构是典型的以服务为中心的企业集成架构，可划分为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）

4 主要协议规范

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

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

REST

REST的5个原则：

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

5 设计标准要求

  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实现的服务都可以由一个WSDM适应（WSDM-companyliant）的管理方案来管理。

6 SOA设计模式

6.1 服务注册表模式

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

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

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

ESB（Enterprise Service Bus，企业服务总线）是由中间件技术实现并支持SOA的一组基础架构，它提供了一种基础设施，其优势在于消除了服务请求者与服务提供者之间的直接链接，即服务请求者与服务提供者之间解耦。ESB可与Web Service技术相容。

ESB

ESB的作用：

  • 提供位置透明性的消息路由和寻址服务
  • 提供服务注册和命名的管理功能
  • 支持多种消息传递范型
  • 支持多种可以广泛使用的传输协议
  • 支持多种数据格式及其相互转换
  • 提供日志和监控功能

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

6.3 微服务

微服务由SOA派生而来，但存在重大区别，故亦经常称微服务不属于SOA。

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

6.3.1 SOA与微服务的区别

微服务与SOA的区别：

  • 比SOA更精细，可以独立进程方式存在。
  • 接口更通用化，如用HTTP RESTful，各种终端均可调用，语言无关，平台无关。
  • 更倾向于分布式部署，互联网场景更适合。

微服务与SOA

6.3.2 微服务的特点

特点：

  • 优点：
    1. 【复杂应用解耦】：
      • 小服务（且专注于做一件事情）
      • 化整为零，易于小团队开发
    2. 【独立】：
      • 独立开发
      • 独立测试及独立部署（简单部署）
      • 独立运行（每个服务独立在其独立进程中）
    3. 【技术选型灵活】：支持异构（如：每个服务使用不同数据库）
    4. 【容错】：故障被隔离在单个服务中，通过重试、平稳退化等机制实现应用层容错
    5. 【松耦合、易扩展】：可根据需求独立扩展
  • 面临的问题与挑战：
    • 分布式环境下的数据一致性【更复杂】
    • 测试的复杂性【服务间依赖测试】
    • 运维的复杂性

微服务

6.3.3 微服务模式方案

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

  1. 聚合器微服务：客户端通过API网关访问聚合器，后者调用多个微服务并提供统一的响应。
  2. 链式微服务：客户端通过API网关依次调用多个微服务，数据沿链条传递。
  3. 数据共享微服务：多个微服务通过读写共享数据库进行数据交互。
  4. 异步消息传递微服务：微服务之间使用消息队列（如Kafka、ActiveMQ、RabbitMQ、RocketMQ）进行异步通信，实现解耦和流量控制。

微服务架构模式方案

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

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

8 SOA实施过程

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

发表评论