vlambda博客
学习文章列表

SOA 和微服务遵循类似的概念。在 第 9 章，揭秘微服务中，我们看到微服务是从 SOA 演变而来的，并且许多 service 特征在这两种方法中都很常见。

但是，它们是相同的还是不同的？

由于微服务是从 SOA 演变而来的，因此微服务的许多特性 类似于 SOA。我们先来看看 SOA 的定义。

我们在微服务中也学到了类似的方面。 那么，微服务在哪些方面有所不同？ 答案是——视情况而定。

上一个问题的答案可能是肯定的，也可能是否定的，这取决于组织及其对 SOA 的采用。 SOA 是一个更广泛的术语，不同的组织采用不同的 SOA 方法来解决不同的组织问题。微服务和 SOA 之间的区别在于组织处理 SOA 的方式。

为了清楚起见，将在下一节中检查一些场景。

Service-oriented integration

面向服务的集成指 是许多组织使用的基于服务的集成方法：

许多组织将主要使用 SOA 来解决其集成复杂性，也称为集成意大利面。通常，这被称为面向服务的集成（SOI ）。在这种情况下，应用程序通过使用标准协议和消息格式（例如SOAP/XML）的通用集成层相互通信基于 HTTP 或 Java 消息服务 (JMS) 的 Web 服务.这些类型的组织专注于企业集成模式 (EIP) 来模拟他们的集成需求。这种方法强烈依赖重量级企业服务总线 (ESB） ，如 TIBCO BusinessWorks、WebSphere ESB、Oracle ESB 等。大多数 ESB 供应商还打包了一组相关 产品，例如规则引擎、业务流程管理引擎等，作为 SOA 套件。这种组织的集成深深植根于这些产品中。他们要么在 ESB 层编写繁重的编排逻辑，要么在服务总线中编写业务逻辑本身。在这两种情况下，所有企业服务都通过 ESB 进行部署和访问。这些服务通过企业治理模型进行管理。对于这样的组织，微服务与 SOA 完全不同。

Legacy modernization

SOA 也用于在遗留应用程序之上构建服务层：

另一类组织会在转型项目或遗留现代化项目中使用 SOA。在这种情况下，服务在使用 ESB 适配器连接到后端系统的 ESB 中构建和部署。对于这些组织，微服务不同于 SOA。

Service-oriented application

一些组织会在应用程序级别采用SOA：

在这种方法中，轻量级集成框架，例如Apache Camel 或 Spring Integration，嵌入在应用程序中以处理 服务相关的横切能力，如协议中介、并行执行、编排、服务集成等。由于一些轻量级集成框架支持原生 Java 对象，因此此类应用程序甚至会使用原生 Plain Old Java Objects (POJO) 服务，用于服务之间的集成和数据交换。因此，所有 services 都必须打包为一个单一的 Web 存档。此类组织可以将微服务视为其 SOA 的下一个合乎逻辑的步骤。

Monolithic migration using SOA

下图 显示了 一个单体应用程序，分为三个微应用程序：

最后一种可能性是在单体系统达到临界点后将单体应用程序转换为更小的单元。他们会将应用程序分解为更小的、物理上可部署的子系统，类似于前面解释的 Y 轴缩放 方法，并将它们作为 Web 存档部署在Web 服务器，或者作为部署在一些本地容器上的 jars。这些作为服务的子系统将使用 Web 服务或其他轻量级协议在服务之间交换数据。他们也会使用 SOA 和服务设计原则来实现这一点。对于此类组织，他们可能倾向于认为微服务是新瓶装旧酒。

云计算是发展最快的技术之一。它承诺了许多好处，例如成本优势、速度、敏捷性、灵活性和弹性。有许多云提供商提供不同的服务。他们正在降低成本模型以使其更具对企业有吸引力。不同的云提供商，例如 AWS、Microsoft、Rackspace、IBM、Google 等，使用不同的工具、技术和服务。另一方面，企业意识到这个不断变化的战场，因此，他们正在寻找从锁定到单一供应商的降低风险的选项。

许多组织将其应用程序提升并转移到云。在这种情况下，应用程序可能无法实现云平台承诺的所有好处。有些应用程序需要进行大修，而有些应用程序可能需要在迁移到云端之前进行微调。总的来说，这取决于应用程序的架构和开发方式。

例如，如果应用程序将其生产数据库服务器 URL 硬编码为应用程序战争的一部分，则需要在将应用程序移动到云之前对其进行修改。在云中，基础设施对应用程序是透明的，尤其是不能假设物理 IP 地址。

我们如何确保应用程序甚至微服务可以在多个云提供商之间无缝运行并利用弹性等云服务？

在开发云原生应用程序时遵循某些原则很重要。

云原生是一个术语，用于开发能够在云环境中高效工作的应用程序，并理解和利用云行为，例如弹性、基于利用率的计费、故障感知等。

Heroku 转发的十二要素应用程序是一种描述现代云就绪应用程序预期特征的方法。这十二个因素同样适用于微服务。因此，了解十二要素很重要。

Single code base

代码 base 原则建议每个应用程序应该有一个单一的代码库。同一代码库可以有多个部署实例，例如开发、测试或生产。代码通常在 Git、Subversion 等源代码控制系统中进行管理：

为微服务扩展相同的理念，每个微服务都应该有自己的代码库，并且这个代码库不与任何其他微服务共享。这也意味着一个微服务将只有一个代码库。

Bundle dependencies

根据这一原则，所有应用程序应该 捆绑它们的依赖项 以及应用程序包。借助 Maven 和 Gradle 等构建工具，我们 显式在项目对象模型中管理依赖项（ POM) 或 gradle 文件，并使用中央 build 工件 repository 例如 Nexus 或 Archiva。这将确保正确管理版本。最终的可执行文件将被打包为一个 war 文件或嵌入所有依赖项的可执行 jar 文件：

