当前位置: 首页 > news >正文

[系统架构设计师]面向服务架构设计理论与实践(十五)

[系统架构设计师]面向服务架构设计理论与实践(十五)

一.SOA的相关概念

1.定义

组件模型,将应用程序不同功能单元(称为服务)通过这些服务 之间定义良好的接口和契约联系起来

业务流程和业务流程执行语言(BPEL)

二.SOA发展历史

1.发展过程

1.萌芽阶段

2.标准化阶段:简单对象访问协议(SOAP),Web服务描述语言(WSDL),通用服务发现和集成协议(UDDI)

3.成熟应用阶段: SCA,SDO,WS-Policy SCA和SDO构成了SOA编程模型的基础,WS-Policy建立了SOA组件之间安全交互的规范

2.SOA与微服务区别

1.微服务比SOA更加精细,以独立进程方式存在

2.微服务提供接口更加通用化

3.微服务更倾向于分布式去中心化的部署

在这里插入图片描述

3.SOA的参考架构

IBM的Websphere业务集成参考架构是典型的以服务为中心的企业集成架构,可划分为6大类

1.业务逻辑服务:业务应用服务,业务伙伴服务,应用和信息资产

2.控制服务:实现人,流程,信息集成的服务,执行这些集成逻辑的能力

3.连接服务:企业服务总线,实现分布在各架构元素中服务间的连接

4.业务创新和优化服务

5.开发服务:需求分析,建模,开发,测试和维护等全面的工具支持

6.IT服务管理:安全服务,目录服务,系统管理和资源虚拟化

三.SOA主要协议和规范

1.Web服务基本协议:UDDI,WSDL,SOAP

在这里插入图片描述

UDDI协议:统一描述,发现和集成协议

Web服务描述语言(WSDL):如何与Web服务通信的xml语言

​ 基本属性:1.服务做些什么,服务所提供的操作(方法)2.如何访问服务,和服务交互的数据格式以及必要协议3.服务位于何处,协议相关的地址,如URL

SOAP协议:分布式的环境中交换信息的简单的协议,基于XML的协议i

REST规范:RESTful 资源表述性状态转移

1.资源:将互联网中的一切暴露给客户端的事物都可以看作是一种资源

2.表述:REST中用表述描述资源在Web中某一时间的状态

3.状态转移:应用状态-对某个时间内用户请求会话相关信息的快照,保存在客户端。资源状态-在服务端保存,是对某个时间资源请求表述的快照

4.超链接:通过在页面嵌入链接和其他资源建立联系

四.SOA设计的标准要求

1.文档标准化

2.通信协议标准

3.应用程序统一登记与集成:统一描述,定义和集成是服务登记的标准

4.服务质量(QoS):可靠性,安全性,策略从,控制,管理

五.SOA的作用与设计原则

1.作用:打破信息孤岛,把应用和资源转换为服务。以及把这些服务变成标准的服务,形成资源的共享

2.SOA的设计原则:

无状态:避免请求者依赖于服务提供者的状态

单一实例:以高内聚的实现方法,避免功能冗余

明确定义的接口:服务的接口由WSDL定义,用于指明服务的公共接口与其内部专用你实现之间的界线

自包含和模块化:服务封装了那些在业务上稳定,重复出现的活动和组件,实现服务的功能实体是完全独立自主的,独立进行部署,版本控制,自我管理和恢复

粗粒度:服务数量不应该太大,依靠消息交互而不是远程过程调用(RPC),通常消息量较大,但是服务之间的交互频度较低

服务之间的松耦合性:

重用能力:

互操作性,兼容和策略声明:

六.SOA的设计模式

1.服务注册表模式

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

服务注册:应用开发者(服务提供者),向注册表公布功能

服务位置: 服务应用开发者,查询注册服务,寻找符合要求服务

服务绑定:服务消费者利用检索到的服务合同来开发代码,开发代码将于注册的服务绑定,调用注册的服务以及与它们实现互动

2.企业服务总线模式

提供一种标准的软件底层架构,各种程序组件能够以服务单元的方式"插入"到该平台上运行,并且组件之间能够以标准的消息通信方式来进行交互。核心功能如下:

1.提供位置透明性的消息路由和寻址服务。程序组件之间无须关注对方的路由和寻址

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

