📚 课程目录第2章 ACA核心架构与资源模型

2. ACA核心架构与资源模型

Azure 容器应用（Azure Container Apps，简称 ACA）的定位是“无服务器容器运行时”。要真正用好它，必须先理解它的资源模型：哪些对象是控制面的管理单元，哪些对象是数据面的运行实体，以及它们之间如何层层嵌套。ACA 的资源模型可以概括为一条清晰的层级链：环境（Environment）→ 容器应用（Container App）→ 修订版（Revision）→ 副本（Replica），而组件（Component）与绑定（Binding）则横向挂接在环境或应用之上，提供 Dapr、存储、密钥等能力。

理解这条链的关键，是区分控制面与数据面。控制面负责“声明与编排”：你通过 ARM/Bicep、CLI 或门户提交期望状态，平台据此创建环境、生成修订版、调度副本。数据面负责“实际承载流量”：副本是真正运行容器镜像的进程单元，请求最终落到某个副本的某个容器上。控制面的变更不会立即等于数据面的行为，二者之间通过修订版和副本的调度过程衔接。

环境：共享边界与隔离单元

环境是 ACA 最外层的资源容器，它决定了容器应用共享什么、隔离什么。一个环境内所有容器应用共享同一个虚拟网络（VNet）、同一个 Log Analytics 工作区、同一套 Dapr 组件定义。这意味着：环境是网络与可观测性的边界，也是成本与安全的分界。生产实践中通常按“业务域 + 环境阶段”划分，例如 env-pay-prod、env-pay-dev，而不是把所有应用塞进一个环境。

环境有两种网络模式：外部入口（External）和内部入口（Internal）。外部环境允许公网访问其 Ingress；内部环境只能通过 VNet 内部或对等网络访问，适合后端微服务。选择哪种模式，直接决定了后续 Ingress 的 FQDN 是否可被公网解析。

容器应用：声明式配置的载体

容器应用是开发者日常操作的核心对象。它声明了：使用哪个镜像、暴露哪个端口、Ingress 如何配置、缩放规则是什么、密钥如何注入、健康探针如何设置。容器应用本身不直接运行容器，它是一份“期望状态”的声明，平台据此生成修订版。

一个典型的容器应用配置包含以下关键字段：

properties:
  configuration:
    ingress:
      external: true
      targetPort: 8080
      transport: http
    secrets:
      - name: db-conn
        value: "Server=...;"
  template:
    containers:
      - name: api
        image: myacr.azurecr.io/order-api:1.4.2
        env:
          - name: DB_CONN
            secretRef: db-conn
        resources:
          cpu: 0.5
          memory: 1Gi
    scale:
      minReplicas: 1
      maxReplicas: 10
      rules:
        - name: http-rule
          http:
            metadata:
              concurrentRequests: "50"

注意 template 中的内容一旦提交，就会生成一个新的修订版。这是 ACA 与普通容器编排平台最大的差异之一：配置变更不是“原地修改”，而是“生成新版本”。

修订版：不可变的版本快照

修订版是容器应用在某一时刻的完整配置快照，一旦创建便不可修改。每次修改镜像、环境变量、缩放规则或资源限制，平台都会生成一个新修订版。修订版有两种模式：

单修订版模式（Single）：只有一个修订版处于激活状态，新版本上线即替换旧版本，适合简单应用。
多修订版模式（Multiple）：多个修订版可同时激活，通过流量权重分配实现灰度发布或 A/B 测试。

在多修订版模式下，你可以为每个修订版设置流量百分比。例如修订版 A 承担 90% 流量，修订版 B 承担 10%，观察 B 的错误率和延迟后再逐步切换。这种能力让 ACA 天然支持金丝雀发布，而不需要额外的服务网格。

副本：真正运行容器的实例

副本是数据面的最小运行单元。一个修订版可以拥有 0 到 N 个副本，具体数量由缩放规则决定。每个副本是一个独立的容器实例，拥有自己的内存空间、CPU 配额和临时存储。副本之间不共享内存，因此应用必须设计为无状态或通过外部存储共享状态。

缩放规则是副本数量的控制器。ACA 支持三种缩放触发器：HTTP 并发请求数、CPU/内存使用率、以及自定义事件（如 KEDA 支持的队列长度）。以 HTTP 并发为例，若设置 concurrentRequests: "50"，当单个副本同时处理 50 个请求时，平台会开始扩容。缩放到零（minReplicas: 0）是 ACA 的重要特性，意味着无流量时副本数归零，不产生计算费用，但冷启动会有延迟。

组件与绑定：横向能力接入

组件与绑定不是层级链的一部分，而是横向挂接的能力。Dapr 组件定义在环境级别，供所有容器应用引用；密钥可以定义在环境级别或应用级别；存储绑定通过 Azure Files 挂载到副本的指定路径。这些能力让容器应用不必在代码中硬编码连接字符串或存储 SDK，而是通过声明式绑定接入。

副本是计费单元。理解“修订版决定配置、副本决定成本”这一分工，是设计 ACA 应用时控制成本与性能平衡的基础。

控制面与数据面的协作过程

当你提交一次配置变更时，实际发生的过程是：控制面接收期望状态 → 校验并生成新修订版 → 调度器根据缩放规则创建或销毁副本 → Ingress 根据流量权重将请求路由到对应修订版的副本。整个过程是异步的，因此变更提交后需要观察修订版状态和副本数量是否达到预期。

判断变更是否生效，可以关注三个信号：修订版是否处于 Provisioned 状态、副本数是否达到 minReplicas、以及 Ingress FQDN 是否返回预期响应。如果修订版长时间处于 Provisioning，通常意味着镜像拉取失败或资源配额不足。

掌握环境、容器应用、修订版、副本这条层级链，以及组件与绑定的横向关系，就掌握了 ACA 资源模型的全貌。后续的缩放策略、流量拆分、密钥管理和可观测性配置，都是在这套模型上展开的。