通过

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

将微服务部署到 Azure 容器应用

Azure 容器应用
Azure Cosmos DB
Azure 服务总线

此方案显示了最初为 Kubernetes 设计的一个现有工作负荷，该工作负载已重新配置为在 Azure 容器应用中运行。 容器应用支持团队希望简化基础结构和容器业务流程的布朗菲尔德工作负载。

示例工作负荷是容器化微服务应用程序。 它重复使用 在 Azure Kubernetes 服务（AKS）上的微服务体系结构中定义的相同工作负荷。 此体系结构将容器应用中的工作负荷重新托管为其应用程序平台。

重要

此体系结构侧重于最大程度地减少应用程序代码更改，并将从 AKS 过渡到容器应用作为平台迁移。 目标是复制现有实现并延迟可能危及迁移的代码或基础结构优化。

对于全新开发的工作负荷，请参阅 使用容器应用和 Dapr 部署微服务。

提示

示例实现支持此体系结构，并说明了本文所述的一些设计选择。

体系结构

显示解决方案的运行时体系结构的关系图。

下载此体系结构的 Visio 文件。

相同环境中的服务可以通过以下方式受益：

  • 内部入口和服务发现
  • 用于运行时日志记录的单个 Log Analytics 工作区
  • 机密和证书的安全管理方法

数据流

  1. 引入服务： 接收客户端请求，对其进行缓冲，然后将其发布到 Azure 服务总线。 它是工作负载的唯一入口点。

  2. 工作流服务： 消费来自服务总线的消息并将其调度到底层微服务。

  3. 包服务：管理包。 该服务在 Azure Cosmos DB 中维护自己的状态。

  4. 无人机计划程序服务：安排无人机并监视无人机飞行。 该服务在 Azure Cosmos DB 中维护自己的状态。

  5. 交付服务： 管理已计划的或运输中的配送。 该服务在 Azure 托管 Redis 中维护自己的状态。

  6. 机密检索： 因为它是现有工作负荷，因此只有一些组件访问 Azure Key Vault 以获取运行时机密。 其他服务从容器应用环境接收这些机密。

  7. 日志和指标： 环境和所有容器应用都会发出 Azure Monitor 功能的日志和指标，然后收集和可视化。

  8. 容器映像： 容器映像是从以前用于 AKS 并部署到容器应用环境的现有 Azure 容器注册表中提取的。

组件

工作负荷使用以下 Azure 服务来相互协调：

  • 容器应用 是一个无服务器容器平台，可简化容器业务流程和管理。 在此体系结构中，容器应用充当所有微服务的主托管平台。

    以下功能取代了以前的 AKS 体系结构的许多功能：

    • 内置服务发现
    • 托管 HTTP 和 HTTP/2 终结点
    • 集成负载均衡
    • 日志记录和监视
    • 基于基于 Kubernetes 的事件驱动自动缩放（KEDA）支持的 HTTP 流量或事件自动缩放
    • 应用程序升级和版本控制

  • 容器注册表 是用于存储和管理专用容器映像的托管注册表服务。 在此体系结构中，它是部署到容器应用环境的所有容器映像的源。 注册表与 AKS 实现中使用的注册表相同。

  • Azure Cosmos DB 是一种全球分布式多模型数据库服务。 在此体系结构中，无人机计划程序服务使用 Azure Cosmos DB 作为其数据存储。

  • Azure DocumentDB 是一种完全托管的 MongoDB 兼容的数据库服务，用于生成新式应用程序。 在此体系结构中，包服务使用 Azure DocumentDB 作为其数据存储。

  • 服务总线 是一种云消息传送服务，提供异步通信功能和混合集成。 在此体系结构中，它处理引入服务与基于任务的工作流微服务之间的异步消息传送。 现有应用程序中的其余服务设计为其他服务可以使用 HTTP 请求调用它们。

  • Azure 托管 Redis 是一个内存缓存服务。 在此体系结构中，它可降低延迟并提高频繁访问的无人机交付数据的吞吐量。

  • Key Vault 是一项云服务，用于安全地存储和访问 API 密钥、密码和证书等机密。 在此体系结构中，无人机计划程序和交付服务使用用户分配的托管标识对 Key Vault 进行身份验证，并检索运行时要求所需的机密。

  • Azure Monitor 是一种全面的监视解决方案，用于收集和分析遥测数据。 在此体系结构中，它通过 Log Analytics 工作区从所有应用程序组件收集和存储指标和日志。 使用此数据监视应用程序、设置警报和仪表板，并执行故障的根本原因分析。

    • Application Insights 是一种提供可扩展监视功能的应用程序性能管理服务。 在此体系结构中，每个服务都使用 Application Insights SDK 进行检测，以监视应用程序性能。

