代码人生

面向服务的体系结构-简单介绍

代码人生 http://www.she9.com 2019-01-11 14:46 出处:网络 编辑:@技术狂热粉
面向服务的体系结构(SOA)已经存在很长时间了。这个词第一次出现是在1998年,自那以后越来越流行。它还分为几个变体,包括微服务体系结构。尽管微服务占主导地位,但SOA死亡的报道被大大夸大了。那么,让我们来回顾一

面向服务的体系结构(SOA)已经存在很长时间了。这个词第一次出现是在1998年,自那以后越来越流行。它还分为几个变体,包括微服务体系结构。尽管微服务占主导地位,但SOA死亡的报道被大大夸大了。那么,让我们来回顾一下什么是SOA。然后我们将了解如何将其设计概念应用到您的工作中。

什么是面向服务的体系结构?

面向服务的体系结构的定义一直都没有个明确的说法。在Open Group于2007年发布白皮书之前,它已经发展了好几年。后来,该文章又进入了《SOA源代码》这本书。由于SOA过去的碎片化,它有多个定义。

按照Hoyle的说法是SOA

开放团队对SOA的定义几乎是一种重复。其中一个原因是面向服务的体系结构的恰当名称。另一个原因可能是Open Group总部缺少同义词典。

面向服务的体系结构(SOA)是一种支持面向服务的体系结构样式。

面向服务是根据服务和基于服务的开发以及服务的结果进行思考的一种方式。

Open Group说,一个服务:


1、是具有指定结果的可重复业务活动的逻辑表示(例如,检查客户信用、提供天气数据、合并钻井报告)。


2、是独立的。


3、可能由其他服务组成(重点是它们的)。


4、是服务使用者的“黑箱”。


因此,SOA将业务流程分离为离散的操作。然后,它创建执行这些操作的服务。


服务执行业务任务。它们是自包含的,但是您可以将服务组合成更大的服务。消费者不应该需要知道关于服务的任何事情。


开放组在定义上更进一步。设计应该“反映真实的商业活动”。“你在它所取代的业务流程之后设计它的操作。服务名称应该是业务流程、规则或策略。


在SOA中,服务彼此通信。它们通过企业服务总线(ESB)进行此操作。SOA使用一种称为无边界信息流的东西。业务消息在总线上流动,因此服务可以通信和协作。这需要大量的协调,根据开放小组的说法,还需要治理。


SOA是一种适用于大型企业的体系结构。It在业务流程之后为应用程序建模。然后,它将它们连接到一个消息交换系统,在那里它们可以协作。它是一个让许多开发团队一起工作的模型。

其他认为的SOA

这就是最接近SOA标准的东西。那么,其它的观点怎么看呢?


这得视情况而定。


2005年,在Open Group发布其源代码之前,Martin Fowler将SOA称为“ServiceOrientedAmbiguity”。

我听人们说SOA的好处是它把数据从流程中分离出来,它把数据和流程结合起来,它使用web标准,它独立于web标准,它是异步的,它是同步的,它的同步性不重要……

面向服务的体系结构对于不同的人来说是不同的。在早期,它的一个决定性特征是它不是什么。SOA是20世纪90年代占主导地位的应用服务器模式的替代方案。除此之外,正如Fowler所暗示的,SOA在旁观者的眼中。

那么微服务架构呢?


那么,微服务呢?微服务体系结构是SOA的一种类型吗?或者是完全不同的东西?答案取决于你问谁。


这两个体系结构都围绕着将业务问题分解为服务的概念。这使得这两种风格看起来很相似,但是如果你再深入一点,就会发现它们之间有很大的区别。


SOA的无边界信息流概念鼓励服务之间的共享。服务共享尽可能多的信息。它们共享软件组件以保持一致性并减少开发工作。这就是开放团队的强大集中治理思想的来源。


有界与无界数据流

基于微服务的系统(希望如此)是用有限上下文的概念构建的。我们之前在一篇关于域驱动设计的文章中讨论了有界上下文。


让我们来看看我们是如何定义它的:

首先,有界上下文意味着包含复杂性。换句话说,我们可以为某些特定的复杂业务逻辑创建一个有边界的上下文。有界上下文通过适配器连接到其他上下文。而且,这些适配器可以防止更改。当上下文中包含的这些复杂性发生变化时,系统的其他部分也不必发生变化。(重点)

有界上下文的存在是为了包含复杂性。它们保护上下文之外的服务不受更改的影响。它是无边界信息流的对立面。


服务和客户机之间的关系是显式定义的。同时,服务之间的通信尽可能少。服务很少(如果有的话)在微服务体系结构中共享组件。


这种差异超越了设计。微服务通过隔离关注点来管理开发团队之间的协作。SOA通过公开它们来实现。开放组需要对SOA系统进行强有力的治理。如果您设计一个在部门之间共享数据的企业系统,那么您就需要它。微服务在有限的上下文中避免了这种情况。开发团队可以在他们定义的接口中工作,而不需要集中控制。

SOA体系结构的关键特征

服务组合


面向服务的体系结构是关于用服务解决业务问题的。想象一下一个巨大的电子商务商店。它销售多条产品线,每条产品线包含数千种产品。


20年前,您可以将其构建为单个应用服务器。应用服务器将连接到关系数据库。然后,将大部分业务逻辑放在数据库中的存储过程中。为了可靠性,可以将其部署到集群上。对系统的任何更改都将意味着更新服务器、数据库,或者同时更新服务器和数据库。应用服务器是刚性的,需要大量硬件。


使用SOA,您可以将系统分解为服务。例如:


销售点(POS)。


付款处理。


库存。


订单执行。


航运。

每个产品线可能有不同的库存服务。但是,代码重用的机会很大。销售点服务可能是一个复合服务。它可能有一个用于与客户机通信的web服务器。它还可以有一个专门的接口来接电话订单。运输服务可能由UPS、USPS、FedEx和专用产品的私人托运人的服务组成。


不使用昂贵的集群,而是运行每个服务的多个实例。下面我们将讨论ESB如何实现这一点。


到目前为止,这听起来很像使用微服务解决这个问题的方法。但是,有一个很大的区别。

企业总线


服务通过企业服务总线(ESB)彼此通信。ESB通常是消息传递系统,如JMS、RabbitMQ或Kafka。总线实现无边界信息流。这是SOA和微服务分道扬镳的地方。


因此,在我们的示例中,POS服务在销售期间与实现和支付处理系统进行对话。履行系统与库存和运输服务等进行通信。这需要协调。服务必须就如何代表产品、销售和客户达成一致。这就是强有力的治理发挥作用的地方。还是它?


消息总线是一种有效的解耦机制。在服务之间协调消息仍然比紧密耦合或单一服务要好。服务开发人员按照约定的消息格式进行编写。这需要强有力的治理吗?为什么消息不能像微服务中使用的RESTful api那样工作呢?


如上所述,消息总线支持容错。您可以运行每个服务的多个实例,并使用编排来共享负载。或者,如果它更适合您的应用程序模型,您可以在热备用模式下运行服务。

企业架构


面向服务的体系结构存在了很长时间,这是有原因的。将流程分解为服务的模型是可靠的,并导致了微服务。对于需要在部门之间共享数据的企业来说,消息总线的概念很好。


对一些人来说,要求强有力的治理可能令人反感,但你并不需要。与其将企业总线用作耦合机制,不如将其用作一个分界点。对于需要在服务之间交换数据的系统来说,SOA的消息总线是一个有价值的补充。


请关注公众号:程序你好
0

精彩评论

暂无评论...
验证码 换一张
取 消