你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

选择适用于微服务的 Azure 计算方案

  • 项目

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

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

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

服务业务流程协调程序

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

在 Azure 平台上，请考虑以下选项：

  • Azure Kubernetes 服务 (AKS) 是托管的 Kubernetes 服务。 AKS 预配 Kubernetes 并公开 Kubernetes API 终结点，但可以承载和管理 Kubernetes 控制平面，并可以执行自动升级、自动修补、自动缩放和其他管理任务。 可将 AKS 视为“Kubernetes API 即服务”。

  • Azure 容器应用是基于 Kubernetes 构建的托管服务，它抽象化了容器业务流程和其他管理任务的复杂性。 容器应用可在无服务器环境中简化容器化应用程序和微服务的部署和管理，同时提供 Kubernetes 的功能。

  • Service Fabric 是用于打包、部署和管理微服务的分布式系统平台。 可将微服务作为容器、二进制可执行文件或 Reliable Services 部署到 Service Fabric。 借助 Reliable Services 编程模型，服务可以直接使用 Service Fabric 编程 API 来查询系统、报告运行状况、接收有关配置和代码更改的通知，以及发现其他服务。 它与 Service Fabric 之间的重要区别在于，它重点用于构建使用 Reliable Collections 的有状态服务。

  • 其他选项（例如 Docker Enterprise Edition）可以在 Azure 上的 IaaS 环境中运行。 可以在 Azure 市场找到部署模板。

容器

有时，人们在谈论容器和微服务时将它们看作相同的事物。 尽管这种看法不对 — 不需要容器即可构建微服务 — 但是，容器确实有一些与微服务尤其相关的优势，例如：

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

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

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

无服务器（函数即服务）

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

Azure Functions 是支持各种函数触发器（包括 HTTP 请求、服务总线队列和事件中心事件）的无服务器计算服务。 有关完整列表，请参阅 Azure Functions 触发器和绑定概念。 另请考虑 Azure 事件网格，它是 Azure 中的托管事件路由服务。

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

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

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

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

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

应用程序集成。 由于需要协调、部署和管理许多小型独立函数，使用无服务器体系结构生成复杂的应用程序可能很困难。 在 Azure 中，一种做法是使用 Azure 逻辑应用来协调一组 Azure 函数。 有关此方法的示例，请参阅创建与 Azure 逻辑应用集成的函数。

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

可伸缩性。 Azure Functions 可以根据传入事件的数目按需自动缩放。 使用业务流程协调程序时，可以通过增加群集中运行的服务实例数进行横向扩展。 此外，可以通过将更多 VM 添加到群集进行扩展。

我们的参考实现主要使用 Kubernetes，但对“交付历史记录”服务使用了 Azure Functions。 Azure Functions 非常适合此特定服务，因为它是事件驱动的工作负载。 该服务使用事件中心触发器来调用函数，因此只需少量的代码。 此外，“交付历史记录”服务并非主要工作流的一部分，因此，在 Kubernetes 群集外部运行该服务不会影响用户发起的操作的端到端延迟。

后续步骤

服务间通信