面向服务的体系结构

在软件工程中，以服务为导向的体系结构（ SOA ）是一种建筑风格，专注于离散服务而不是单片设计。因此，它也应用于软件设计领域，其中通过网络上的通信协议通过应用程序组件向其他组件提供服务。服务是一个离散的功能单元，可以远程访问并独立采取行动和更新，例如在线检索信用卡声明。 SOA还旨在独立于供应商，产品和技术。

服务取向是一种基于服务和基于服务的开发以及服务结果的思考方式。

根据SOA的众多定义之一，服务具有四个属性：

从逻辑上讲，它代表具有指定结果的可重复的业务活动。
它是独立的。
它是对消费者的黑匣子，这意味着消费者不必意识到该服务的内部运作。
它可能由其他服务组成。

可以将不同的服务共同用作服务网格，以提供大型软件应用程序的功能，SOA原理与模块化编程共享。面向服务的体系结构集成了分布式，分别维护和部署的软件组件。它是通过网络（尤其是在IP网络上的网络）上有助于组件的通信与合作的技术和标准来启用的。

SOA与API（应用程序编程界面）的想法，计算机程序的不同部分之间的接口或通信协议有关，旨在简化软件的实现和维护。可以将API视为服务，而SOA可以将服务允许服务运行。

概述

在SOA中，服务使用协议来描述其如何通过描述元数据传递和解析消息。该元数据描述了服务的功能特征和服务质量特征。面向服务的体系结构旨在允许用户组合大量功能，以形成纯粹由现有服务构建并以临时方式组合的应用程序。服务向请求者提供了一个简单的接口，该界面将起作用的基本复杂性抽像出来。进一步的用户也可以访问这些独立服务，而无需任何内部实施。

定义概念

相关的流行语服务导向促进了服务之间的松散耦合。 SOA将功能分为不同的单位或服务，开发人员可以通过网络访问，以允许用户将它们合并并重用应用程序的生产。这些服务及其相应的消费者通过以明确的，共享的格式或通过两个或多个服务之间的活动进行协调来通过数据来互相交流。

2009年10月，为以服务为导向的体系结构发布了一份宣言。这提出了六个核心价值观，如下所示：

与技术策略相比，业务价值更重要。
战略目标比特定于项目的收益更重要。
固有的互操作性比自定义集成更为重要。
共享服务比特定用途实现更重要。
灵活性比优化更重要。
进化的改进比追求最初的完美更为重要。

SOA可以看作是连续体的一部分，范围从分布式计算和模块化编程，SOA到Mashups ， SaaS和Cloud Computing的实践（有些人将其视为SOA的后代）。

原则

尽管许多行业消息来源都发表了自己的原则，但没有与以服务为导向的建筑的确切组成有关的行业标准。其中一些包括以下内容：

标准化服务合同: 服务遵守标准通信协议，如给定的一组服务中的一个或多个服务说明文档所定义。
服务参考自主权（松散耦合的一个方面）: 服务之间的关系最小化至他们只知道自己的存在的水平。
服务位置透明度（松散耦合的一个方面）: 无论存在何处，都可以从网络中的任何地方调用服务。
服务寿命: 服务的设计应长期存在。在可能的情况下，如果服务不需要新功能，应避免强迫消费者更改，如果您今天致电服务，您明天应该可以致电同一服务。
服务抽象: 该服务充当黑匣子，这就是他们的内在逻辑对消费者隐藏。
服务自治: 服务是独立的，并从设计时间和运行时的角度控制它们封装的功能。
服务无状态: 服务是无状态的，即返回请求的值或给出异常，因此最大程度地减少了资源使用。
服务粒度: 确保服务规模和范围的原则。服务为用户提供的功能必须相关。
服务归一化: 服务分解或合并（归一化）以最大程度地减少冗余。在某些情况下，这可能不做。在这些情况下，需要优化性能，访问和聚合。
服务合成性: 服务可用于撰写其他服务。
服务发现: 服务补充了交流元数据，可以通过这些数据有效地发现和解释。
服务可重复使用: 逻辑分为各种服务，以促进代码的重复使用。
服务封装: 最初未根据SOA计划的许多服务可能被封装或成为SOA的一部分。