备选方法

高级 AKS 微服务体系结构描述了使用 Kubernetes 的此示例的替代方案。

方案详细信息

可以使用容器应用（用于托管容器化应用程序的无服务器环境）简化微服务容器的部署和管理。

Fabrikam，Inc.，一家虚构的公司，实施无人机交付工作负载，用户要求无人机拿起货物交付。 当客户安排取件时，后端系统会分配无人机，并向用户通知估计的取件时间。

微服务应用程序已部署到 AKS 群集。 但 Fabrikam 团队没有利用高级或特定于平台的 AKS 功能。 它们将应用程序迁移到容器应用，使应用程序能够执行以下作：

  • 将应用程序从 AKS 移动到容器应用时，采用最少的代码更改。 代码更改与可观测性库相关，这些库使用 Kubernetes 节点信息扩充日志和指标，这些信息在新环境中不相关。

  • 使用 Bicep 模板部署基础结构和工作负载：部署其应用程序容器不需要 Kubernetes YAML 清单。

  • 通过托管入口公开应用程序。 内置对基于 HTTPS 的外部入口的支持，用于公开引入服务，从而无需用户自行配置入口。

  • 从容器注册表拉取容器映像。 容器应用与存储在任何可用存储库中的任何 Linux 基础映像兼容。

  • 使用修订功能来支持应用程序生命周期需求。 它们可以运行特定容器应用的多个修订版，并针对 A/B 测试或蓝/绿部署方案跨它们拆分流量。

  • 使用托管标识通过 Key Vault 和容器注册表进行身份验证。

可能的用例

将基于微服务的应用程序部署到平台即服务（PaaS）中，以简化管理并避免运行容器业务流程协调程序的复杂性。 由于以下原因，与 Kubernetes 部署相比，布朗菲尔德工作负载通过使用这种体系结构节省了资金：

  • 工作负载配置选择
  • 运营团队在第 2 天运营任务上花费的时间减少
  • 避免过度预配的能力

注释

并非所有工作负荷都会产生这种成本节省。

考虑容器应用的其他常见用途：

  • 在无服务器、基于消耗的平台上运行容器化工作负荷。
  • 根据 HTTP 或 HTTPS 流量以及 KEDA 支持的事件驱动触发器来自动缩放应用程序。
  • 最大程度地减少容器化应用程序的维护开销。
  • 部署 API 终结点。
  • 主持后台处理的应用程序。
  • 处理事件驱动的流程。

Optimizations

工作负荷团队的目标是将现有工作负载迁移到容器应用，只需更改最少的代码。 但是，在迁移后，应进行多项优化来改进体系结构和工作负荷实现。

改进机密管理

工作负荷使用混合方法来管理机密。 仅当切换到托管标识不需要修改代码时，托管标识才适用于这些服务。 无人机计划程序和交付服务使用用户分配的托管标识和 Key Vault 来访问存储的机密。 其余服务需要代码更改才能采用托管标识，因此这些服务使用容器应用环境提供的机密。

更好的方法是使用应用或作业标识（而不是环境提供的机密）更新所有代码以支持托管标识。 有关工作负荷标识的详细信息，请参阅 容器应用中的托管标识。

避免需要单一修订模式的设计

工作流服务容器应用在单一修订模式下运行。 在单一修订模式下，应用有一个由零个或多个副本支持的修订。 副本由应用容器和任何必需的 sidecar 组成。 此示例不使用边车，因此每个副本都是单个容器。 工作流服务不是为与消息架构向前兼容而设计的。 两个不同的服务版本不应并发运行。

