“运行模式”指的是计算资源（应用程序在这些资源上运行）的承载模型。 在微服务体系结构方面，有两种方案特别流行：

  • 可管理专用节点 (VM) 上运行的服务的服务业务流程协调程序。
  • 使用函数即服务 (FaaS) 的无服务器体系结构。

尽管这不是仅有的两个选项，但两者是用于构建微服务的成熟方案。 应用程序可以包含这两种方案。

服务业务流程协调程序

业务流程协调程序处理与一组服务的部署和管理相关的任务。 这些任务包括在节点上放置服务、监视服务运行状况、重启不正常的服务、对服务实例之间的网络流量进行负载均衡、服务发现、缩放服务实例的数目，以及应用配置更新。 常用业务流程协调程序包括 Kubernetes、Service Fabric、DC/OS 和 Docker Swarm。

容器

有时，人们在谈论容器和微服务时将它们看作相同的事物。 尽管不是这样，但您不需要使用容器来构建微服务-容器确实具有一些与微服务特别相关的优点，例如：

  • 可移植性。 容器映像是一个独立包，无需安装库或其他依赖项即可运行。 因此，它们的部署非常轻松。 容器可以快速启动和停止，因此，我们可以运转新的实例来处理更多负载，或者在发生节点故障后进行恢复。

  • 密度。 与运行虚拟机相比，容器比较轻量，因为它们共享 OS 资源。 因此，可将多个容器打包到单个节点。当应用程序由许多小型服务构成时，这种做法特别有利。

  • 资源隔离。 可以限制容器可用的内存量和 CPU，这有助于确保失控的进程不会耗尽主机资源。 有关详细信息，请参阅 Bulkhead 模式 。

无服务器（函数即服务）

使用无服务器体系结构时，无需管理 VM 或虚拟网络基础结构。 可以部署代码，然后让托管服务将该代码放入 VM 并执行。 这种方法往往比较适合用于使用基于事件的触发器协调的小粒度函数。 例如，放入队列的消息可能会触发一个函数，该函数从队列中读取并处理该消息。

选择业务流程协调程序还是无服务器？

在业务流程协调程序方案与无服务器方案之间做出选择时，请考虑下面一些因素。

易管理性无服务器应用程序易于管理，因为平台可自行管理所有计算资源。 尽管业务流程协调程序可将群集管理和配置工作的某些方面抽象化，但它不会完全隐藏底层 VM。 使用业务流程协调程序时，需要考虑负载均衡、CPU 和内存使用率以及网络等方面的问题。

灵活性和控制。 在服务与群集的配置和管理方面，业务流程协调程序提供很高的控制度。 弊端是复杂性会增大。 使用无服务器体系结构会牺牲一定的控制度，因为这些细节已抽象化。

可移植性。 此处列出的所有业务流程协调程序（Kubernetes、DC/OS、Docker Swarm 和 Service Fabric）都可以在本地或多个公有云中运行。

应用程序集成。 使用无服务器体系结构构建复杂的应用程序可能会很困难，因为需要协调、部署和管理许多小型独立函数。

成本。 使用业务流程协调程序时，需要为群集中运行的 VM 付费。 使用无服务器应用程序时，只需为实际消耗的计算资源付费。 在这两种情况下，都需要考虑到任何附加服务（例如存储、数据库和消息传递服务）的成本。

可伸缩性。 使用业务流程协调程序时，可以通过增加群集中运行的服务实例数进行横向扩展。 此外，可以通过将更多 VM 添加到群集进行扩展。

我们的参考实现主要使用 Kubernetes。