2026 年 Node.js SaaS 应用最佳无服务器容器平台
对许多 Node.js SaaS 团队来说,传统 PaaS 与 Kubernetes 之间存在很大空白。
你可能想要 Docker/OCI 可移植性、自动 HTTPS、自动扩缩容、私有网络、托管身份、修订版本、作业、日志以及缩容至零的经济性,但你可能不想运维 Kubernetes 控制平面、节点组、入口控制器、CNI 插件、集群升级、Helm Chart 或集群自动伸缩器。
这个空白正是无服务器容器平台发挥作用的地方。
对于 2026 年的 Node.js SaaS,值得评估的最强选项是:
- Google Cloud Run
- Azure Container Apps
- Amazon ECS Express Mode
- DigitalOcean App Platform
- Koyeb
2026 年还有一个重要的 AWS 变化:App Runner 不应再作为新客户默认选择。 AWS 已将 App Runner 转为维护模式,并在 2026 年 4 月 30 日后停止接受新客户。现有服务仍可运行,但 AWS 建议将 Amazon ECS Express Mode 用于新的容器化 Web 应用和 API。
快速建议
当你想要最纯粹的无服务器容器模型时,选择 Google Cloud Run:缩容至零、高可配置并发、服务、作业、worker 池、强大的 Node.js 指导、修订版本以及深度 GCP 集成。
当 Azure 是你的标准环境、基于 KEDA 的事件扩缩很重要,或者你想要 Consumption 和 Dedicated 工作负载配置文件以及修订版本流量拆分而不运行 AKS 时,选择 Azure Container Apps。
当 AWS 是你的主要云平台,并且你想要简化的 ECS/Fargate 部署同时保持底层 AWS 资源完全可见和可自定义时,选择 Amazon ECS Express Mode。
当你想要可预测的容器定价、更简单的运营、Git/容器部署、托管数据服务以及更小的云覆盖范围时,选择 DigitalOcean App Platform。基于请求的自动扩缩于 2026 年 5 月正式发布。
当全球轻量计算、按秒计费、自动扩缩和缩容至零很重要且不想采用 Kubernetes 时,选择 Koyeb。
2026 年比较
| 平台 | 最适合 | 缩容至零 | 价格信号 | 核心优势 |
|---|---|---|---|---|
| Google Cloud Run | 纯无服务器容器体验 | 支持 | 请求/实例 CPU+RAM,含每月免费额度 | 强并发能力、修订版本、作业、成熟的无服务器体验 |
| Azure Container Apps | Azure 原生 + 事件驱动工作负载 | Consumption 支持 | vCPU 秒 + GiB 秒 + 请求;也可用 Dedicated | KEDA 扩缩、修订版本、托管身份 |
| Amazon ECS Express Mode | AWS 原生容器托管 | 不是同一种纯请求驱动零模型 | 无 Express 费用;按 Fargate + ALB + CloudWatch + 传输计费 | ECS 灵活性,免去初始 ECS 样板 |
| DigitalOcean App Platform | 可预测的中小企业/初创托管 | 符合条件的服务支持 | 容器每月 $5 起 | 简单定价、请求自动扩缩、一体化平台 |
| Koyeb | 全球轻量无服务器计算 | 支持,公开预览 | 按秒实例 | 小实例、全球覆盖、缩容至零 |
1. Google Cloud Run
Cloud Run 仍然是“把容器交给云,不要让我运维服务器”这一理念最干净的实现。
典型的 Node.js SaaS 路径是:
Artifact Registry -> Cloud Run service -> HTTPS + IAM + autoscaling + revisions -> Cloud SQL / Memorystore / Pub/Sub / Storage
当前基于请求的每月免费额度按 us-central1 价格计算,包括 180,000 vCPU 秒、360,000 GiB 秒和 200 万次请求。基于实例的计费免费额度为 240,000 vCPU 秒和 450,000 GiB 秒。
Cloud Run 目前支持每个实例最高 1,000 个并发请求。这对 Node.js 尤其重要,因为 I/O 密集型 API 常常可以在等待 PostgreSQL、Redis、支付 API 和其他网络依赖期间同时处理大量并发请求。
不要盲目地将并发设置为最大值。正确的数值是仍能满足延迟、内存、事件循环延迟、数据库连接和下游限流 SLO 的最高值。
Google 当前的 Node.js 优化指南建议尽可能直接用 node 启动进程,而不是使用 npm start,以减少启动开销:
CMD ["node", "dist/server.js"]
对于延迟敏感的端点,配置最小实例数;对于低价值或间歇性端点,允许缩容到零。
2026 年 8 月 27 日,Google 推出了 Cloud Run instances,用于不适合常规请求驱动服务模型的长期运行工作负载。结合服务、作业、worker 池和 GPU 支持,这表明 Cloud Run 正在扩展为更广泛的托管容器执行层。
最适合: GCP 上无需 Kubernetes 的无状态 Node.js API、webhook、worker 和作业。
2. Azure Container Apps
Azure Container Apps 尤其适合事件驱动的 Node.js 工作负载,因为它的自动扩缩围绕 KEDA 概念构建。
HTTP -> Node.js API Container App
Service Bus / event source -> KEDA -> Node.js worker replicas
Consumption 计划目前每个订阅每月包含以下免费额度:
- 180,000 vCPU 秒
- 360,000 GiB 秒
- 200 万次 HTTP 请求
当符合条件的应用缩容到零时,不会产生资源消耗费用。
Container Apps 也可以保持最小副本存活。当副本满足文档规定的空闲条件时,Azure 可以按降低后的空闲费率而非活跃费率计费。
当前扩缩限制允许一个修订版本最少使用 0 个副本,最多使用 1,000 个副本。规则可以是 HTTP、TCP 或自定义 KEDA 规则。
修订版本是不可变快照。在多修订版本模式下,你可以拆分流量,例如:
v1 -> 90%
v2 -> 10%
然后观察指标,再增加 v2 的流量或回滚。
Azure 还支持 专用工作负载配置文件,适用于需要单租户特性、专用硬件或可预测分配容量的工作负载。
最适合: Azure 原生 SaaS、Service Bus/Event Hubs worker、事件驱动处理,或需要修订版本流量控制而不使用 AKS 的团队。
3. Amazon ECS Express Mode
AWS 的无服务器容器推荐在 2026 年发生了实质性变化。
App Runner 已进入维护模式。对于新的 Web/API 容器工作负载,AWS 现在推荐 Amazon ECS Express Mode。
使用 ECS Express Mode 时,你提供容器镜像以及所需 IAM 角色。Express Mode 会编排基于 Fargate 的 ECS 服务、HTTPS 端点、负载均衡、网络、自动扩缩和监控。
一个主要差异点是透明性:这些资源保留在你的 AWS 账户中,并可直接访问。这让你拥有简单的起点,同时不会把 ECS、Fargate、ALB、IAM、CloudWatch 及相关基础设施隐藏在封闭的 PaaS 抽象之后。
Express Mode 可以在网络配置允许的情况下,自动将最多 25 个服务整合到一个 Application Load Balancer 后面,减少“一个小服务一个 ALB”的成本问题。
目前没有额外的 Express Mode 费用。你需要为运行应用所创建的资源付费,包括:
- Fargate 计算
- Application Load Balancer
- CloudWatch 日志和指标
- 数据传输
- 附加的 AWS 服务
2026 年 7 月 1 日,AWS 为 ECS Express Mode 增加了自定义任务定义支持。这允许进行高级任务级配置,例如可观测性/安全 sidecar、自定义健康检查、ulimit、Linux 运行时设置和 FireLens 日志路由,同时保留 Express Mode 简化的部署流程。
不要假设 ECS Express Mode 具有与 Cloud Run 相同的零空闲成本优势。它的主要价值是AWS 原生简洁性加上 ECS 灵活性,而不一定是极少使用端点的最低成本。
最适合: 已在使用 RDS/Aurora、ElastiCache、SQS、EventBridge、S3、KMS、IAM 和 CloudWatch 的 AWS SaaS。
2026 年的 App Runner
AWS 已正式宣布 App Runner 将在 2026 年 4 月 30 日后停止接受新客户。现有 App Runner 服务会继续运行并获得安全/可用性支持,但 AWS 表示没有新功能计划。
现有客户不必仅仅因为维护状态而紧急迁移。新应用应改而评估 ECS Express Mode。
4. DigitalOcean App Platform
DigitalOcean App Platform 比 Cloud Run 更像 PaaS,但当可预测的月度成本比超大规模云厂商的计费复杂性更值得优先考虑时,它很有吸引力。
当前共享 CPU 容器定价如下:
| 计划 | 价格 |
|---|---|
| 1 vCPU / 512 MiB | 每月 $5 |
| 1 vCPU / 1 GiB 固定 | 每月 $10 |
| 1 vCPU / 1 GiB 可扩缩 | 每月 $12 |
| 1 vCPU / 2 GiB | 每月 $25 |
| 2 vCPU / 4 GiB | 每月 $50 |
专用 CPU 计划目前从每月 $29 开始。超出包含额度的额外出站带宽按 $0.02/GiB 计费。
2026 年一个重要改进是基于请求的自动扩缩,已于 5 月 20 日正式发布。服务可以根据 HTTP 指标扩缩,例如:
- 每秒请求数
- p95 请求时长
基于请求的自动扩缩适用于共享和专用 CPU 计划。基于 CPU 的自动扩缩仍适用于合适的计划。
这对 Node.js 很重要,因为对于 I/O 密集型 API,请求压力通常比平均 CPU 是更好的信号。
App Platform 支持从源代码或预构建容器构建、托管健康检查、worker、作业、日志转发、最近修订版本回滚以及托管数据库集成。
最适合: 希望获得可预测定价和紧凑云平台,而不是数十种基础设施原语的中小型 SaaS 团队。
5. Koyeb
Koyeb 将容器部署与按秒基础设施计费和全球部署位置相结合。
当前 Standard CPU 价格包括:
| 实例 | 规格 | 价格 |
|---|---|---|
| Nano | 0.25 vCPU / 256 MB | 每小时 $0.0036 |
| Micro | 0.5 vCPU / 512 MB | 每小时 $0.0072 |
| Small | 1 vCPU / 1 GB | 每小时 $0.0144 |
| Medium | 2 vCPU / 2 GB | 每小时 $0.0288 |
| Large | 4 vCPU / 4 GB | 每小时 $0.0576 |
当前 Pro 平台计划为每月 $29,含 $10 的计算额度。Scale 计划为每月 $299,含 $100 计算额度和 99.9% SLA。
Koyeb 的 Scale-to-Zero 功能目前处于公开预览阶段。受支持的标准 CPU/GPU 服务可以使用 min instances = 0。默认空闲时间为 5 分钟;付费计划可配置更长的空闲时间。
Koyeb 可以根据多个因素自动扩缩,包括 CPU、内存和请求速率。配置多个规则时,它会选择所需的最大实例数,以避免容量不足。
最适合: 全球分布的轻量 API,以及希望获得按秒基础设施经济性而不需要 Kubernetes 控制平面的团队。
Node.js 架构规则
调整并发
Node.js 是一种 I/O 并发运行时。一个请求可能大部分时间都在等待 PostgreSQL、Redis、对象存储或外部 API。
更高的单实例并发可以显著减少容器数量,但每个并发请求也会消耗内存、套接字、数据库池容量和下游配额。
在选择生产并发值之前,对 CPU、RSS/堆、事件循环延迟、p95/p99 延迟、数据库等待时间和错误率进行负载测试。
保护数据库
无服务器计算可能比 PostgreSQL 连接扩容得更快。
100 instances x pool max 10 = 1,000 possible DB connections
使用有边界的本地连接池,并在需要时使用外部事务池/代理,例如 RDS Proxy、PgBouncer/Supavisor、Prisma Accelerate 或其他托管连接池。
将状态放在容器之外
把容器文件系统和进程内存视为临时的。
将持久状态存储在:
- PostgreSQL/MySQL
- Redis/Valkey
- 队列
- 对象存储
不要将上传文件的唯一副本保存在 /tmp 中,也不要把共享登录会话保存在进程内 Map 中。
处理优雅关闭
无服务器实例会在缩容、部署和维护期间终止。Node.js 必须正确排空。
process.on("SIGTERM", async () => {
server.close();
await worker?.stop();
await dbPool.end();
await telemetry.flush();
process.exit(0);
});
在接受新工作之前停止宣告就绪状态,然后在平台的终止窗口内排空现有工作。
使用工作负载身份
优先使用短期云身份,而不是环境变量中的静态凭据:
container identity -> short-lived token -> database/queue/storage/secrets
视情况使用 Google 服务身份、Azure 托管身份或 AWS 任务角色。
使用不可变部署标识
不要只部署 latest。
使用镜像摘要或不可变版本标签,并保留修订版本以便回滚。
冷启动优化
冷启动延迟大致为:
image pull + sandbox/container start + Node.js startup + module loading + app initialization + first dependency connection
使用多阶段构建、更小的运行时镜像、直接 node 启动、在安全时进行延迟初始化,以及按需建立数据库连接。
不要在 HTTP 服务器就绪之前加载大型可选数据集或创建最大规模的连接池。
成本模型
当利用率波动时,无服务器容器最具吸引力。
对于持续 24/7 且 CPU 利用率始终较高的工作负载,固定/预留容器或 VM 容量可能更便宜。
对以下所有项建模:
- 活动 CPU 和内存
- 最小/空闲容量
- 请求
- 负载均衡器
- 私有网络/NAT
- 出站流量
- 日志/指标
- 数据库和缓存
由于缩容至零和每月免费额度,Cloud Run 和 Azure Container Apps 对间歇性服务的计算成本可以非常低。
ECS Express Mode 没有 Express 附加费,但应把 Fargate + ALB + CloudWatch 放在一起建模。
DigitalOcean 提供了更简单的固定月度容器模型。
Koyeb 按秒计费实例时间,并可通过缩容至零减少有效运行时间。
何时迁移到 Kubernetes
不要仅仅因为流量高就迁移。托管无服务器容器平台可以承载相当大的流量。
只有当你真正需要以下控制能力时才迁移:
- 自定义调度
- 服务网格
- 复杂网络策略
- 控制器/Operator
- DaemonSet
- 特殊持久化存储
- 高级节点/GPU 放置
- 跨多个团队/云的统一 Kubernetes 平台
如果问题只是成本或延迟,请在接管集群之前调优无服务器服务。
最终建议
对于 2026 年的 Node.js SaaS:
- Google Cloud Run 是最强的通用无服务器容器默认选择。
- Azure Container Apps 是最强的 Azure/事件驱动选项。
- Amazon ECS Express Mode 现在是 AWS 简化容器部署评估的默认选择,并在新的架构决策中取代 App Runner。
- DigitalOcean App Platform 非常适合可预测定价和更简单的运营。
- Koyeb 在全球轻量计算、按秒计费和缩容至零方面很有吸引力。
架构规则很简单:
当你希望容器作为应用边界,但不希望集群作为运营边界时,使用无服务器容器。
保持服务无状态、调整 Node.js 并发、限制数据库连接、使用工作负载身份、处理 SIGTERM,并使用不可变修订版本。