soa架构,soa考试

soa架构的优点有哪些？

利用SOA架构开发的优点：

第一、更易维护

业务服务提供者和业务服务使用者的松散耦合关系及对开放标准的采用确保了该特性的实现。建立在以 SOA基础上的信息系统，当需求发生变化的时候，不需要修改提供业务服务的接口，只需要调整业务服务流程或者修改操作即可，整个应用系统也更容易被维护。

第二、更高的可用性

该特点是在于服务提供者和服务使用者的松散耦合关系上得以发挥与体现。使用者无须了解提供者的具休实现细节。

第三、更好的伸缩性

依靠业务服务设计、开发和部署等所采用的架构模型实现伸缩性。使得服务提供者可以互相彼此独立地进行调整，以满足新的服务需求。

微服务架构 vs SOA架构

一、面向服务的架构SOA

面向服务的架构是一种软件体系结构，应用程序的不同组件通过网络上的通信协议向其他组件提供服务。通信可以是简单的数据传递，也可以是两个或多个服务彼此协调连接。这些独特的服务执行一些小功能，例如验证付款、创建用户 帐户 或提供社交登录等。

面向服务的架构不太关于如何对应用程序进行模块化构建，更多的是关于如何通过分布式、单独维护和部署的软件组件的集成来组成应用程序。这些通过技术和标准来实现，通过技术和标准使得组件能够更容易地通过网络（尤其是IP网络）进行通信和协作。

SOA架构中有两个主要角色： 服务提供者（Provider）和服务使用者（Consumer）。 而软件代理则可以 扮演这 两个角色。该Consumer层是用户（人、应用程序或第三方的其它组件）与SOA交互的点，和Provider层则由SOA架构内的所有服务所构成。

SOA首先在90年代中期得名，当时一家名为Gartner Group的公司认识到了这个软件架构的新趋势，并在全球推广。通过这样做，他们设法大大加快了这种架构模式的采用和进一步发展。然而，使用分布式服务作为软件体系结构的最早记录可追溯到二十世纪80年代初。

二、微服务架构

微服务架构在某种程度上是面向服务的架构SOA继续发展的下一步。基本上，这种架构类型是开发软件，网络或移动应用程序作为独立服务套件（又称微服务）的一种特殊方式。这些服务的创建仅限于一个特定的业务功能，如用户管理、用户角色、电子商务车、搜索引擎、社交媒体登录等。此外，它们是完全独立的，也就是说它们可以写入不同的编程语言并使用不同的数据库。集中式服务管理几乎不存在，微服务使用轻量级HTTP、REST或Thrift API进行通信。

这个词本身起源于2011年5月在威尼斯附近举行的软件架构师研讨会。他们第一次使用“微服务”这个术语来描述参与者看到的一个共同的架构风格，其中许多参会者都在 探索 相似的内容。2012年5月，同一个团队决定将“微服务”作为最合适的名称。然而实际上，微软、亚马逊、Netflix和Facebook等主要的 科技 公司已经在微服务架构方面工作了十多年。

乍一看，微服务架构似乎谈论的是与SOA相同的事情。不过，如果引用微软服务领域的先驱Martin Flower的话，他曾经说过，“我们应该把SOA看作微服务的超集”。

那么，差异在哪里呢？可以说，两种架构比起不同的架构有更多的相似之处，然而，它们是两种不同类型的架构。下面会详细分析这一点。

三、SOA vs. MicroServices

下面进一步解释下表所述的不同之处：

开发方面 - 在这两种体系结构中，可以使用不同的编程语言和工具开发服务，从而将技术多样性带入开发团队。开发可以在多个团队中组织，但是在SOA中，每个团队都需要了解常见的通信机制。另一方面，使用微服务，服务可以独立于其他服务运行和部署。因此，频繁部署新版本的微服务或独立扩展服务会更容易。您可以在这里进一步阅读有关微服务的这些好处。

“上下文边界” - SOA鼓励组件的共享，而微服务尝试通过“上下文边界”来最小化共享。上下文边界是指以最小的依赖关系将组件及其数据耦合为单个单元。由于SOA依靠多个服务来完成业务请求，构建在SOA上的系统可能比微服务要慢。

