Microsoft 已将 Azure Container Apps Express 与其底层的 Container Apps Sandboxes 一并推向正式可用。Express 的核心取舍很明确：省去 Container Apps 环境的预配置过程，借助预热资源池实现亚秒级启动，并支持缩容到零；代价则是部分平台能力暂不可用。
对于临时 API、事件处理器、预览环境和间歇性任务，这种模式能明显缩短“创建资源到收到首个请求”的路径。但它并不是现有 Container Apps 环境的无条件替代品，选型前需要认真核对功能边界。
Express 改变了哪一段部署流程
传统容器应用通常要先准备承载环境，再将工作负载部署进去。Express 跳过环境预配，让开发者更直接地提交容器镜像与运行参数。
它建立在 Container Apps Sandboxes 之上。Sandboxes 是一个基于 microVM 的计算层，用来运行容器工作负载。配合预热池，Express 可以在亚秒级启动实例，并在没有流量或任务时缩容到零。
这几项能力组合起来，适合处理以下类型的工作负载：
- 按需启动的轻量 HTTP API；
- 分支或 Pull Request 对应的短期预览环境；
- 流量低且不连续的内部工具；
- 可快速初始化的 webhook 接收器；
- 不需要常驻实例的原型与实验服务。
这里要区分两个时间指标：平台能够快速提供计算实例，不代表应用一定能快速就绪。如果容器启动时要下载模型、执行数据库迁移、扫描大量文件或建立多个外部连接，应用自身的初始化仍可能成为主要延迟。
亚秒级启动仍然需要“小而快”的镜像
预热池解决的是计算资源准备问题，开发者仍需控制镜像体积和进程启动路径。可以这样实践：让服务使用精简基础镜像，不在启动阶段安装依赖，并提供简单的健康检查端点。
下面是一个可以直接运行的零依赖 Python HTTP 服务。它监听 PORT 环境变量，并将日志写到标准输出，适合作为 Express 概念验证镜像。
mkdir aca-express-demo
cd aca-express-demo
cat > app.py <<'PY'
import json
import os
import time
from http.server import BaseHTTPRequestHandler, ThreadingHTTPServer
STARTED_AT = time.time()
PORT = int(os.getenv("PORT", "8080"))
class Handler(BaseHTTPRequestHandler):
def send_json(self, status, payload):
body = json.dumps(payload).encode("utf-8")
self.send_response(status)
self.send_header("Content-Type", "application/json")
self.send_header("Content-Length", str(len(body)))
self.end_headers()
self.wfile.write(body)
def do_GET(self):
if self.path == "/healthz":
self.send_json(200, {"status": "ok"})
return
self.send_json(200, {
"message": "hello from a container",
"uptime_ms": round((time.time() - STARTED_AT) * 1000)
})
def log_message(self, fmt, *args):
print(json.dumps({
"level": "info",
"client": self.client_address[0],
"message": fmt % args
}), flush=True)
server = ThreadingHTTPServer(("0.0.0.0", PORT), Handler)
print(json.dumps({"level": "info", "event": "started", "port": PORT}), flush=True)
server.serve_forever()
PY
cat > Dockerfile <<'DOCKER'
FROM python:3.12-slim
WORKDIR /app
COPY app.py /app/app.py
ENV PORT=8080
EXPOSE 8080
CMD ["python", "/app/app.py"]
DOCKER
docker build -t aca-express-demo:local .
docker run --rm -p 8080:8080 aca-express-demo:local
另开一个终端验证服务：
curl http://localhost:8080/
curl http://localhost:8080/healthz
部署到 Azure 前，需要把镜像推送到 Azure Container Registry 或其他可访问的镜像仓库，再在 Express 创建流程中填写镜像地址，并将入口目标端口设为 8080。不同时间点的 Azure CLI 或资源 API 参数可能发生变化，因此应以当前 Azure 门户或 CLI 帮助中暴露的 Express 资源类型为准，不要直接套用普通 Container Apps 环境的创建脚本。
如果需要构建适合云端运行架构的镜像，可以在登录目标镜像仓库后执行：
# 将 REGISTRY、REPOSITORY 和 TAG 替换为自己的值
export REGISTRY="example.azurecr.io"
export REPOSITORY="aca-express-demo"
export TAG="v1"
docker buildx build \
--platform linux/amd64 \
-t "$REGISTRY/$REPOSITORY:$TAG" \
--push .
功能边界决定它能不能进入生产
Express 当前不支持以下能力：
- 自定义域名；
- 可用区冗余；
- Azure Key Vault 引用；
- OpenTelemetry；
- Dapr。
这些限制并非简单的“以后再优化”。它们直接影响入口设计、密钥管理、可观测性、可靠性和服务间通信。
例如，面向公网的正式产品如果必须使用企业域名，就不能假设应用可以直接在 Express 上完成域名绑定。可以评估在前方增加已有网关或反向代理，但这会引入额外成本、延迟和运维责任。
缺少 Key Vault 引用时，也不应把长期密钥写进镜像、Dockerfile 或 Git 仓库。部署前要确认 Express 当前支持的安全配置注入方式是否满足组织要求；如果无法满足，就应选择功能更完整的 Container Apps 部署模式。
OpenTelemetry 不可用同样值得警惕。上面的示例使用结构化标准输出，只能作为基础日志方案，不能等同于完整的 trace、metric 和 log 关联。依赖分布式追踪排障的微服务系统，不适合在没有替代方案的情况下迁移。
Dapr 不受支持意味着现有应用如果使用其服务调用、状态存储、发布订阅或绑定能力，就需要自行替换这些集成，或者继续留在支持 Dapr 的运行环境中。
更适合从低依赖工作负载开始
评估 Express 时，可以按下面的清单做一次快速筛选：
- 应用是否可以容忍缩容到零后的冷启动；
- 镜像和进程能否在很短时间内完成初始化；
- 是否不需要直接绑定自定义域名；
- 是否不要求可用区冗余；
- 密钥能否通过符合安全规范的替代方式提供；
- 是否不依赖 Dapr；
- 标准日志或现有外围监控是否足够；
- 是否已经验证当前区域可用性、配额和计费方式。
稳妥的采用顺序是先部署无状态、低风险、可随时重建的服务，实际测量首请求延迟、扩缩容行为和故障恢复，再决定是否扩大范围。Express 的价值不是提供最多的平台功能，而是让一类轻量、突发式工作负载更快落地。只要功能缺口与业务要求对得上，这种更短的部署路径就很有吸引力。