2017年，Azure Container Instances（容器实例，以下简称ACI）上线时，微软打出的口号是"2秒启动一个容器"。8年过去了，这个服务依然活在Kubernetes和Container Apps的阴影里——但有个数据很有意思：ACI的活跃用户中，超过40%是在凌晨0点到6点之间创建实例的。这些人不是夜猫子，是被突发任务逼到墙角的人。
那个周四晚上的£0.14账单
一位.NET开发者分享了他的经历。周四晚上11点，客户要求连夜完成一次数据迁移——从遗留SQL Server到Azure SQL。他的控制台应用需要16GB内存才能全量处理数据，笔记本跑不动，虚拟机配置要20分钟，现有的App Service规格又不够。
ACI的解决方案是：把应用打包成Docker镜像，推送到Azure容器注册表（ACR），两分钟后拿到一个16GB内存的运行实例。迁移完成，删除容器，账单£0.14。
这个场景暴露了ACI的核心定位：不是替代你的长期服务，而是填补"临时、突发、一次性"的算力缺口。按秒计费，没有预留实例的包袱，也没有Kubernetes集群的管理开销。
但问题在于，很多人把ACI当成了便宜版的虚拟机，或者简单版的容器编排平台。这两种用法都会让你付出代价——要么是性能瓶颈，要么是账单惊吓。
ACI的真正主场：三类任务
从实际案例来看，ACI适合的任务有清晰的边界。
第一类是事件驱动的批处理。比如每月一次的财务对账、季度性的数据清洗、或者CI/CD流水线中的构建任务。这些任务需要一定资源，但运行时间确定，不需要7×24小时待命。ACI的按秒计费在这里是绝杀——传统虚拟机哪怕只跑10分钟，也要为整小时的预留付费。
第二类是突发扩容的泄压阀。你的主服务跑在App Service或Container Apps上，突然遇到流量 spike。与其升级整个服务计划，不如把部分负载丢给ACI处理。微软官方文档里有个案例：某电商平台在大促期间，用ACI承接了30%的订单验证任务，峰值过去后立即释放，成本比扩容主集群低67%。
第三类是"胶水代码"的临时托管。两个系统需要对接，但中间逻辑不值得长期维护一个服务。比如把旧系统的Webhook数据格式转换成新系统能接受的结构，跑几周就下线。ACI的"用完即走"特性，让这种临时方案不会变成技术债务。
什么时候ACI会让你踩坑
ACI的架构限制很硬，不是"暂时不支持"，而是产品设计上的取舍。
最大的一块短板是网络。ACI实例默认没有固定的公网IP，也不支持负载均衡。如果你需要多个实例分担流量、或者要求稳定的出站IP做白名单，ACI会直接退出竞争。2023年微软给ACI加了VNet集成，但配置复杂度直线上升，失去了"即开即用"的初心。
持久化存储也是弱项。ACI支持挂载Azure文件存储（File Storage），但IOPS性能有限，不适合数据库类负载。有开发者试过在ACI里跑PostgreSQL做临时分析，结果查询一复杂就卡死——文件存储的延迟在10-20毫秒级别，本地SSD是百微秒级，差距是数量级的。
最隐蔽的坑是冷启动时间。官方说的"2秒"是指容器镜像已经在ACR里的情况。如果你的镜像没做优化，或者需要从Docker Hub拉取，启动时间可能飙到30秒以上。对于需要快速响应的事件驱动场景，这个延迟是致命的。
和Azure其他计算选项的残酷对比
微软自己在文档里列了张表，但藏得很深。我把关键差异摊开说。
ACI vs App Service：后者更适合长期运行的Web应用，有内置的自动缩放、SSL终止、部署槽位。但如果你只是跑一个定时任务，App Service的"始终开启"设置会让你为空闲时间买单。一个每天只跑2小时的任务，在ACI上的成本大约是App Service的1/8。
ACI vs Container Apps：这是最容易混淆的一对。Container Apps支持KEDA（基于事件驱动的自动缩放）、Dapr（分布式应用运行时）、以及多修订版本管理。简单说，如果你需要"微服务"级别的编排能力，Container Apps是底线。ACI的定位比它更低层——只是一个容器，没有服务发现，没有流量分割。
ACI vs Azure Functions：Functions的冷启动更快（特别是Premium计划），但运行时长限制在10分钟（Consumption计划）或无限制（Premium）。ACI没有执行时长上限，适合需要跑几小时的大任务。但Functions的计费粒度更细，128MB内存的函数跑1秒，账单可能是ACI同规格的几十分之一。
一个粗糙的判断标准：如果你的任务需要运行超过15分钟、或者内存需求超过1.5GB、或者需要自定义容器环境，ACI比Functions便宜；如果需要服务间调用、自动缩放策略、或者蓝绿部署，Container Apps是起点。
一个被忽视的细节：ACI的"休眠"陷阱
2022年，微软给ACI加了个"容器组重用"功能，本意是减少重复创建的开销。但有个副作用：如果你依赖容器启动时的初始化逻辑（比如从Key Vault拉取配置），重用机制会跳过这些步骤。有开发者在生产环境踩过这个坑——配置更新了，但ACI实例还在用缓存的旧值，导致静默错误。
解决方法是显式设置重启策略为"Never"，强制每次任务都创建新实例。但这又拉高了启动时间。微软的文档直到2023年底才补充这个注意事项。
另一个细节是地域定价。ACI在北欧区域的单价大约是美国东部的1.3倍，但很多人默认选离办公室最近的区域。对于一次性任务，跨区域部署到便宜区域，网络延迟的影响往往可以忽略——但账单差异可能达到40%。
那个周四晚上用ACI救火的开发者，后来把经验写进了团队的运维手册。他加了一条备注："ACI不是基础设施，是消防器材。平时放在那里没人注意，真着火的时候，2分钟和20分钟的差距，决定你是英雄还是背锅的。"
你的团队上次凌晨被突发任务叫醒，是多久之前？当时用的什么方案，账单多少？
热门跟贴