通信 - 在SOA中， ESB可能成为影响整个系统的单一故障点。由于每个服务都通过ESB进行通信，如果其中一个服务变慢，可能会阻塞ESB并请求该服务。另一方面，微服务在容错方面要好得多。例如，如果一个微服务存在内存错误，那么只有该微服务会受到影响。所有其他微服务将继续定期处理请求。

互操作性 - SOA 通过消息中间件组件促进了多种异构协议的使用。微服务试图通过减少集成选择的数量来简化架构模式。 因此，如果您想要在异构环境中使用不同协议来集成多个系统，则需要考虑SOA。如果您的所有服务都可以通过相同的远程访问协议访问，那么微服务对您来说是一个更好的选择。

大小Size - 最后一点但并非最不重要的一点，SOA和微服务的主要区别在于规模和范围。微服务架构中的前缀“微”是指内部组件的粒度，意味着它们必须比SOA架构的服务往往要小得多。微服务中的服务组件通常有一个单一的目的，他们做得很好。另一方面，在SOA服务中通常包含更多的业务功能，并且通常将它们实现为完整的子系统。

四、结论

我们不能简单地说一种架构比另一种架构更好。这主要取决于您正在构建的应用程序的目的。SOA更适合需要与许多其他应用程序集成的大型复杂企业应用程序环境。这就是说，小型应用程序不适合SOA架构，因为它们不需要消息中间件组件。而微服务架构，在另一方面，是更适合于较小和良好的分割，基于Web的系统。另外，如果您正在开发移动或Web应用程序，那么微服务作为开发人员可以为您提供更大的控制权。最后，我们可以得出结论，因为它们服务于不同的目的，微服务和SOA确实是不同类型的体系结构。

什么是SOA架构

面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。

面向服务架构，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。

SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。SOA可以看作是B/S模型、XML（标准通用标记语言的子集）/WebService技术之后的自然延伸。

SOA将能够帮助软件工程师们站在一个新的高度理解企业级架构中的各种组件的开发、部署形式，它将帮助企业系统架构者以更迅速、更可靠、更具重用性架构整个业务系统。较之以往，以SOA架构的系统能够更加从容地面对业务的急剧变化。

SOA 架构

4.2.3.1 SOA 的概念

SOA 是一种架构模型，它将应用程序的不同功能单元(即服务)通过服务之间定义良好的接口和契约联系起来。接口采用中立的方式进行定义，它独立于实现服务的硬件平台、操作系统和编程语言。

不同的厂商和个人对 SOA 有如下不同的定义:

(1)Service-architecture.com 将 SOA 定义为: “本质上是服务的集合。服务间彼此通信，这种通信可能是简单的数据传送，也可能是两个或更多的服务协调进行某些活动。服务间需要某些方法进行连接。所谓服务就是精确定义、封装完善、独立于其他服务所处环境和状态的函数。”

(2)Looselycoupled.com 将 SOA 定义为: “按需连接资源的系统。在 SOA 中，资源被作为可通过标准方式访问的独立服务，提供给网络中的其他成员。与传统的系统结构相比，SOA 规定了资源间更为灵活的松散耦合关系。”

(3)Gartner 则将 SOA 描述为: “客户端/服务器的软件设计方法，一项应用由软件服务和软件服务使用者组成……SOA 与大多数通用的客户端/服务器模型的不同之处，在于它着重强调软件组件的松散耦合，并使用独立的标准接口。”

虽然不同厂商或个人对 SOA 有着不同的理解，但是从以上定义可以看出 SOA 的几个关键特性: 一种粗粒度、松散耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。

SOA 并不是一种现成的技术，而是一种架构和组织 IT 基础结构及业务功能的方法。SOA 是一种在计算环境中设计、开发、部署和管理离散逻辑单元(服务)的模型。SOA要求开发人员将应用设计为服务的集合，以及跳出应用本身进行思考，考虑现有服务的重用，或思索他们的服务如何能够被其他项目重用。“单独的”、“独立的”、“封装完善的”服务所具有的一个关键的好处是，可以采用多种不同方法将它们组合成较大型的服务，由此来实现重用。

4.2.3.2 构成 SOA 的技术