如果服务总线消息架构必须更改，则必须在部署新的工作流服务版本之前清空总线。 更好的方法是更新服务代码，以实现向前兼容，同时使用多版本模式来减少与清空队列相关的停机时间。

考虑基于职位的工作

工作流服务作为长时间运行的容器应用实现。 但它也可以在 容器应用中作为作业运行。 作业是一个容器化应用程序，可按需启动，根据可用工作运行以完成，然后关闭并释放资源。 作业比连续运行的副本更具经济性。 迁移服务以基于队列中可用的工作作为容器应用作业运行可能是一个实用选项。 这取决于典型的队列量，以及工作流服务是否编写得有限、可并行化并且资源优化。 试验并验证以确定最佳方法。

实施入站控制

工作负荷使用容器应用的内置外部入口功能来公开引入服务。 入口控制方法无法完全将入口点定位到 Web 应用程序防火墙（WAF）后面或将其包含在 Azure DDoS 防护计划中。 需要通过 WAF 保护所有对外的 Web 工作负载。 若要在容器应用环境中实现此配置，应禁用内置公共入口并添加 应用程序网关 或 Azure Front Door。

注释

网关需要有意义的运行状况探测，使入口服务保持活动状态，并防止其缩放到零。

使用 Dapr 实现现代化

可以通过与 分布式应用程序运行时（Dapr）集成来进一步现代化工作负荷。 它增加了工作负荷代码与状态存储、消息系统和服务发现机制之间的抽象。 有关详细信息，请参阅 使用容器应用和 Dapr 部署微服务。 如果 Kubernetes 中的工作负载已使用 Dapr 或常见的 KEDA 缩放程序，则迁移到容器应用通常是直接的，可以保留该功能。

迁移到用户身份验证和授权

工作负载不会将授权职责委托给网关。 引入服务处理其客户端的授权。 更好的方法是将此责任卸载到 内置身份验证和授权功能，通常称为 “轻松身份验证”。 此更改利用平台功能并减少引入微服务中的自定义代码。

注意事项

以下注意事项实现 Microsoft Azure Well-Architected Framework 的支柱，这是一组指导原则，可用于提高工作负荷的质量。 有关详细信息，请参阅 Azure Well-Architected Framework。

可靠性

可靠性有助于确保应用程序能够履行对客户的承诺。 有关详细信息，请参阅 可靠性的设计评审清单。

容器应用可帮助你部署、管理、维护和监视工作负荷中的应用程序。 可以遵循核心建议来提高可靠性。 从 Kubernetes 迁移期间会实施一些建议。

  • 修订有助于在零停机的情况下部署应用程序更新。 可以使用修订来管理应用程序更新的部署，并在修订之间拆分流量以支持蓝/绿部署和 A/B 测试。

  • 借助容器应用可观测性功能，可以深入了解环境中运行的组件。 容器应用与 Application Insights 和 Log Analytics 集成。 您使用此数据跟踪操作，并根据指标和事件设置警报，成为可观测系统中的一部分。

    性能监视可帮助你评估负载下的应用程序。 指标和日志提供数据来识别趋势、调查失败和执行根本原因分析。

  • 使用 健康检查和就绪探测 来处理启动缓慢的容器，并在它们准备好接收流量之前避免发送流量。 Kubernetes 实现包括这些终结点。 如果它们提供有效的信号，请继续使用它们。

  • 当服务意外终止时，容器应用会自动重启它。 已启用服务发现，以便工作流服务可以发现其下游微服务。 使用 复原策略 来处理超时并引入断路器逻辑，而无需进一步调整代码。

  • 启用自动缩放规则以满足流量和工作负载增加的需求。

  • 使用容器应用的动态负载均衡和缩放功能来提高可用性。 过度预配环境的子网，以便它始终有足够的 可用 IP 地址供将来的副本或作业使用。

  • 避免直接在容器应用环境中存储状态，因为副本关闭时所有状态都会丢失。 将状态外部化到每个微服务的专用状态存储。 此架构将状态分布到以下三个不同的存储中：Azure 托管 Redis、适用于 NoSQL 的 Azure Cosmos DB 和 Azure DocumentDB。

  • 使用多区域拓扑部署所有资源，包括容器应用。 有关详细信息，请参阅 容器应用中的可用性区域支持。

    将非临时应用程序的最低副本数设置为每个可用区至少一个副本。 在典型的操作条件下，副本会在区域内的可用区之间可靠地分布和均衡。