在微服务的上下文中，这是要遵循的基本原则之一。每个微服务都应该在最终的可执行包中捆绑所有必需的依赖项和执行库，例如 HTTP 侦听器等。

Externalizing configurations

外部化配置principle 为您提供了将代码中的所有配置参数外部化的建议。应用程序的配置参数因环境而异，例如支持电子邮件 ID 或外部系统的 URL、用户名、密码、队列名称等。这些对于开发、测试和生产将有所不同。所有服务配置都应该外部化：

同样的原则对于微服务也是显而易见的。微服务配置参数应该从外部源加载。这也将帮助您自动化发布和部署过程，因为这些环境之间的唯一变化是配置参数。

Backing services are addressable

所有支持服务应该可以通过可寻址的 URL 访问。所有服务都需要在其执行的生命周期中与一些外部资源进行对话。例如，他们可能正在收听消息或向消息系统发送消息、发送电子邮件或将数据持久化到数据库中。所有这些服务都应该可以通过 URL 访问，而无需复杂的通信要求：

在微服务世界中，微服务既可以与消息系统对话以发送或接收消息，也可以接受或发送消息到另一个服务 API。在一般情况下，这些端点要么是使用 REST 和 JSON 的 HTTP 端点，要么是基于 TCP 或 HTTP 的消息传递端点。

Isolation between build, release, and run

这个原则提倡强隔离之间 构建阶段、发布阶段和运行阶段。构建阶段是指通过包含所需的所有资产来编译和生成二进制文件。发布阶段是指将二进制文件与特定于环境的配置参数相结合。运行阶段是指在特定的执行环境上运行应用程序。管道是单向的。因此，不可能将更改从运行阶段传播回构建阶段。本质上，这也意味着不建议为生产进行特定的构建；相反，它必须通过管道：

在微服务中，构建会创建可执行的 jar 文件，包括服务运行时，例如 HTTP 监听器。在发布阶段，这些可执行文件将与发布配置（例如生产 URL 等）相结合，并创建一个发布版本，很可能是像 Docker。在 run 阶段，这些容器将通过容器调度程序部署到生产环境中。

Externalizing logs

十二要素应用从不尝试 存储或发送日志文件。在云中，最好避免使用本地 I/O 或文件系统。如果给定基础架构中的 I/O 速度不够快，它们可能会造成瓶颈。解决方案是使用集中式日志框架。 Splunk、greylog、 Logstash、Logplex、Loggly 是日志传送和分析工具的一些示例。推荐的方法是ship 通过点击central 存储库="indexterm"> logback 附加程序并写入托运人的端点之一。