SOA 本身是 “如何将软件组织在一起” 的抽象概念。它依赖于用 XML 和 Web 服务实现并以软件的形式存在的更加具体的观念和技术。此外，它还需要安全性、策略管理、可靠消息传递以及会计系统的支持，从而有效地工作。还可以通过分布式事务处理和分布式软件状态管理来进一步地改善它。

SOA 服务和 Web 服务之间的区别在于设计。SOA 概念并没有确切地定义服务具体如何交互，而仅仅定义了服务如何相互理解以及如何交互。其中的区别也就是定义如何执行流程的战略与如何执行流程的战术之间的区别。而另一方面，Web 服务在需要交互的服务之间如何传递消息有具体的指导原则; 从战术上实现 SOA 模型最常见的方式是通过HTTP 传递的 SOAP 消息。因而，从本质上讲，Web 服务是实现 SOA 的具体方式之一。

虽然 Web 服务是实现 SOA 最好的方式，但是 SOA 并不局限于 Web 服务。其他使用WSDL 直接实现服务接口并且通过 XML 消息进行通信的协议也可以包括在 SOA 之中。例如 CORBA 和 IBM 的 MQ 系统通过使用能够处理 WSDL 的新特征也可以参与到 SOA 中来。如果两个服务需要交换数据，那么它们还会需要使用相同的消息传递协议，但是数据接口允许相同的信息交换。

4.2.3.3 SOA 的基本特征

SOA 是一种粗粒度、松散耦合的软件架构，其服务之间通过简单、精确定义的接口进行通讯，不涉及底层编程接口和通讯模型。这种模型具有下面几个特征( 1.html)［U1］。

(1)松散耦合。服务请求者到服务提供者的绑定与服务之间是松耦合的。松散耦合旨在将服务使用者和服务提供者在服务实现和客户如何使用服务方面隔离开来。服务接口作为与服务实现分离的实体而存在，服务请求者不知道提供者实现的技术细节，比如程序设计语言、部署平台等等。服务请求者往往通过消息调用操作请求消息和响应而不是通过使用文件格式。服务实现的修改完全不会影响到服务的使用者。

(2)粗粒度服务。服务粒度指的是服务所公开功能的范围，一般分为，细粒度和粗粒度。其中，细粒度服务是那些能够提供少量业务流程可用性的服务。粗粒度服务是那些能够提供高层业务逻辑的可用性服务。粗粒度服务可以灵活组合稳定性强、重用性高的细粒度服务，而快速形成新的业务逻辑。虽然细粒度的接口为请求者应用程序提供了更多的灵活性，它同样也意味着交互的模式可能随着不同的服务请求者而不同。这可能使对于服务提供者的支持更加困难。粗粒度接口保证服务请求者将以一致的方式使用服务。面向服务的体系结构不要求使用粗粒度接口，但是推荐使用它们作为外部集成的最佳实践。服务编排可以用来创建运行由细粒度操作组成的业务流程的粗粒度接口。

(3)标准化的接口。服务描述的重点在于与几部分交互所用的操作服务、调用操作的消息、构造这种消息的细节和关于向何处发送用于构造这种消息的处理细节的消息。通过服务接口的标准化描述，从而使得该服务可以提供给在任何异构平台和任何用户接口使用。该接口隐藏了实现服务的细节，允许独立于实现服务基于的硬件或软件平台和编写服务所用的编程语言使用服务。

(4)无状态服务。服务应该是独立的、自包含的请求，在实现时它不需要从一个请求到另一个请求的信息或状态。服务不应该依赖于其他服务的上下文和状态。当需要依赖时，它们最好定义成通用业务流程、函数和数据模型，而不是实现构件比如会话密钥。当然，请求者应用程序需要服务调用之间的持久状态，但是这不应该与服务提供者分开。

什么是SOA架构，SOA和ERP架构是什么关系

ERP与SOA本质上并没有太大的关系。

ERP是应用系统，SOA是一种架构风格，所有系统都可以基于SOA架构风格，也可以不基于。

对于ERP来说，SOA起到的作用就是：ERP各个系统都需要相互交互，且不同企业对同一套ERP的业务要求也各不相同，SOA架构就是扮演一个牵线搭桥的功能。

通过SOA的方式，使得各个本分散的系统集成起来，各种流程更灵活的耦合起来，这样对于变化的需求就有足够的灵活性去满足。