3.支持多种消息传递范型(如请求/响应,发布/订阅等)

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

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

6.提供日志和监控功能

3.微服务模式

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

微服务模式的特点如下:

1.复杂应用解耦: 微服务架构将单一模块应用分解为多个微服务,同时保持总体功能不表

2.独立:微服务在软件生命周期中是独立开发,测试及部署的

3.技术选型灵活:微服务架构下系统应用的技术选型时去中心化的,每个开发团队可根据自身应用的业务需求发展状况选择合适的体系架构与技术

4.容错:由于各个微服务相互独立,故障会被隔离在单个服务中,并且系统其他微服务可通过重试,平稳退化等机制实现应用层的容错,从而提高系统应用的容错性

5.松耦合,易扩展:每个服务之间都是松耦合的

在这里插入图片描述

4.微服务架构模式方案

聚合器微服务:聚合器充当流程指挥者,调用多个微服务实现系统应用程序所需功能

链式微服务:客户端或服务在收到请求后,会发生多个服务间的嵌套递归调用,返回经过合并处理的响应

数据共享微服务:该模式适用于单体架构应用到微服务架构的过渡阶段,服务之间允许存在强耦合关系,例如存在多个微服务共享缓存与数据库存储的现象

异步消息传递微服务:对于一些不必要以同步方式运行的业务逻辑,可以使用消息队列代替REST实现请求,响应,加快服务调用的响应速度

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

服务发现与服务调用链跟踪变得困难

很难实现传统数据库的强一致性,转而追求最终一致性

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

1.原有架构中的集成需求包括:应用程序集成的需求,终端用户界面集成的需求,流程集成的需求以及已有系统信息集成的需求

2.服务粒度的控制及无状态服务的设计表述如下

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

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

八.SOA实施的过程

1.方案选择

尽量选择能进行全局规划的方案

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

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

2.业务流程分析主要关注

建立服务模型:自顶向下分解法,业务目标分析法,自底向上分析法

建立业务流程:建立业务对象(实体,过程,事件等业务对象),建立服务接口,建立服务流程

SOA实施的过程

1.方案选择

尽量选择能进行全局规划的方案

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

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

2.业务流程分析主要关注

建立服务模型:自顶向下分解法,业务目标分析法,自底向上分析法

建立业务流程:建立业务对象(实体,过程,事件等业务对象),建立服务接口,建立服务流程

http://www.dtcms.com/a/340173.html

相关文章:

  • Shader学习路线
  • C++ MFC/BCG编程:文件对话框(CFileDialog、CFolderPickerDialog)
  • 【免费AI文档助手开发实战系列】基于正则表达式的PDF脱敏python服务构建(一)
  • 国产化PDF处理控件Spire.PDF教程:如何使用 Python 添加水印到 PDF
  • 太阳光模拟器在无人机老化测试中的应用
  • JVM参数优化
  • Nacos-8--分析一下nacos中的AP和CP模式
  • InfoNES模拟器HarmonyOS移植指南
  • SpringAI接入openAI配置出现的问题全解析
  • hadoop技术栈(九)Hbase替代方案
  • 深入理解计算机系统
  • 9-302 家里网能搜出两个ip, 无法联大堂监控室
  • LangChain —多模态 / 多源上下文管理
  • 银河麒麟V10一键安装Oracle 11g脚本分享
  • 【运维进阶】管理大项目
  • Linux数据库:【索引】
  • 如何成功初始化一个模块
  • 第4章 React状态管理基础
  • TDengine IDMP 运维指南(4. 使用 Docker 部署)
  • LWIP的IP 协议栈
  • C#传参调用外部exe
  • FACE 与 AUTOSAR 架构比较研究:本质异同分析
  • Huggingface-Qwen2-blog学习
  • Ubuntu 下面安装搜狗输入法debug记录
  • git 常用操作
  • 可靠性测试:软件稳定性的守护者
  • Linux网络服务(二)——交换机、网络层与传输层原理详解
  • L2TP虚拟局域网
  • Qt 插件开发全解析:从接口定义,插件封装,插件调用到插件间的通信
  • 从0到1掌握 Spring Security(第四篇):密码加密原理、默认行为与配置选型