此示例方案显示了一个现有工作负载的示例，该工作负载最初设计为在 Kubernetes 上运行，而现在可在 Azure 容器应用中运行。 Azure 容器应用非常适合棕地 (brownfield) 工作负载；在这类工作负载中，团队希望简化复杂的基础结构和容器业务流程。 示例工作负载运行容器化微服务应用程序。
该示例采用 Azure Kubernetes 服务上的微服务体系结构中使用的工作负载，并将其重新托管在 Azure 容器应用中作为其应用程序平台。
提示
该体系结构由示例实现提供支持，该示例实现描述了本文中所述的一些设计选项。
体系结构
下载此体系结构的 Visio 文件。
在此方案中，容器映像源自 Azure 容器注册表并部署到容器应用环境。
共享同一环境的服务受益于：
- 内部入口和服务发现
- 用于运行时日志记录的单个 Log Analytics 工作区
- 安全管理机密和证书
工作流服务容器应用在单一修订模式下运行。 在单一修订模式下运行的容器应用将具有由零到多个副本支持的单一修订。 副本由应用程序容器和任何必需的挎斗容器组成。 此示例不使用挎斗容器，因此每个容器应用副本都表示单个容器。 由于此示例不使用缩放，因此每个容器应用只运行一个副本。
工作流使用混合方法来管理机密。 托管标识用于此类实现所需的服务中，无需更改代码。 无人机计划程序和交付服务使用用户分配的托管标识通过 Azure 密钥保管库进行身份验证，以便访问存储在那里的机密。 其余服务通过应用程序级别的容器应用服务来存储机密。
此图演示了解决方案的运行时体系结构。
下载此体系结构的 Visio 文件。
数据流
- 引入服务：接收客户端请求、缓冲这些请求，并通过 Azure 服务总线将其发送到工作流服务。
- 工作流服务：使用来自 Azure 服务总线的消息并将其调度到基础服务。
- 包服务：管理包。
- 无人机计划程序服务：安排无人机并监视无人机飞行。
- 配送服务：管理已计划或在途的配送。
组件
无人机配送服务使用一系列相互协作的 Azure 服务。
Azure Container Apps
Azure 容器应用是主要组件。
以下功能消除了以前的 AKS 体系结构的许多复杂性：
- 内置服务发现
- 完全托管的 HTTP 和 HTTP/2 终结点
- 集成负载均衡
- 日志记录和监视
- 基于 KEDA 支持的 HTTP 流量或事件进行自动缩放
- 应用程序升级和版本控制
外部存储和其他组件
Azure 密钥保管库服务，用于安全地存储和访问机密，例如 API 密钥、密码和证书。
Azure 容器注册表存储专用容器映像。 也可以使用其他容器注册表，例如 Docker Hub。
Azure Cosmos DB 使用开源的 Azure Cosmos DB for MongoDB 存储数据。 微服务通常是无状态的，它们将自身的状态写入外部数据存储。 Azure Cosmos DB 是一个 NoSQL 数据库，具有适用于 MongoDB 和 Cassandra 的开源 API。
Azure 服务总线提供可靠的云消息传递即服务和简单的混合集成。 服务总线支持微服务应用程序中常用的异步消息传递模式。
Azure Cache for Redis 在应用程序体系结构中添加一个缓存层，以提高繁重流量负载的速度和性能。
Azure Monitor 从应用程序收集指标和日志并将其进行存储。 使用此数据可以监视应用程序、设置警报和仪表板，以及针对故障执行根本原因分析。 此方案使用 Log Analytics 工作区对基础结构和应用程序进行全面监视。
Application Insights 为服务提供可扩展的应用程序性能管理 (APM) 和监视。 每个服务都使用 Application Insights SDK 进行检测，以监视应用并将数据定向到 Azure Monitor。
用于配置和部署应用程序的 Bicep 模板。
备选方法
此示例的替代方案是使用 Kubernetes 的 Fabrikam 无人机配送应用程序，该应用程序在 GitHub 上的 Azure Kubernetes 服务 (AKS) Fabrikam 无人机配送存储库中提供。
方案详细信息
企业可以使用 Azure 容器应用简化微服务容器的部署和管理。 容器应用提供完全托管的无服务器环境，用于生成和部署新式应用程序。
Fabrikam, Inc.（一家虚构的公司）实现了无人机配送应用程序，用户可通过该应用请求无人机取货进行配送。 当客户安排取件时，后端系统会分配一架无人机，并将估计的交付时间告知用户。
微服务应用程序已部署到 Azure Kubernetes 服务 (AKS) 群集。 不过，Fabrikam 团队没有利用高级或特定于平台的 AKS 功能。 他们最终在没有产生太多开销的情况下将应用程序迁移到了 Azure 容器应用。 通过将解决方案移植到 Azure 容器应用，Fabrikam 能够：
- 按近乎原样迁移应用程序：将应用程序从 AKS 移动到 Azure 容器应用时，只需进行非常少量的代码更改。
- 使用 Bicep 模板部署基础结构和工作负载：部署其应用程序容器不需要 Kubernetes YAML 清单。
- 通过托管入口公开应用程序：内置支持基于 https 的外部入口来公开引入服务，无需配置自己的入口。
- 从 ACR 拉取容器映像：Azure 容器应用不需要特定的基础映像或注册表。
- 管理应用程序生命周期：修订功能支持运行特定容器应用的多个修订，并在这些修订之间拆分流量，来进行 A/B 测试或实现蓝/绿部署方案。
- 使用托管标识：Fabrikam 团队能够使用托管标识向 Azure Key Vault 和 Azure 容器注册表进行身份验证。
可能的用例
- 将基于微服务的棕色地带应用程序部署到平台即服务 (PaaS) 产品/服务中，以避免管理容器业务流程协调程序的操作复杂性。
- 通过将容器化服务迁移到支持本机缩放到零的平台来优化运营和管理。
- 执行长时间运行的后台进程，例如单一修订模式下的工作流服务。
容器应用的其他常见用途包括：
- 在基于消耗的无服务器平台上运行容器化工作负载。
- 基于 KEDA 支持的 HTTP/HTTPS 流量和/或事件驱动的触发器自动缩放应用程序
- 最大限度地减少容器化应用程序的维护开销
- 部署 API 终结点
- 承载后台处理应用程序
- 处理事件驱动的处理
注意事项
这些注意事项实施 Azure 架构良好的框架的支柱原则，即一套可用于改善工作负载质量的指导原则。 有关详细信息，请参阅 Microsoft Azure 架构良好的框架。
可用性
通过容器应用，可以更轻松地部署、管理、维护和监视应用程序。 可通过以下关键功能确保可用性：
- 修订有助于在零停机的情况下部署应用程序更新。 可以使用修订来管理应用程序更新的部署，并在修订之间拆分流量，以支持蓝/绿部署和 A/B 测试（当前未在此示例工作负荷中使用）。
- 使用容器应用端到端可观测性功能，可以全面了解正在运行的应用程序。 容器应用与 Azure Monitor 和 Log Analytics 集成，可用于跟踪容器应用执行，并根据指标和事件设置警报。
- 当应用意外终止时，容器应用服务会自动重启它。
- 可以启用自动缩放规则，以满足流量和工作负载增加时的需求。
- 容器应用的动态负载均衡功能优化了性能（此示例工作负载中当前未使用）。
卓越运营
卓越运营涵盖了部署应用程序并使其在生产环境中保持运行的运营流程。 有关详细信息，请参阅卓越运营支柱概述。
为了实现卓越运营，容器应用服务提供以下功能：
- GitHub Actions 集成，用于设置自动化 CI/CD 部署。
- 具有流量拆分的多修订模式，用于测试对应用程序代码和缩放规则的更改。
- 与 Azure Monitor 和 Log Analytics 集成，提供对容器化应用程序的见解。
性能效率
性能效率是指工作负载能够以高效的方式扩展以满足用户对它的需求。 有关详细信息，请参阅性能效率要素概述。
此解决方案中的性能注意事项：
- 工作负载分布在多个微服务应用程序中。
- 每个微服务都是独立的，不与其他微服务共享任何内容，因此它们可以独立缩放。
- 随着工作负载的增加，可以启用自动缩放。
- 请求是动态均衡负载的。
- 指标（包括 CPU 和内存利用率、带宽信息和存储利用率）可通过 Azure Monitor 获得。
- Log Analytics 提供日志聚合，用于跨每个容器应用环境收集信息。
可靠性
可靠性可确保应用程序符合你对客户的承诺。 有关详细信息，请参阅可靠性支柱概述。
容器应用将尝试重启失败的容器，并对用户隐藏硬件。 暂时性故障和备份计算资源的高可用性由 Microsoft 处理。
通过 Log Analytics 和 Azure Monitor 进行性能监视，可以评估负载下的应用程序。 指标和日志记录信息提供识别趋势所需的数据，以防止故障，并在故障发生时执行根本原因分析。
安全性
安全性针对蓄意攻击及滥用宝贵数据和系统提供保障措施。 有关详细信息，请参阅安全性支柱概述。
机密
- 容器应用可以将敏感值作为机密进行存储和检索。 为容器应用定义机密后，该应用程序和任何关联的缩放规则都可以使用它。 如果在多修订模式下运行，则所有修订将共享相同的机密。 由于机密被视为应用程序范围的更改，因此如果更改机密的值，不会创建新的修订。 但是，对于要加载新机密值的任何正在运行的修订，都需要重启它们。 在此方案中，使用应用程序和环境变量值。
- 环境变量：敏感值可以安全地存储在应用程序级别。 更改环境变量后，容器应用将生成新的修订。
网络安全
- 入口：为了限制外部访问，仅为外部入口配置引入服务。 只能通过容器应用环境中的内部虚拟网络来访问后端服务。 仅在需要时向 Internet 公开服务。 由于此体系结构使用内置的外部入口功能，因此此解决方案无法完全将入口点置于 Web 应用程序防火墙 (WAF) 后面或将其包含在 DDoS 防护计划中。 所有面向 Web 的工作负载都应置于 Web 应用程序防火墙之后。
- 虚拟网络：创建环境时，可提供自定义虚拟网络；否则，虚拟网络由 Microsoft 自动生成和管理。 你无法操作这个由 Microsoft 管理的虚拟网络，例如通过将网络安全组 (NSG) 或强制隧道流量发送到出口防火墙进行操作。 此示例使用自动生成的虚拟网络。
有关更多网络拓扑选项，请参阅 Azure 容器应用中的网络体系结构。
工作负载标识
- 容器应用支持 Microsoft Entra 托管的标识，应用可通过这些标识向其他受 Microsoft Entra ID 保护的资源（例如 Azure Key Vault）验证其自身，而无需在容器应用中管理凭据。 容器应用可以使用系统分配的托管标识、用户分配的托管标识，或同时使用两者。 对于不支持 AD 身份验证的服务，应在 Azure Key Vault 中存储机密，并使用托管标识来访问机密。
- 使用托管标识进行 Azure 容器注册表访问。 Azure 容器应用支持对工作负载使用与容器注册表访问不同的托管标识，建议在对托管标识实现精细访问控制时这样做。
成本优化
- “Microsoft Azure 架构良好的框架”中的“成本”部分描述了成本注意事项。 使用 Azure 定价计算器估算特定方案的成本。
- Azure 容器应用具有基于消耗的定价模型。
- Azure 容器应用支持缩放到零。 当容器应用缩放到零时，无需支付任何费用。
- 在此方案中，Azure Cosmos DB 和 Azure Cache for Redis 是主要的成本驱动因素。
部署此方案
请按照 Azure 容器应用示例方案存储库中的 README.md 中的步骤部署此方案。
作者
本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。
主要作者：
- Catherine Bundy | 技术作家