在微服务生态系统中，这非常重要，因为我们正在将一个系统分解为许多较小的服务，这可能会导致去中心化日志记录。如果他们将日志存储在本地存储中，那么在服务之间关联日志将非常困难：

在开发中，微服务可能会将日志流定向到 stdout，而在生产中，这些流将被日志传送器捕获并发送到中央用于存储和分析的日志服务。

无服务器计算架构或功能即服务（FaaS) 这些天来已经获得了相当多的人气。在无服务器计算中，开发人员需要不用担心关于 应用服务器、虚拟机、容器、基础设施、可扩展性和其他服务质量。相反，开发人员编写函数并将这些函数放入已经运行的计算基础设施中。无服务器计算提高了更快的软件交付速度，因为它消除了微服务所需的基础设施的供应和管理部分。有时，这甚至被称为 NoOps。

FaaS 平台支持 多种语言运行时，例如Java、Python、Go 等。有许多无服务器计算平台和框架可用。而且，这个space还在不断发展。 AWS Lambda、IBM OpenWhisk、Azure Functions、Google Cloud Functions 是一些流行的无服务器计算托管基础架构。 Red Hat Funktion 是另一个 无服务器< span>computing 平台位于 Kubernetes 之上，该平台可以部署在任何云或本地。 IronFunctions 是最近的参赛者之一——一个与云无关的无服务器计算平台。还有other serverless 计算平台，比如用于web相关功能的Webtask。 BrightWork 是另一个用于 JavaScript 应用程序的无服务器计算平台 < /a> 提供minimal 供应商锁定。

还有 许多 其他框架旨在简化支持不同语言的 AWS Lambda 开发和部署。 Apex、无服务器、 适用于 Java 的 Lambda 框架、适用于 Python 的 Chalice、 Claudia for Node JS、Sparta for Go 和 Gordon< /strong> 是 一些 ="indexterm"> 此类别中流行的frameworks。

无服务器计算与微服务密切相关。换句话说，微服务是无服务器计算的基础。无服务器计算和微服务都有 number 的特征。与微服务类似，函数通常一次执行一项任务，本质上是隔离的，并通过指定的基于事件或 HTTP 的 API 进行通信。此外，函数的占用空间更小，如微服务。可以肯定地说，功能遵循基于微服务的架构。

下图展示了一个基于 AWS Lambda 的无服务器计算场景：

在这种情况下，每个微服务都将被开发为一个单独的 AWS Lambda 函数，并通过 API 网关独立连接以进行基于 HTTP 的通信。在这种情况下，每个微服务都将自己的数据保存在 Amazon DynamoDB 中。

通常，FaaS 计费模型真正基于 按使用付费 模型，而不是为虚拟的情况下遵循的保留模型付费机器 或EC2 实例。此外，开发人员不必担心在不再使用图像时会钝化图像。当只有少数交易时，将收取足够的计算能力。随着负载的增加，会自动分配更多的资源。这使得无服务器计算成为许多企业的有吸引力的模型。

新型微服务用例，如大数据、认知计算、物联网和机器人，是无服务器计算的完美候选者。有关这些用例的更多信息将在下一节中解释。

同样重要的是要注意，无服务器计算的缺点是其强大的供应商锁定。这个领域仍在变得成熟，也许我们会在这个领域看到更多的工具来缩小这些差距。未来，我们还将看到市场上有大量服务可供微服务开发人员在无服务器计算平台上进行开发时使用。无服务器计算与微服务架构一起，绝对是开发人员的一个有前途的选择。

在大数据、认知计算、机器人和物联网的背景下，微服务用例有新的样式：

上图显示了大数据、认知和 IoT 环境中常用的简化 Lambda 架构。正如您在图中看到的那样，微服务在架构中起着至关重要的作用。批处理层处理数据，通常存储在 Hadoop 分布式文件系统 (HDFS) 文件系统。微服务写在这个批处理层处理数据之上，并构建 serving 层。由于微服务是独立的，当它们遇到新的需求时，很容易将这些实现添加为微服务。

速度层微服务主要是用于流处理的反应式微服务。这些微服务接受数据流，应用逻辑，然后用另一组事件响应。同样，微服务也用于在服务层之上公开数据服务。

以下是上述架构的不同变体：