模式

每个SOA构建块都可以扮演三个角色中的任何一个：

服务提供者: 它创建Web服务并将其信息提供给服务注册表。每个提供商都会辩论许多如何公开服务的方式，这更重要的是：安全性或轻松可用性，为服务提供的价格以及更多的价格。提供商还必须确定为给定的经纪服务列出该服务的类别，以及使用该服务需要哪种交易合作伙伴协议。
服务经纪，服务注册表或服务存储库: 它的主要功能是向任何潜在请求者提供有关Web服务的信息。实施经纪人的人决定经纪人的范围。公共经纪人在任何地方和任何地方都可以使用，但是私人经纪人仅适用于有限的公众。 UDDI是早期，不再积极支持提供Web服务发现的尝试。
服务请求者/消费者: 它使用各种查找操作在经纪人注册表中找到条目，然后绑定到服务提供商以调用其Web服务之一。无论服务 - 消费者需要哪种服务，他们都必须将其带入经纪人，将其绑定到相应的服务中，然后使用它。如果服务提供多个服务，他们可以访问多个服务。

服务消费者 - 管理的关系受标准化服务合同的约束，该合同具有业务部分，功能部分和技术零件。

服务组成模式具有两种广泛的高级建筑风格：编舞和编排。与特定建筑风格无束缚的较低企业集成模式在SOA设计中仍然具有相关性和符合条件。

实施方法

可以使用Web服务或微服务实现面向服务的体系结构。这样做是为了使功能性建筑块可通过独立于平台和编程语言的标准Internet协议访问。这些服务可以代表新的应用程序，也可以代表现有旧系统的包装器，以使其启用网络。

实施者通常使用Web服务标准构建SOA。一个例子是肥皂，在2003年W3C（万维网联盟）的1.2版推荐后，肥皂已经获得了广泛的行业认可。这些标准（也称为Web服务规格）也提供了更大的互操作性，并提供了一些保护性，并免受锁定的保护。在专有供应商软件中。但是，也可以使用任何其他基于服务的技术，例如Jini ， Corba ， Internet通信引擎， REST或GRPC实施SOA。

体系结构可以独立于特定的技术运行，因此可以使用广泛的技术来实施，包括：

基于WSDL和SOAP的Web服务
消息传递，例如ActiveMQ，JMS，RabbitMQ
宁静的HTTP，具有代表性状态转移（REST），构成其自身约束的建筑风格
OPC-UA
互联网通信引擎
WCF （Microsoft实施Web服务，形成WCF的一部分）
apache节俭
grpc
巫师

实现可以使用其中一个或多个协议，例如，可以使用文件系统机制在符合SOA概念的过程之间定义的接口规范之后传达数据。关键是具有定义接口的独立服务，可以打电话给标准方式执行其任务，而无需提供通话应用程序的服务，并且没有应用程序具有或不需要了解该服务实际执行其任务的知识。 SOA可以通过将松散耦合和可互操作的服务结合使用来开发应用程序。

这些服务基于与基础平台和编程语言无关的正式定义（或合同，例如WSDL）进行互操作。接口定义隐藏了特定语言服务的实现。因此，基于SOA的系统可以独立于开发技术和平台（例如Java，.Net等）发挥作用。例如，在Java EE平台上运行的Java编写的.NET平台和服务中编写的服务都可以由常见的复合应用程序（或客户端）消费。在任一平台上运行的应用程序还可以消费在另一个平台上运行的服务，作为促进重复使用的Web服务。托管环境还可以包装COBOL遗产系统并将其作为软件服务呈现。 ^。

