SOA简介

让我们简要回顾一些第3章涵盖的主题，明确它们之间的相互关系以及它们如何明确地导出SOA定义:

我们已经确定，面向服务在一定程度上得到有意义的应用之后，解决方案才被认为是面向服务的。然而，仅仅了解设计范式是不够的。想要一致和成功地应用面向服务需要一个定制的技术架构，以适应其设计偏好，最初是在服务第一次交付时，尤其是当服务集合被大量积累并组装成复杂的服务组合时。

换句话说:

大家转发关注小编，私信小编“学习”得到获取方式吧！、

大家转发关注小编，私信小编“学习”得到获取方式吧！

1.理解服务与微服务的层次

下面是常见的服务模型:

任务服务:具有通常对应于单一用途的父业务流程逻辑的非不可知的功能上下文服务。任务服务通常会封装组成多个其他服务以完成其任务所需的组合逻辑。
微服务:一种非不可知服务，通常包含特定处理和实现需求的逻辑小功能范围。微服务逻辑通常不可重用，但可以具有解决方案内复用潜力。逻辑性质也许会变化。
实体服务:具有与一个或多个相关业务实体(例如发票、客户或索赔)相关联的不可知功能上下文的可重用服务。例如，“采购订单”服务具有与采购订单相关数据和逻辑处理相关联的功能上下文。
公共服务:虽然是具有不可知功能上下文的可重用服务，但这种类型的服务并不是从业务分析规范和模型中得出的。它封装了底层的技术中心功能，例如通知、日志记录和安全处理。

微服务和公共服务的冗余实现被放置在-一个包含系统组件和库的容器内

2.Web服务建模过程

3.REST服务建模过程

4.Web服务的服务API与契约设计

在候选概念服务得以建模并充分细化后，就到了面向服务设计阶段，在此阶段我们可以基于之前面向服务分析过程的结果开始设计物理服务契约。

当构建基于SOAP的Web服务时，这个阶段要求我们在设计相应服务逻辑之前，应用若干契约相关的面向服务原则、以一致和标准的方式将API的设计作为每个服务契约的一部分。

具体来说，通过使用Web服务契约优先方法可以得到以下好处:

我们通常以正式定义服务需要处理的信息开始一一个Web服务契约设计。为了实现这一点，我们需要对在WSDLtypes区域中定义的消息结构进行形式化。SOAP消息在SOAP封装的Body部分中携带数据，并且此数据需要进行组织和显示。为此，我们通常依赖于XML Schema。

注意，在面向服务分析过程中，一个或多个服务更适合通过REST实现而非通过基于SOAP的Web服务技术集来实现。这种情况适用于被识别出的微服务或通过REST使其处理需求得到更好实现的其他服务。

5.Web服务及REST服务的服务API与契约版本控制

在部署服务契约之后，消费者程序自然会开始形成依赖关系。当随后被迫修改契约时，我们需要弄清楚:

这些问题要求我们进行版本控制。每当将版本控制概念引入SOA项目时，可能会引出一些问题，例如:

我们将讨论这些问题，并提供一组解决常见版本问题的选项。

●使用易于理解、简单的语言解释SOA和面向服务基础

●微服务、微任务和容器化

●服务交付生命周期和相关阶段

●服务及微服务的分析与概念化

●REST服务、Web服务及微服务的服务API设计

●Web服务及REST服务的现代服务API与契约版本控制技术

●包括面向服务原则、REST约束和SOA模式(包含3种新模式)的最新附录

本书对应用架构师、企业架构师、软件开发人员以及任何有兴趣了解或负责设计与实现现代面向服务解决方案的IT专业人士来说，都是不可或缺的参考指南。