安全性

安全性提供针对故意攻击和滥用宝贵数据和系统的保证。 有关详细信息，请参阅 安全的设计评审清单。

机密

  • 容器应用可以将敏感值作为机密进行存储和检索。 为容器应用定义机密后，它可以被应用程序和任何相关的扩展规则使用。 如果以多修订模式运行，则所有修订共享相同的机密。 由于机密被视为应用程序范围更改，因此，如果更改机密的值，则不会创建新的修订。 但是，要让任何正在运行的版本加载新的密钥值，需要重启它们。 在此方案中，使用应用程序和环境变量值。

  • 重写服务代码以使用应用自己的托管标识对依赖项（而不是预共享机密）进行身份验证。 所有依赖项都具有支持托管标识身份验证的 SDK。

  • 可以在应用程序级别安全地将敏感值存储在环境变量中。 环境变量更改时，容器应用会创建新的修订。

网络安全性

  • 若要限制外部访问，仅为外部入口配置引入服务。 后端服务只能通过容器应用环境中的内部虚拟网络进行访问，并且配置为内部模式。 仅在需要时向 Internet 公开服务。

    由于此体系结构使用内置的外部入口功能，因此此解决方案不提供完全定位 WAF 后面的入口点或将其包含在 DDoS 防护计划中的能力。 使用 Web 应用程序防火墙保护所有面向网络的工作负载。 有关入口改进的详细信息，请参阅 实现入口控制。

  • 创建环境时，可以提供自定义虚拟网络。 否则，Microsoft自动生成和管理虚拟网络。 无法通过添加网络安全组（NSG）或强制将流量隧道发送到出口防火墙来操作此Microsoft托管的虚拟网络。 该示例使用自动生成的虚拟网络，但自定义虚拟网络可改进安全控制。 自定义网络允许通过 Azure 防火墙应用 NSGs 和用户定义路由（UDR）的路由。

有关网络拓扑选项的详细信息，包括对入口的专用终结点支持，请参阅 容器应用中的网络体系结构。

工作负载标识

  • 容器应用支持Microsoft Entra 托管标识，这些标识使应用能够向受 Microsoft Entra ID（如 Key Vault）保护的其他资源进行身份验证，而无需在容器应用中管理凭据。 容器应用可以使用系统分配的标识、用户分配的标识或两者。 对于不支持Microsoft Entra ID 身份验证的服务，请将机密存储在 Key Vault 中，并使用托管标识访问机密。

  • 使用一个用户指定的专用托管身份来访问容器注册中心。 容器应用支持使用不同于容器注册表访问的托管标识来操作工作负载。 此方法提供精细访问控制。 如果工作负荷具有多个容器应用环境，请不要跨实例共享标识。

  • 将系统分配的托管标识用于工作负荷标识，将标识生命周期绑定到工作负荷组件生命周期。

更多安全建议

  • 此工作负荷的 Kubernetes 实现通过使用 Microsoft Defender for Containers 的功能来提供保护。 在此体系结构中，Defender for Containers 仅 评估 容器注册表中容器的漏洞。 Defender for Containers 不提供容器应用的运行时保护。 如果需要运行时保护，请评估与非Microsoft安全解决方案的补充。

  • 不要在共享容器应用环境中运行工作负荷。 将其与不需要访问这些微服务的其他工作负荷或组件隔离开。 创建单独的容器应用环境。 在容器应用环境中运行的应用和作业可以发现并访问在启用了内部入口的环境中运行的任何服务。

成本优化

