1. Azure容器应用平台全景

在Azure上运行容器化应用，并不是只有一条路。Azure同时提供了四种主流承载方式：Azure Container Apps（ACA）、Azure Kubernetes Service（AKS）、Azure App Service（含Web App for Containers）以及Azure Container Instances（ACI）。它们都能运行容器镜像，但设计目标、抽象层级、运维责任和计费模型差异很大。选错平台，往往意味着要么过度工程化、成本失控，要么在业务增长时被迫推倒重来。因此，平台选型的第一步不是比较功能清单，而是先明确“谁负责管理什么”。

四种平台的本质定位

ACI是最轻量的容器运行方式，属于“单容器/单容器组”级别的托管服务。它没有编排层，不提供自动扩缩容、服务发现或滚动升级，适合一次性任务、批处理作业、CI/CD中的构建步骤，或需要快速验证镜像的场景。ACI按秒计费，用完即停，是典型的“任务型”载体。

App Service是PaaS层的Web应用托管平台。它支持直接部署代码，也支持以容器方式部署（Web App for Containers）。其核心价值在于内置了HTTP入口、TLS终止、自定义域名、部署槽位、自动缩放和身份集成。对于标准Web API、前后端分离的后端服务，App Service的抽象程度最高、上手最快，但它对容器编排能力、Sidecar模式、Dapr等微服务高级特性的支持有限。

ACA是Azure在2021年后主推的Serverless容器平台，构建在Kubernetes之上，但把集群、节点池、Ingress控制器、服务网格等基础设施全部隐藏。它提供基于KEDA的事件驱动自动缩放、内置Ingress、Dapr集成、修订版本管理和流量拆分。ACA的定位是“不需要管理Kubernetes，但需要微服务级容器能力”的场景。

AKS是完整的托管Kubernetes服务。它暴露Kubernetes API，允许用户自定义节点池、网络插件（CNI）、Ingress Controller、服务网格、Operator、GPU节点、Windows节点等。AKS适合需要精细控制调度策略、多租户隔离、复杂网络拓扑或已有Kubernetes生态投资的团队。代价是运维复杂度最高，需要理解Kubernetes的升级、节点维护、资源配额和成本分摊。

选型决策树：从业务约束出发

与其横向对比功能，不如按以下顺序提问：

1. 这个负载是长期运行的服务，还是一次性任务？ 如果是一次性任务或短生命周期作业，优先考虑ACI；如果是长期服务，进入下一步。
2. 是否需要Kubernetes原生API、自定义控制器或特殊调度？ 如果需要，选择AKS；如果不需要，进入下一步。
3. 是否是标准HTTP Web应用，且团队希望最少运维？ 如果是，App Service通常是成本最低、交付最快的选择；如果应用需要微服务拆分、事件驱动缩放或Dapr，进入下一步。
4. 是否需要容器级微服务能力，但不想管理Kubernetes？ 如果是，ACA是最佳匹配。

这个决策树的关键在于：AKS不是默认答案。很多团队因为“Kubernetes是行业标准”而直接选择AKS，结果把大量精力花在集群运维上，而业务本身并不需要Kubernetes的灵活性。反过来，如果业务确实需要多租户隔离、自定义CRD或GPU调度，ACA和App Service都无法替代AKS。

典型业务场景与参数示例

假设一个团队要部署一套订单处理系统，包含三个组件：一个对外REST API、一个订单事件消费者、一个每日对账批处理任务。按照上面的决策树：

• REST API：标准HTTP服务，无特殊Kubernetes需求，团队只有2名后端开发。选择App Service，使用P1v3实例（2核4GB），开启自动缩放，最小1实例、最大5实例，缩放阈值设为CPU 70%。部署槽位用于灰度发布。
• 订单事件消费者：从Azure Service Bus队列消费消息，需要根据队列深度动态伸缩。选择ACA，配置KEDA Service Bus缩放规则，最小副本0、最大副本20，消息阈值设为50。ACA在无消息时缩到0，成本显著低于常驻实例。
• 每日对账批处理：每天凌晨运行一次，处理约10万条记录，运行时间约8分钟。选择ACI，使用2核4GB容器，通过Logic App或Azure Function触发，任务完成后自动终止，按秒计费。

如果这个团队后续需要引入服务网格、自定义Operator或GPU推理节点，则应将消费者和API迁移到AKS。但在当前阶段，混合使用App Service、ACA和ACI，总运维负担远低于直接上AKS。

成本与运维的权衡

从成本角度看，ACI按秒计费，适合短任务；ACA支持缩到0，适合间歇性负载；App Service按实例小时计费，适合稳定流量；AKS除了节点VM费用外，还有负载均衡器、存储、网络出口以及最容易被低估的人力运维成本。一个3节点AKS集群，即使业务负载很轻，每月的固定成本也可能超过App Service的P1v3实例，而团队还需要投入时间处理Kubernetes版本升级、节点镜像更新和安全补丁。

从控制力角度看，AKS提供完整的Kubernetes API，可以精确控制Pod调度、资源配额、网络策略和存储类。ACA虽然底层也是Kubernetes，但用户无法访问API Server，只能通过ACA的资源模型（环境、应用、修订版本）来操作。App Service的控制粒度更粗，但换来了极低的运维门槛。ACI则几乎没有编排能力，只适合单容器或简单容器组。

选型检查清单

在实际项目中，可以用以下问题快速收敛选型：

这张表不是绝对规则，而是帮助团队在讨论时快速定位分歧点。例如，如果业务需要GPU推理但团队没有Kubernetes经验，可以考虑先用ACI运行单容器GPU任务，或者使用Azure Machine Learning的托管在线端点，而不是直接搭建AKS GPU节点池。

总结来说，Azure容器平台的选择不是“哪个更好”，而是“哪个更匹配当前约束”。ACI解决任务型容器，App Service解决标准Web应用，ACA解决免运维的微服务容器，AKS解决需要完整Kubernetes控制力的复杂场景。理解这四者的定位差异，是后续进行平台设计与规模化部署的基础。