高级编程语言，例如BPEL以及WS-CDL和WS-COORTINATION等规格，通过提供一种定义和支持精细元素服务的精美服务的方法来扩展服务概念，以又可以依次将其提供给更粗糙的商业服务，而建筑师又可以这样做纳入复合应用程序或门户中实施的工作流程和业务流程。

面向服务的建模是一个SOA框架，它标识了指导SOA从业者概念化，分析，设计和架构其面向服务的资产的各种学科。面向服务的建模框架（SOMF）提供了一种建模语言和工作结构或“地图”，描绘了有助于成功的以服务为导向的建模方法的各种组件。它说明了确定服务开发计划的“做什么”方面的主要要素。该模型使从业人员能够制定项目计划并确定面向服务的计划的里程碑。 SOMF还提供了一个通用的建模符号，以解决业务与IT组织之间的一致性。

组织福利

一些企业建筑师认为，SOA可以帮助企业对不断变化的市场状况更快，更具成本效益的反应。这种架构风格在宏（服务）级别而不是微（类）级别上促进了重复使用。它还可以简化与存在（遗产）资产的互连和使用。

有了SOA，想法是组织可以从整体上研究一个问题。企业具有更多的整体控制。从理论上讲，不会使用任何工具集可能取悦它们的开发人员。但是，他们将编码为业务内设定的标准。他们还可以开发整个企业的SOA，以封装面向业务的基础架构。 SOA也被说明为高速公路系统，可为汽车驾驶员提供效率。关键是，如果每个人都有汽车，但是任何地方都没有高速公路，那么任何试图快速或有效地到达任何地方的事情都会有限和混乱。 IBM Web Services副总裁Michael Liebow说，SOA“建造高速公路”。

在某些方面，SOA可以被视为建筑进化，而不是革命。它捕获了以前软件体系结构的许多最佳实践。例如，在通信系统中，很少开发使用真正静态绑定来与网络中其他设备交谈的解决方案。通过采用SOA方法，这样的系统可以定位自己，以强调定义明确，高度可互操作的接口的重要性。 SOA的其他前身包括基于组件的软件工程以及远程对象的面向对象的分析和设计（OOAD），例如在Corba中。

服务包括仅通过正式定义的接口可用的独立功能单元。服务可能是易于生产和改进的某种“纳米企业”。另外，服务也可以是构建的“大型公司”，作为下属服务的协调工作。

将服务的实施视为与较大项目的单独项目的原因包括：

分离将这一概念推广到业务，即服务可以与组织中常见的更大且较慢的项目一起迅速而独立地交付。企业开始了解系统和简化服务的用户界面。这倡导敏捷性。也就是说，它促进了业务创新，并加快了上市时间的速度。
分离可以促进服务与消费项目的分离。这在服务的设计不知道其消费者是谁的情况下鼓励了良好的设计。
该服务的文档和测试工件并未嵌入较大项目的细节中。当需要以后重复使用服务时，这一点很重要。

SOA有望间接简化测试。服务是自主的，无状态的，具有充分记录的接口，并且与实施的横切关注点分开。如果组织具有适当定义的测试数据，则建立一个相应的存根，该存根对构建服务时会对测试数据做出反应。该服务还捕获了完整的回归测试，脚本，数据和响应。可以使用与其调用服务相对应的现有存根来测试该服务作为“黑匣子”。可以在原始和范围内服务为存根的情况下构建测试环境，而其余的网格为完整服务的测试部署。由于每个接口都使用其自己的完整回归测试文档进行了完整记录，因此识别测试服务中的问题变得很容易。测试的发展是为了仅验证测试服务根据其文档运行，并在环境中所有服务的文档和测试案例中找到差距。管理IDEMTOTENT服务的数据状态是唯一的复杂性。

示例可能被证明有助于记录其有用的水平的服务。 Java社区过程中某些API的文档提供了很好的例子。由于这些都是详尽的，因此员工通常只使用重要的子集。 JSR-89中的“ ossjsa.pdf”文件例证了此类文件。

批评