成本优化侧重于减少不必要的开支和提高运营效率的方法。 有关详细信息，请参阅 成本优化的设计评审清单。

  • 查看工作负荷的示例价格估算值。 使用 Azure 定价计算器。 配置会有所不同，因此请对其进行调整，使其与方案匹配。

  • 在此方案中，Azure Cosmos DB、Azure 托管 Redis 和服务总线高级版是主要成本驱动因素。

  • 对于通常 CPU 和内存消耗较少的容器，请首先评估其工作负荷特征。 根据您的使用情况估算消耗模型的成本，以帮助收集基础成本数据并对其他模型进行评估。 例如，可以为具有高度可预测且稳定的组件使用专用工作负荷配置文件，并且可以共享专用节点。 为了进行成本优化，请为每个专用配置文件维护三个节点的倍数，以确保在可用性区域中有足够的计算主机和副本分布。

  • 通过在非活动期间确保组件可缩放到零来消除计算成本，以便仅在需要时付费。 此方法可减少具有可变或不经常使用的应用的费用。 运行状况检查通常会阻止完全缩减到零。 在体系结构中，可以将工作流服务重新实现为任务式作业，以便在空闲期间利用“缩放到零”功能。 此方法与可以使用 消耗计划的工作负载很好地耦合。

  • 若要避免跨区域网络费用，请在同一区域中部署所有组件，例如状态存储和容器注册表。

卓越运营

卓越运营涵盖部署应用程序并使其在生产环境中运行的运营流程。 有关详细信息，请参阅 卓越运营的设计评审清单。

  • 使用 GitHub Actions 或 Azure Pipelines 集成设置自动化持续集成和持续部署（CI/CD）管道。

  • 将多修订模式与流量拆分配合使用，以测试对工作负荷代码和缩放规则的更改。

  • 与 Application Insights 和 Log Analytics 集成，以便深入了解工作负荷。 使用与工作负载其他组件相同的 Log Analytics 工作区，将所有工作负载的洞察集中在一起。

  • 使用基础设施即代码（IaC），例如 Bicep 或 Terraform，来管理所有基础设施部署。 部署包括容器应用环境、容器注册表和微服务状态存储。 将微服务部署管道与基础结构管道分开，因为它们通常不共享类似的生命周期。 Azure 基础结构的声明性管道应部署除容器应用资源之外的所有资源。

  • 使用命令性方法来创建、更新和删除环境中的容器应用。 如果要在修订之间动态调整流量转移逻辑，这一点尤其重要。 在部署工作流中使用 GitHub 操作 或 Azure Pipelines 任务。 此命令性方法可以基于 YAML 应用定义。 为了尽可能减少健康检查失败，请确保在部署容器应用程序之前，管道已用新的容器镜像更新容器镜像库。

    Kubernetes 实现的一个重要变化是管理 Kubernetes 清单文件（例如定义 Deployment Kubernetes 对象）的转变。 Kubernetes 通过此清单对象提供一种原子性的"一起成功"或"一起失败"的微服务部署方法。 在容器应用中，每个微服务都是独立部署的。 部署管道负责协调安全部署所需的任何排序和回滚策略。

性能效率

性能效率是指工作负荷能够高效地缩放以满足用户需求。 有关详细信息，请参阅 性能效率的设计评审清单。

  • 工作负载分布在多个微服务应用程序中。

  • 每个微服务都是独立的，与其他微服务没有共享任何状态，这可实现独立的缩放。

  • 将容器应用作业用于有限过程运行，以实现瞬态运行时，并降低空闲服务的资源消耗。 评估启动和停止任务与使组件保持活跃和待命状态的性能影响。

  • 启用自动缩放。 尽可能首选基于事件的缩放，而不是基于指标的缩放。 例如，如果设计支持，工作流服务可以根据服务总线队列深度进行扩展。 默认自动缩放程序基于 HTTP 请求。 在平台迁移期间，重要的是要从相同的扩展方法开始，然后再评估扩展优化。

  • 请求会动态负载均衡到修订版本的可用副本。

  • 指标（包括 CPU、内存、带宽信息和存储的利用率）可通过 Azure Monitor 获得。

部署此方案

遵循 容器应用示例场景存储库中 README.md 的步骤。

供稿人

Microsoft 会维护本文。 以下参与者撰写了本文。

贡献者：

后续步骤