soa架构和bs架构的区别 soa架构的缺点

爱你网 2024-05-02 20:50:24

面向服务的体系结构,是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。下面小编给大家介绍一下“soa架构和bs架构的区别 soa架构的缺点”

1.soa架构和bs架构的区别

首先SOA和微服务架构一个层面的东西,而对于ESB和微服务网关是一个层面的东西,一个谈到是架构风格和方法,一个谈的是实现工具或组件。

1、SOA(Service Oriented Architecture)“面向服务的架构”:他是一种设计方法,其中包含多个服务, 服务之间通过相互依赖最终提供一系列的功能。一个服务 通常以独立的形式存在与操作系统进程中。各个服务之间通过网络调用。

2、微服务架构:其实和 SOA 架构类似,微服务是在 SOA 上做的升华,微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”,原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。

微服务架构 = 80%的SOA服务架构思想 + 100%的组件化架构思想 + 80%的领域建模思想

2.soa架构的缺点

1、可靠性(Reliability)

SOA还没有完全为事务的最高可靠性——不可否认性(nonrepudiation)、消息一定会被传送且仅传送一次(once-and-only-once delivery)以及事务撤回(rollback)——做好准备,不过等标准和实施技术成熟到可以满足这一需求的程度并不遥远。

2、安全性(Security)

在过去,访问控制只需要登录和验证;而在SOA环境中,由于一个应用软件的组件很容易去与属于不同域的其他组件进行对话,所以确保迥然不同又相互连接的系统之间的安全性就复杂得多了。

3、编排 (Orchestration)

统一协调分布式软件组件以便构建有意义的业务流程是最复杂的,但它同时也最适合面向服务类型的集成,原因很显然,建立在SOA上面的应用软件被设计成可以按需要拆散、重新组装的服务。作为目前业务流程管理(BPM)解决方案的核心,编排功能使IT管理人员能够通过已经部署的套装或自己开发的应用软件的功能,把新的元应用软件 (meta-application)连接起来。 事实上,最大的难题不是建立模块化的应用软件,而是改变这些系统表示所处理数据的方法。

4、遗留系统处理(Legacy support)

SOA中提供集成遗留系统的适配器, 遗留应用适配器屏蔽了许多专用性API的复杂性和晦涩性。一个设计良好的适配器的作用好比是一个设计良好的SOA服务:它提供了一个抽象层,把应用基础设施的其余部分与各种棘手问题隔离开来。一些厂商就专门把遗留应用软件“语义集成”到基于XML的集成构架中。 但是集成遗留系统的工作始终是一种挑战。

5、语义 Semantics

定义事务和数据的业务含义,一直是IT管理人员面临的最棘手的问题。语义关系是设计良好SOA架构的核心要素。 就目前而言,没有哪一项技术或软件产品能够真正解决语义问题。为针对特定行业和功能的流程定义并实施功能和数据模型是一项繁重的任务,它最终必须由业务和IT管理人员共同承担。不过,预制组件和经过实践证明的咨询技能可以简化许多难题。

采用XML技术也许是一个不错的主意。许多公司越来越认识到制定本行业XML标准的重要性。譬如,会计行业已提议用可扩展业务报告语言(XBRL)来描述及审查总账类型的记录。 重要的是学会如何以服务来表示基本的业务流程。改变开发方式需要文化变迁,相比之下,解决技术难题只是一种智力操练。

6、性能(performance)

批评SOA的人士经常会提到性能是阻碍其采用的一个障碍,但技术的标准化总需要在速度方面有一些牺牲。这种怀疑观点通常针对两个方面:SOA的分布性质和Web服务协议的开销。

相关文章