【系统架构设计师】二十一、面向服务架构设计理论与实践②

帅次

于 2024-07-30 08:30:00 发布

阅读量553

点赞数 12

分类专栏：【软考高级】系统架构设计师文章标签：系统架构系统架构设计师架构分布式中间件微服务

本文链接：https://blog.csdn.net/g984160547/article/details/140767558

版权

【软考高级】系统架构设计师专栏收录该内容

47 篇文章 5 订阅

订阅专栏

四、SOA 主要协议和规范

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

功能	协议
发现服务	UDDI、 DISCO
描述服务	WSDL、XML Schema
消息格式层	SOAP、REST
编码格式层	XML( DOM,SAX )
传输协议层	HTTP、TCP/IP、SMTP等

（1）UDDI 协议：统一描述、发现和集成协议。包含了服务描述与发现的标准规范，它使得商业实体能够彼此发现；定义它们怎样在 Internet 上互相作用，并在一个全球的注册体系架构中共享信息。

（2）Web 服务描述语言（Web Services Description Language，WSDL）：WSDL 是一个用来描述 Web 服务和说明如何与 Web 服务通信的 XML 语言。描述了 Web 服务的 3 个基本属性：
①服务做些什么—服务所提供的操作（方法）。
②如何访问服务—和服务交互的数据格式以及必要协议。
③服务位于何处—协议相关的地址，如 URL。

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

（4）REST 规范：RESTful 即 REST 形式的，是对遵循REST 设计思想同时满足设计约束的一类架构设计或应用程序的统称，这一类都可称为 RESTful，可以理解为资源表述性状态转移：
①资源：将互联网中一切暴露给客户端的事物都可以看作是一种资源。
②表述：REST 中用表述描述资源在 Web 中某一个时间的状态。
③状态转移：分为两种，应用状态—对某个时间内用户请求会话相关信息的快照，保存在客户端。资源状态—在服务端保存，是对某个时间资源请求表述的快照。
④超链接：通过在页面中嵌入链接和其他资源建立联系。

五、SOA 设计的标准要求

5.1 SOA设计标准

        （1）文档标准化。SOA 服务具有平台独立的自我描述 XML 文档。Web 服务描述语言是用于
描述服务的标准语言。
        （2）通信协议标准。SOA 服务用消息进行通信，该消息通常使用 XML Schema 来定义（也称作 XML Schema Definition，XSD）。
        （3）应用程序统一登记与集成。在一个企业内部，SOA 服务通过一个扮演目录列表（Directory Listing）角色的登记处（Registry）来进行维护。应用程序在登记处（Registry）寻找并调用某项服务。UDDI是标准。

5.2 服务质量

每项 SOA 服务都有一个与之相关的服务质量 (Quality of Service,QoS)。QoS的一些关键元素有安全需求(例如认证和授权)、可靠通信以及谁能调用服务的策略。服务质量（QoS）主要包括：
（1）可靠性：服务消费者和服务提供者之间传输文档时的传输特性（且仅仅传送一次、最多传送一次、重复消息过滤、保证消息传送）。
（2）安全性：Web 服务安全规范用来保证消息的安全性。
（3）策略：服务提供者有时候会要求服务消费者与某种策略通信。
（4）控制：在 SOA 中，进程是使用一组离散的服务创建的。BPEL4WS 或者 WSBPEL（Web Service Business Process Execution Language）是用来控制这些服务的语言。
（5）管理：针对运行在多种环境下的所有服务，必须有一个统一管理系统，以便系统管理员能够有效管理。

六、 SOA 的作用与设计原则

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