SOA已与Web服务混为一谈；但是，Web服务只是实现构成SOA样式的模式的一个选项。在没有远程程序调用（RPC）的本地或二进制形式的情况下，应用程序可能会更慢，需要更多的处理能力，增加成本。大多数实现确实会产生这些间接费用，但是可以使用技术（例如Java Business Integration （JBI）， Windows Communication Foundation （WCF）（WCF）和数据分发服务（DDS））实施SOA，而不依赖于远程过程或翻译。 XML或JSON。同时，新兴的开源XML解析技术（例如VTD-XML ）和各种与XML兼容的二元格式有望显著提高SOA性能。

国家服务要求消费者和提供商共享相同的特定于消费者的上下文，这要幺包含在提供商和消费者之间的消息中或引用。该约束的缺点是，如果服务提供商需要保留每个消费者的共享上下文，则可以降低服务提供商的总体可扩展性。它还增加了服务提供商和消费者之间的耦合，并使切换服务提供商更加困难。最终，一些批评家认为SOA服务仍然受其代表的应用程序的限制。

面向服务的建筑面临的主要挑战是元数据管理。基于SOA的环境包括许多服务，这些服务相互交流以执行任务。由于该设计可能涉及多种服务，因此应用程序可能会产生数百万个消息。进一步的服务可能属于不同的组织，甚至涉及竞争的公司创造一个巨大的信任问题。因此，SOA治理进入了事物的计划。

SOA面临的另一个主要问题是缺乏统一的测试框架。没有工具可以在以服务为导向的体系结构中测试这些服务所需的功能。困难的主要原因是：

溶液的异质性和复杂性。
由于自治服务的整合而导致的一系列测试组合。
包括来自不同和竞争供应商的服务。
由于新功能和服务的可用性，平台正在不断变化。

扩展和变体

事件驱动的架构

应用程序编程接口

应用程序编程接口（API）是开发人员可以与Web应用程序进行交互的框架。

Web 2.0

Tim O'Reilly创造了“ Web 2.0 ”一词，以描述一套感知的，快速增长的基于Web的应用程序。经历了广泛覆盖范围的主题涉及Web 2.0和面向服务的体系结构之间的关系。

SOA是将应用程序逻辑封装在具有均匀定义的界面并通过发现机制公开可用的服务中的应用逻辑的理念。复杂性隐藏和重复使用的概念，但也松散耦合服务的概念激发了研究人员详细说明两种哲学，SOA和Web 2.0及其各自的应用之间的相似之处。一些人认为Web 2.0和SOA具有显著不同的要素，因此不能被视为“平行哲学”，而另一些则认为这两个概念是互补的，并将Web 2.0视为全球SOA。

Web 2.0和SOA的理念满足了不同的用户需求，从而揭示了有关设计以及现实应用程序中使用的技术的差异。但是，截至2008年，用例证明了将Web 2.0和SOA的技术和原理结合起来的潜力。

微服务

微服务是用于构建分布式软件系统的面向服务体系结构的现代解释。微服务体系结构中的服务是通过网络相互通信以实现目标的过程。这些服务使用技术不可知论协议，有助于封装语言和框架的选择，使他们的选择成为服务内部的关注。微服务是一种新的实现和实施方法，自2014年以来（以及在DevOps引入之后）就变得很流行，并且还强调了连续部署和其他敏捷实践。

没有单一的对微服务的共同定义。文献中可以找到以下特征和原则：

细粒界面（到独立部署服务），
业务驱动开发（例如域驱动设计），
理想的云应用架构，
多语言编程和持久性，
轻巧的容器部署，
分散的连续交付，
具有整体服务监控的DevOps。

交互式应用程序面向服务的架构

需要实时响应时间的交互式应用程序，例如低延迟交互式3D应用程序，正在使用针对服务的特定体系结构来满足此类应用程序的特定需求。其中包括例如低延迟优化的分布式计算和通信以及资源和实例管理。