面向服务架构设计

本博客地址:https://security.blog.csdn.net/article/details/136739411

一. 基本概念

1、面向服务的体系结构(SOA)中,服务的概念有了延伸,泛指系统对外提供的功能集。从软件的基本原理定义,可以认为 SOA 是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。

2、业务流程与业务流程执行语言(BPEL)。业务流程是指为了实现某种业务目的行为所进行的流程或一系列动作。使用 BPEL,用户可以通过组合、编排和协调 Web 服务自上而下地实现面向服务的体系结构。

3、SOA 与微服务的区别
● 微服务相比于 SOA 更加精细,微服务更多地以独立的进程的方式存在,互相之间并无影响。
● 微服务提供的接口方式更加通用化,例如 HTTP RESTful 方式,各种终端都可以调用,无关语言、平台限制。
● 微服务更倾向于分布式去中心化的部署方式,在互联网业务场景下更适合。
● 微服务在实现高并发方面是局限的。

二. SOA的参考架构

1、业务逻辑服务。用于实现业务逻辑的服务和执行业务逻辑的能力,其中包括业务应用服务业务伙伴服务应用和信息资产

2、控制服务。包括实现流程信息集成的服务,以及执行这些集成逻辑的能力。

3、连接服务。通过提供企业服务总线,实现分布在各种架构元素中服务间的连接性。

4、业务创新和优化服务。用于监控业务系统运行时服务的业务性能,并通过及时了解到的业务性能和变化,采取措施适应变化的市场。

5、开发服务。贯彻整个软件开发生命周期的开发平台,从需求分析到建模、设计、开发、测试和维护等全面的工具支持。

6、IT 服务管理。支持业务系统运行的各种基础设施管理能力或服务,如安全服务、目录服务、系统管理和资源虚拟化。

三. SOA主要协议和规范

1、Web 服务最基本的协议包括 UDDI、WSDL、SOAP,通过它们可以提供直接而又简单的 Web Service 支持,如图:
在这里插入图片描述

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

3、Web 服务描述语言(WSDL):WSDL 是一个用来描述 Web 服务和说明如何与 Web 服务通信的 XML 语言。描述了 Web 服务的 3 个基本属性:服务做些什么如何访问服务服务位于何处

4、SOAP 协议:SOAP 是在分散或分布式的环境中交换信息的简单的协议,是一个基于 XML 的协议

5、REST 规范:为了让不同的软件或者应用程序在任何网络环境下都可以进行信息的互相传递。微服务对外就是以 REST API 的形式暴露给调用者。RESTful 即 REST 形式的,是对遵循 REST 设计思想同时满足设计约束的一类架构设计或应用程序的统称,这一类都可称为 RESTful,可以理解为资源表述性状态转移。

四. SOA设计的标准要求

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

2、通信协议标准。SOA 服务用消息进行通信,该消息通常使用 XML Schema 来定义(也称作 XSD)。

3、应用程序统一登记与集成。在一个企业内部,SOA 服务通过一个扮演目录列表角色的登记处来进行维护。统一描述定义集成是服务登记的标准。

4、服务质量(QoS)主要包括:可靠性安全性策略通信控制管理

五. SOA 的作用与设计原则

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

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

六. SOA 的设计模式

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

2、企业服务总线模式。其提供一种标准的软件底层架构,各种程序组件能够以服务单元的方式插入到该平台上运行,并且组件之间能够以标准的消息通信方式来进行交互。其核心功能如下:
● 提供位置透明性的消息路由和寻址服务。程序组件之间无须关注对方的路由和寻址。
● 提供服务注册和命名的管理功能。
● 支持多种消息传递范型(如请求/响应、发布/订阅等)。
● 支持多种可以广泛使用的传输协议。
● 支持多种数据格式及其相互转换。
● 提供日志和监控功能。

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

4、微服务模式的特点为:复杂应用解耦、独立开发/测试及部署、技术选型灵活、容错性高、松耦合与易扩展。

5、微服务架构模式方案主要包括:
聚合器微服务:聚合器充当流程指挥者,调用多个微服务实现系统应用程序所需功能。
链式微服务:客户端或服务在收到请求后,会发生多个服务间的嵌套递归调用,返回经过合并处理的响应。
数据共享微服务:该模式适用于在单体架构应用到微服务架构的过渡阶段,服务之间允许存在强耦合关系。
异步消息传递微服务:对于一些不必要以同步方式运行的业务逻辑,可以使用消息队列代替 REST 实现请求、响应,加快服务调用的响应速度。

6、微服务架构面临的问题与挑战
● 服务发现与服务调用链跟踪变得困难。
● 很难实现传统数据库的强一致性,转而追求最终一致性。

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

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

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

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

八. SOA 实施的过程

1、选择 SOA 解决方案主要从以下 3 个方面进行:
● 尽量选择能进行全局规划的方案。
● 选择时充分考虑企业自身的需求。
● 从平台、实施等技术方面进行考察。

2、业务流程分析主要关注:
● 建立服务模型:自顶向下分解法业务目标分析法自底向上分析法
● 建立业务流程:建立业务对象(实体、过程、事件等业务对象)建立服务接口建立服务流程

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

武天旭

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值