云（更具体地说，容器）、微服务和 DevOps 三重奏的目标是一组 common 目标——交付速度、商业价值和成本效益。所有三个都可以保持进化< /a> 独立，但它们相互补充以实现预期的共同目标。从事其中任何一项工作的组织自然倾向于考虑其他密切相关的组织：

许多组织开始将 DevOps 作为一种组织实践来实现高速发布周期，但最终转向微服务架构和云。但是，拥有微服务和云来支持 DevOps 并不是强制性的。然而，自动化大型单体应用程序的发布周期没有多大意义，而且在许多情况下，这是不可能实现的。在这种情况下，微服务架构和云将在实施 DevOps 时派上用场。

如果我们掷硬币，云不需要微服务架构来实现它的好处。然而，为了有效地实施微服务，云和 DevOps 都是必不可少的。

总而言之，如果一个组织的目标是以具有成本效益的方式实现交付速度和质量，那么这三者的结合可以带来巨大的成功。

反应式编程范式是一种有效的 方式来构建可扩展、容错的应用程序。反应式宣言定义了反应式编程的basic哲学。

通过将反应式编程原理与微服务架构相结合，开发人员可以构建低延迟、高吞吐量的可扩展应用程序。

微服务通常是围绕业务能力设计的。理想情况下，设计良好的微服务将表现出微服务之间的最小依赖关系。然而，实际上，当期望微服务提供与单体应用程序相同的功能时，许多微服务必须协同工作。根据业务能力划分服务并不能解决所有问题。服务之间的隔离和通信也同样重要。尽管微服务通常是围绕业务能力设计的，但通过同步调用将它们连接起来可能会在它们之间形成硬依赖。因此，组织可能没有意识到微服务的全部好处。它们之间具有强依赖关系的分布式系统有其自身的开销并且难以管理。例如，如果其中一个微服务需要升级，它可能会严重影响其他依赖服务。因此，采用响应式风格对于成功的微服务实现很重要。

让我们进一步研究一下反应式微服务。处理响应式编程时有四个支柱。这些属性是 resilient、responsive、基于消息的和弹性。弹性和响应能力与孤立密切相关。隔离是both响应式编程的基础well 作为微服务。每个微服务都是自治的，并且是 largerbuilding 块class="indexterm"> 系统。总的来说，这些微服务通过围绕业务功能绘制边界而与其其他功能组件隔离。通过这样做，一个服务的故障可以很好地与其他服务隔离。如果发生故障，它不应对其下游服务造成问题。后备服务或同一服务的副本将暂时接管其职责。通过引入隔离，每个隔离的组件都可以独立扩展、管理和监控。

即使隔离已经到位，如果服务之间的通信或依赖关系被建模为同步阻塞 RPC 调用，则无法完全隔离故障。因此，通过使用异步非阻塞调用以反应式设计服务之间的通信非常重要：

如上图所示，在响应式系统中，每个微服务都会监听一个事件。服务在接收到输入事件时做出反应。然后服务开始处理该事件并发送另一个响应事件。微服务本身不知道生态系统中运行的任何其他服务。在此示例中，微服务 1 不了解 微服务 2 和 微服务 3。可以通过将一个服务的输出队列连接到另一个服务的输入队列来实现编排，如图所示。

根据事件的速度，服务可以通过旋转实例的副本来自动扩展。例如，在反应式订单管理系统中，一旦下单，系统就会发出 Order Event。可能有许多微服务在监听 Order Event。 在消费 this 事件，它们执行各种操作。这种设计还允许开发人员在需要时不断添加越来越多的反应例程。

反应式微服务的流程控制或编排将自动处理，如图前面所示。没有中央指挥和控制。相反，微服务本身的消息和输入输出合约将建立流程。更改 message 流程是easy 通过rewiring 输入输出队列来实现。

高度可扩展且可靠的消息系统是反应式微服务生态系统中最重要的组件。 QBit, Spring Reactive, RxJava 和 RxJS 是一些帮助您构建反应式微服务的框架和库。 Spring 5 inbuilt 支持 develop 反应式网络应用程序。 Spring Cloud Streams 是构建真正的好选择 使用 Spring Framework 的反应式微服务。

A reactive microservice-based order management system

让我们看看另一个 微服务 示例：一个在线零售网站。在这种情况下，我们会更加关注后端服务，比如客户通过网站下单时产生的订单事件：

该微服务系统完全基于反应式编程实践而设计。

