03_SOA(Service-oriented|03_SOA(Service-oriented architecture)详解 03_SOA(Service-orientedarchitecture)

SOA 面向服务的体系结构(SOA)是一种软件设计风格，其中服务由应用程序组件通过网络上的通信协议提供给其他组件。面向服务体系结构的基本原则独立于供应商、产品和技术。服务是一个独立的功能单元，可以远程访问、独立操作和更新，比如在线检索信用卡对账单。
根据SOA的许多定义，服务有四个属性:

它在逻辑上表示具有指定结果的业务活动。
它是自包含的。
对于消费者来说，这是一个黑匣子。
它可能包括其他基础服务

可以结合使用不同的服务来提供大型软件应用程序的功能，这是SOA与模块化编程共享的原则。面向服务的体系结构集成了分布式、独立维护和部署的软件组件。它是通过技术和标准实现的，这些技术和标准促进了组件在网络上的通信和合作，特别是在IP网络上。
概述
在SOA中，服务使用协议来描述如何使用描述元数据传递和解析消息。该元数据描述了服务的功能特征和服务质量特征。面向服务的体系结构旨在允许用户将大块功能组合起来，形成纯粹由现有服务构建的应用程序，并以特定的方式组合它们。服务向请求者提供一个简单的接口，该接口抽象出作为黑盒子的底层复杂性。此外，用户还可以访问这些独立的服务，而不需要知道它们的内部实现。
定义概念
相关的流行语服务导向促进了服务之间的松散耦合。SOA将功能分为不同的单元或服务，开发人员可以通过网络访问这些单元或服务，以便允许用户在应用程序的生产中组合和重用它们。这些服务及其相应的消费者通过以明确定义的共享格式传递数据或通过协调两个或更多服务之间的活动来相互通信。
2009年10月发布了一份面向服务架构的宣言。其中提出了六个核心价值观，如下所示：

商业价值比技术战略更重要。
战略目标比项目特定的利益更重要。
内在互操作性比定制集成更重要。
共享服务比特定用途实现更重要。
灵活性比优化更重要。
进化精炼比追求初始完美更重要。

SOA可以被视为连续体的一部分，其范围从分布式计算的旧概念和模块化编程，到SOA，再到当前的mashup，SaaS和云计算实践（有些人认为是SOA的后代）。
原则
尽管许多行业来源已经发布了自己的原则，但没有与面向服务架构的确切组成相关的行业标准。其中一些包括以下内容：

标准化服务合同
- 服务遵循标准通信协议，由一组给定服务中的一个或多个服务描述文档共同定义。
服务引用自治（松散耦合的一个方面）
- 服务之间的关系被最小化到他们只知道它们存在的水平。
服务地点透明度（疏松耦合的一个方面）
- 无论网络位于何处，都可以从网络中的任何位置调用服务。
服务寿命
- 服务的设计应该是长期的。在可能的情况下，如果服务不需要新特性，就应该避免强制消费者进行更改，如果您今天调用服务，那么明天就应该能够调用相同的服务。
服务抽象
- 服务充当黑盒，即它们的内部逻辑对消费者隐藏。
服务的自主权
- 服务是独立的，并且从设计时和运行时的角度控制它们封装的功能。
服务无国籍
- 服务是无状态的，即要么返回请求的值，要么提供异常，从而最小化资源的使用。
服务粒度
- 确保服务具有足够大小和范围的原则。服务提供给用户的功能必须是相关的。
  服务标准化
- 服务被分解或合并(规范化)以最小化冗余。在某些情况下，可能不需要这样做，这些情况下需要性能优化、访问和聚合。
服务的可组合性
- 服务可用于组合其他服务。
服务发现
- 服务由通信元数据补充，通过这些元数据可以有效地发现和解释服务。
服务的可重用性
- 逻辑被划分为各种服务，以提升代码的重用。
服务封装
- 许多最初没有在SOA下计划的服务可能被封装或成为SOA的一部分。

Patterns
每个SOA构建块都可以扮演以下三个角色之一:

服务提供者
- 它创建Web服务并将其信息提供给服务注册表。每个提供商都会讨论大量的方法，以及为什么要公开哪些服务，哪些更重要：安全性或易用性，提供服务的价格等等。
- 提供商还必须决定应该为给定的代理服务列出服务的类别以及使用该服务需要哪种贸易伙伴协议。
服务代理，服务注册表或服务仓库
- 其主要功能是使任何潜在请求者都能获得有关Web服务的信息。实施经纪人的人决定经纪人的范围。公共经纪人随处可见，但私人经纪人只能向有限的公众开放。UDDI是一种早期的，不再主动支持的尝试来提供Web服务发现。
服务请求者/消费者
- 它使用各种查找操作在代理注册表中查找条目，然后绑定到服务提供者以调用其中一个Web服务。无论服务消费者需要哪种服务，他们都必须将其带入经纪人，将其与相应的服务绑定，然后使用它。如果服务提供多种服务，他们可以访问多种服务。

服务消费者 - 提供者关系由标准化服务合同管理，其中包括业务部分，功能部分和技术部分。
服务组合模式有两种广泛的高级架构风格：编排和编排。不受特定体系结构风格约束的较低级别的企业集成模式在SOA设计中仍然具有相关性和合格性。
实施方法
面向服务的体系结构可以使用Web服务实现。这样做是为了使功能构建块可以通过独立于平台和编程语言的标准Internet协议访问。这些服务既可以代表新应用程序，也可以代表现有遗留系统的包装，使其具备网络功能。
实施者通常使用Web服务标准构建SOA。一个例子是SOAP，它在2003年从W3C（万维网联盟）推荐1.2版后获得了广泛的行业认可。这些标准（也称为Web服务规范）也提供了更大的互操作性和一些保护锁定专有供应商软件。但是，也可以使用任何其他基于服务的技术（如Jini，CORBA或REST）实现SOA 。
架构可以独立于特定技术运行，因此可以使用多种技术实现，包括：

基于WSDL和SOAP的Web服务
消息传递，例如，使用ActiveMQ，JMS，RabbitMQ
RESTful HTTP，具有Representational状态转移（REST），构成自己的基于约束的架构风格
OPC-UA
WCF（Microsoft的Web服务实现，构成WCF的一部分）
Apache Thrift
GRPC
SORCER

实现可以使用这些协议中的一个或多个，例如，可以使用文件系统机制来遵循符合SOA概念的进程之间的定义的接口规范来传送数据。关键是具有已定义接口的独立服务，可以调用这些接口以标准方式执行其任务，而无需服务预先知道调用应用程序，并且应用程序不需要或不需要知道服务如何实际执行其任务。SOA支持开发通过组合松散耦合和可互操作的服务构建的应用程序。
这些服务基于独立于底层平台和编程语言的正式定义（或合同，例如WSDL）进行互操作。接口定义隐藏了特定于语言的服务的实现。因此，基于SOA的系统可以独立于开发技术和平台（例如Java，.NET等）运行。例如，在运行于.NET平台上的C＃和用Java EE平台上运行的Java编写的服务编写的服务都可以由公共复合应用程序（或客户端）使用。在任一平台上运行的应用程序也可以使用在另一平台上运行的服务作为便于重用的Web服务。托管环境还可以包装COBOL遗留系统并将其作为软件服务提供。
诸如BPEL之类的高级编程语言和诸如WS-CDL和WS-Coordination之类的规范通过提供一种定义和支持将细粒度服务编排成更粗粒度的业务服务的方法来扩展服务概念，架构师可以反过来并入在复合应用程序或门户中实现的工作流和业务流程。
面向服务的建模是一个SOA框架，它可以识别指导SOA从业者对其面向服务的资产进行概念化，分析，设计和构建的各种规程。在面向服务的建模框架（SOMF）提供了一个建模语言和工作结构或“地图”描绘了有助于成功的面向服务的建模方法的各种组件。它说明了识别服务开发方案的“做什么”方面的主要元素。该模型使从业者能够制定项目计划并确定面向服务的计划的里程碑。SOMF还提供了一种通用的建模符号，以解决业务和IT组织之间的一致性问题。
组织利益
一些企业架构师认为，SOA可以帮助企业更快，更经济地响应不断变化的市场条件。这种体系结构促进了宏（服务）级别的重用，而不是微观（类）级别的重用。它还可以简化现有IT（传统）资产的互连和使用。
使用SOA，我们的想法是组织可以从整体上看待问题。企业拥有更多的整体控制权。从理论上讲，不会有大量的开发人员使用任何工具集可能会让他们满意。但他们将编码为业务中设定的标准。他们还可以开发企业级SOA，封装面向业务的基础架构。SOA也被描述为为汽车驾驶员提供效率的高速公路系统。关键在于，如果每个人都有车，但在任何地方都没有高速公路，那么事情就会受到限制和混乱，无论是试图快速或有效地到达任何地方。IBM Web服务副总裁Michael Liebow表示，SOA“建设高速公路”。
在某些方面，SOA可以被视为架构演变而不是革命。它捕获了以前软件架构的许多最佳实践。例如，在通信系统中，很少开发使用真正静态绑定与网络中的其他设备通信的解决方案。通过采用SOA方法，此类系统可以将自己定位为强调定义明确，高度可互操作的接口的重要性。SOA的其他前身包括基于组件的软件工程和远程对象的面向对象分析和设计（OOAD），例如，在CORBA中。
服务包括仅通过正式定义的界面可用的独立功能单元。服务可以是某种易于生产和改进的“纳米企业”。服务也可以是作为下属服务的协调工作而构建的“大型企业”。SOA的成熟部署有效地定义了组织的API。
将服务实施视为大型项目的单独项目的原因包括：

分离将业务概念推广到业务，即服务可以快速独立地从组织中常见的较大且移动较慢的项目中提供。业务开始了解呼叫服务的系统和简化的用户界面。这提倡敏捷。也就是说，它促进了业务创新并加快了产品上市时间。
分离促进了服务与消费项目的脱钩。这样可以鼓励良好的设计，因为服务的设计不需要知道消费者是谁。
服务的文档和测试工件未嵌入较大项目的详细信息中。当服务需要稍后重用时，这很重要。

SOA承诺间接简化测试。服务是自治的，无状态的，具有完全记录的接口，并且与实现的横切关注点分开。如果组织拥有适当定义的测试数据，则会构建相应的存根，以便在构建服务时对测试数据做出反应。还会为服务捕获一整套回归测试，脚本，数据和响应。该服务可以使用与其调用的服务相对应的现有存根作为“黑盒子”进行测试。可以构建测试环境，其中原始和超出范围的服务是存根，而网格的其余部分是完整服务的测试部署。由于每个界面都有完整的文档，并有自己的全套回归测试文档，识别测试服务中的问题变得很简单。测试演变为仅仅根据其文档验证测试服务是否运行，并且发现环境中所有服务的文档和测试用例存在差距。管理数据的状态幂等服务是唯一的复杂性。
批评
SOA已经与Web服务混为一谈; 但是，Web服务只是实现构成SOA样式的模式的一种选择。在没有本机或二进制形式的远程过程调用（RPC）的情况下，应用程序可能运行得更慢并且需要更多处理能力，从而增加了成本。大多数实现都会产生这些开销，但SOA可以使用不依赖于远程过程调用或通过转换的技术（例如，Java Business Integration（JBI），Windows Communication Foundation（WCF）和数据分发服务（DDS））来实现。 XML。同时，新兴的开源XML解析技术（如VTD-XML）和各种XML兼容的二进制格式有望显着提高SOA性能。使用JSON而不是XML实现的服务不会受到此性能问题的影响。
有状态服务要求消费者和提供者共享相同的特定于消费者的上下文，该上下文包含在提供者和消费者之间交换的消息中或由其引用。如果服务提供者需要为每个消费者保留共享上下文，则该约束的缺点在于它可能降低服务提供者的整体可伸缩性。它还增加了服务提供商和消费者之间的耦合，使交换服务提供商更加困难。最终，一些批评者认为SOA服务仍然受到他们所代表的应用程序的限制。
面向服务的体系结构面临的主要挑战是管理元数据。基于SOA的环境包括许多彼此之间进行通信以执行任务的服务。由于设计可能涉及多个服务一起工作，因此应用程序可能会生成数百万条消息。进一步的服务可能属于不同的组织甚至是竞争公司，造成巨大的信任问题。因此SOA治理进入了事物的计划。
SOA面临的另一个主要问题是缺乏统一的测试框架。没有工具可以提供在面向服务的体系结构中测试这些服务所需的功能。困难的主要原因是：

异质性和解决方案的复杂性。
由于自主服务的集成，大量的测试组合。
包含来自不同和竞争供应商的服务。
由于新功能和服务的可用性，平台不断变化。

扩展和变体

事件驱动的架构
Web 2.0
- 蒂姆·奥莱利（Tim O'Reilly）创造了“ Web 2.0 ” 这一术语来描述一种快速增长的基于网络的应用程序。经历了广泛报道的主题涉及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的技术和原则的潜力。
微服务
- 微服务是对用于构建分布式软件系统的面向服务的体系结构的现代解释。在一个微服务架构服务是过程与彼此之间通过所述通信网络，以满足一个目标。这些服务采用技术无关的协议，这有助于封装语言和框架的选择，使他们的选择，内部的服务问题。微服务是SOA的一种新的实现和实现方法，自2014年（以及DevOps引入之后）开始流行，并且还强调持续部署和其他敏捷实践。