SOA 的设计原则主要有：

        （1）无状态。以避免服务请求者依赖于服务提供者的状态。
        （2）单一实例。以高内聚的实现方法，来避免功能冗余。
        （3）明确定义的接口。服务的接口由 WSDL 定义，用于指明服务的公共接口与其内部专用实现之间的界线。
        （4）自包含和模块化。服务封装了那些在业务上稳定、重复出现的活动和组件，实现服务的功能实体是完全独立自主的，独立进行部署、版本控制、自我管理和恢复。
        （5）粗粒度。服务数量不应该太大，依靠消息交互而不是远程过程调用（Remote Procedure Call，RPC），通常消息量较大，但是服务之间的交互频度较低。

        （6）服务之间的松耦合性。服务使用者看到的是服务的接口，其位置、实现技术和当前状态等对使用者是不可见的，服务私有数据对服务使用者是不可见的。
        （7）重用能力。服务应该是可以复用的。
        （8）互操作性、兼容和策略声明。为了确保服务规约的全面和明确，利用策略来定义可配置的互操作语义，来描述特定服务的期望、控制其行为。利用策略声明确保服务期望和语义兼容性方面的完整和明确。

七、SOA 的设计模式

7.1 服务注册表模式

        服务注册表支持驱动 SOA 治理的服务合同、策略和元数据的开发、发布和管理。
        （1）服务注册：应用开发者，也叫服务提供者，向注册表公布它们的功能。
        （2）服务位置：也就是服务应用开发者，帮助它们查询注册服务，寻找符合自身要求的服务。
        （3）服务绑定：服务的消费者利用检索到的服务合同来开发代码，开发的代码将与注册的服务绑定、调用注册的服务以及与它们实现互动。

7.2 企业服务总线模式

企业服务总线是由中间件技术实现的支持面向服务架构的基础软件平台，支持异构环境中的服务以基于消息和事件驱动模式的交互，并且具有适当的服务质量和可管理性。

一个典型的在 ESB 环境中组件之间的交互过程是：首先由服务请求者触发一次交互过程，产生一个服务请求消息，并将该消息按照ESB 的要求标准化，然后标准化的消息被发送给服务总线。 ESB 根据请求消息中的服务名或者接口名进行目的组件查找，将消息转发至目的组件，并最终将处理结果逆向返回给服务请求者。这种交互过程不再是点对点的直接交互模式，而是由事件驱动的消息交互模式。

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

7.3 微服务模式

微服务不再强调传统 SOA 架构里面比较重的 ESB 企业服务总线，同时SOA 的思想进入到单个业务系统内部实现真正的组件化。

微服务架构将一个大型的单个应用或服务拆分成多个微服务，可扩展单个组件而不是整个应用程序堆栈，从而满足服务等级协议。

微服务模式特点：复杂应用解耦、独立、技术选型灵活、容错、松耦合易扩展。

常见的微服务设计模式：

（1）聚合器微服务：聚合器调用多个微服务实现系统应用程序所需功能，具体有两种形式：

①是将检索到的数据信息进行处理并直接展示;
②是对获取到的数据信息增加业务逻辑处理后，再进一步发布成一个新的微服务作为一个更高层次的组合微服务，相当于从服务消费者转换成服务提供者。

（2）链式微服务：客户端或服务在收到请求后，会返回一个经过合并处理的响应，服务之间形成一条调用链。

（3）数据共享微服务：当服务之间存在强耦合关系时，可能存在多个微服务共享缓存与数据库存储的现象。

（4）异步消息传递微服务：消息队列将消息写入一个消息队列中，实现业务逻辑以异步方式运行，从而加快系统响应速度。

微服务架构的问题与挑战：

（1）微服务架构分布式特点带来的复杂性；
（2）微服务架构的分区数据库体系不同服务拥有不同数据库；
（3）增加了测试的复杂性；
（4）在大规模应用部署中，在监控、管理、分发及扩容等方面，微服务也存在着巨大挑战。

八、SOA的构建与实施

8.1 构建SOA时应该注意的问题

（1）原有系统架构中的集成需求：当架构师基于 SOA 来构建一个企业级的系统架构时，一定要注意对原有系统架构中的集成需求进行细致的分析和整理。集成需求包括：应用程序集成的需求、终端用户界面集成的需求、流程集成的需求以及已有系统信息集成的需求。
（2）服务粒度的控制以及无状态服务的设计：SOA 系统中服务的构建有两点需要特别注意的地方：①是对于服务粒度的控制，②是对于无状态服务的设计。