当一个事件被发布时，许多微服务在接收到事件后就准备好启动了。它们中的每一个都是独立的，不依赖于其他微服务。这种模型的优点是我们可以不断添加或替换微服务来实现特定的需求。

在上图中，显示了八个微服务。 OrderEvent 到达时会发生以下活动：

• OrderService kicks off when an OrderEvent is received. OrderService creates an order and saves details to its own database.
• If the order is successfully saved, an OrderSuccessfulEvent is created by OrderService and published.
• A series of actions will take place when OrderSuccessfulEvent arrives.
• DeliveryService accepts the event and places a DeliveryRecord to deliver the order to the customer. This in turn generates DeliveryEvent and publishes the event.
• The TruckingService picks up the DeliveryEvent and processes it. For instance, TruckingService creates a trucking plan.
• CustomerNotificationService sends a notification to the customer informing the customer that an order is placed.
• InventoryCacheService updates the inventory cache with the available product count.
• StockReorderService checks whether the stock limits are adequate and generates ReplenishEvent if required.
• CustomerPointsService recalculates the customer's loyalty points based on this purchase.
• CustomerAccountService updates the order history in the customer account.

在这种方法中，每个服务只负责一个功能。服务接受并生成事件。每个服务都是独立的，不知道它的邻域。因此，邻域可以像 蜂窝类比中提到的那样有机地增长。必要时可以添加新服务。添加新服务不会影响任何现有服务。

微服务不是灵丹妙药，它不能解决当今世界的所有架构挑战。对于何时使用微服务，没有硬性规定或严格的指导方针。

微服务可能并不适合每个用例。微服务的成功很大程度上取决于用例的选择。第一个也是最重要的活动是针对微服务优势对用例进行试金石测试。试金石必须涵盖我们在本章前面讨论过的所有微服务优势。对于给定的用例，如果没有可量化的收益，或者成本超过收益，那么该用例可能不是微服务的正确选择。

让我们讨论一些适合微服务架构候选的常用使用场景：

如果用例属于这些类别中的任何一个，它们就是微服务架构的潜在候选者。在微服务中我们应该考虑避免一些场景：

许多组织已经成功地踏上了通往微服务世界的旅程。在本节中，我们将研究微服务领域的一些领先者，以分析他们为什么这样做，以及他们是如何做到的？以下是根据 Internet 上提供的信息整理的组织 采用微服务的列表：

微服务是已经在< /a> 主流。当开发微服务时，有 一些横切关注 需要实现，例如externalized< id="id325951075" class="indexterm"> 日志记录、跟踪、嵌入式 HTTP 侦听器、健康检查等。因此，重大的努力将进入 开发这些 横切关注点。微服务frameworks就是在这个领域出现来填补这些空白的。

有很多微服务frameworks< /a> 可用 apart 从 那些 是提到特别 下的 serverless 计算。功能各不相同在这些微服务 框架。因此，为开发选择正确的framework 很重要。

Spring Boot、Dropwizard 和 Wildfly Swarm 是用于开发 微服务。但是，这些框架只提供 简约支持 用于大规模微服务 开发。 Spring Boot 与 Spring Cloud 一起为微服务提供了完善的支持。 Spring Framework 5 引入了 响应式网络框架。结合 Spring Boot 和 Spring Framework 5 响应式是响应式微服务的不错选择。或者，Spring Streams 也可用于 微服务 发展。

以下是其他微服务框架的精选列表：

这个列表并没有到此结束。这一类还有很多，比如 Kontena、Gilliam、Magnetic、Eventuate、LSQ 和 Stellient，这些都是支持微服务的一些平台。

本书的其余部分将重点介绍使用 Spring Framework 项目构建微服务。

在本章中，我们了解了微服务架构与其他一些流行的架构风格的关系。

我们从与 SOA 和十二要素应用程序的微服务关系开始。我们还研究了微服务架构与其他架构之间的联系，例如无服务器计算架构和 Lambda 架构。我们还了解了将微服务与云和 DevOps 结合使用的优势。然后，我们分析了一些来自不同行业的成功采用微服务的企业及其用例的示例。最后，我们回顾了一段时间内发展起来的一些微服务框架。

在下一章中，我们将开发一些示例微服务，以使我们在本章中的学习更加清晰。