假设你要为即将上线的应用找一个“新家”，小区里恰好有三位房东。第一位房东 Cloud Foundry 管理着一栋 5A 级企业园区，物业、安保、会议室一应俱全，但搬进去要先填二十份表格、走严格审批；第二位房东 Heroku 开的是酒店式公寓，签约五分钟、拎包即住，连灯泡坏了都有人管，只是房租按天计、加一间房就要翻倍；第三位房东 CapRover 不走寻常路，它卖给你一套智能房屋组装包——你在自己的地皮上拼装集装箱，水电一接就能住，一个月只要几十块，可马桶堵了得自己通。这三位房东的共同身份叫 PaaS（平台即服务）：他们替你管理服务器这些“水电煤”，让你专心写业务代码。跟三位房东打交道，主要看五件事：入住手续（部署流程）、房间扩容（扩展能力）、周边配套（生态支持）、租金账单（价格成本）和产权归属（托管模式）。本文用这场“找房记”把三份合同摊开对比，最后教你怎么按团队情况挑中那一栋最合适的房子。

岗位关联

对 AI 从业者来说，PaaS 选型是平台工程与云原生方向的高频面试话题。掌握三平台差异，你不仅能在技术选型时给出有依据的建议，还能把“内部开发者平台”“少运维、快交付”写进自己的能力清单。

目录
  1. 可视化演示
  2. 1. 平台概述：认识三位房东
  3. 2. 部署流程：入住手续哪家快
  4. 3. 扩展能力：房间不够怎么办
  5. 4. 生态支持：周边配套丰不丰
  6. 5. 价格成本：租金账单算笔账
  7. 6. 托管模式：产权归谁说了算
  8. 7. 选型建议：我的房该怎么选
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示CloudFoundry、Heroku、CapRover三大PaaS平台的部署流程、核心架构组件与选型矩阵，交互理解平台差异。

本节配有交互动效（进入视口后自动加载，约 3KB）。

'+modeData.deploy.caption+'

1. 平台概述：认识三位房东

搬家之前，先摸清三位房东的底细。Cloud Foundry 像一家老牌高端物业公司，服务过许多大型集团，手续规范、门禁森严；Heroku 是连锁酒店式公寓，前台笑容满面，什么都帮你安排妥当；CapRover 则是网上买回来的智能家居组装包，说明书简单，动手拼一拼就能住。三者的共同身份，就是 PaaS（平台即服务）——一个把服务器、操作系统、中间件等“水电煤”全部包办，让你只管把应用代码“拎包入住”的运行环境。

技术世界里，PaaS 的承诺是“免运维 + 快速上线”。但三位房东的经营半径很不一样：Cloud Foundry（简称 CF）是 Linux Foundation 旗下的开源 PaaS 项目，强调企业级能力，比如多租户隔离（org/space）、统一服务市场和 LDAP/SSO 集成。它本身不是一家云厂商，而是一套可以装在自己基础设施上的软件——你要么自己部署，要么买 VMware Tanzu、IBM Cloud 等基于 CF 的商业发行版。

Heroku 是 2007 年诞生的老牌商业 PaaS（现属 Salesforce），核心玩法是 git push 部署，应用运行在名为 dyno 的轻量容器里，主打“五分钟上线”。CapRover 则是 2019 年开源的轻量 PaaS，基于 Docker 与 Docker Swarm，自带 Web 控制台，安装在自己的 VPS 上，强调“傻瓜式 + 极低成本”。一句话概括：CF 是重而稳的企业园区，Heroku 是快而贵的酒店式公寓，CapRover 是便宜灵活的 DIY 小屋。

认完房东，接下来要看三件事：入住手续（部署流程）、房间扩容（扩展能力）、周边配套（生态支持），最后算租金（价格成本）和产权（托管模式）。

运维节省=T自建运维T自建运维+T业务开发\displaystyle \text{运维节省} = \frac{T_{\text{自建运维}}}{T_{\text{自建运维}} + T_{\text{业务开发}}}
这个公式衡量“被运维吃掉的时间占比”。自建机房的团队这个值可能高达 40%，用 PaaS 后通常降到 10% 以下，省下的时间全归业务开发。
  1. 分子 T_自建运维自己买机器、装系统、配网络、打安全补丁的时间，这是“自己当水电工”的成本。
    T自建运维T_{\text{自建运维}}
  2. 分母总工时运维时间与业务开发时间相加，代表团队全部有效工作时间。
    T自建运维+T业务开发T_{\text{自建运维}} + T_{\text{业务开发}}
  3. 比值解读占比越低，团队越专注业务；三位房东的核心价值就是把这个分子压到最低，让“水电煤”不再占用你的工位。
    运维节省→min⁡\text{运维节省} \to \min

2. 部署流程：入住手续哪家快

搬家最怕办手续。Cloud Foundry 的入住要填一份“manifest 登记表”，写清楚住几个人、房间多大、要接哪些公共设施；Heroku 的入住是前台看一眼身份证，行李就被机器人直接拖进房间；CapRover 则像你把打包好的集装箱（Docker 镜像）交给他，他在 Web 面板上点一下“入库”，箱子自动拆装。

部署流程是选择 PaaS 的第一道门槛，它决定了“从代码到在线”的反馈闭环有多快。Cloud Foundry 要求先写 manifest.yml，声明应用名、内存、域名、绑定服务，然后执行 cf push。平台会用 Buildpack（语言构建包）自动识别 Java、Node、Python 等项目并完成编译打包。概念虽多（org、space、route），但一次配好后可以反复复用。

Heroku 则是把简化做到极致：git push heroku main 一条命令，系统自动检测语言并构建，用 Procfile 声明 web/worker 进程类型。代价是必须遵守 12-factor 规范——配置走环境变量、文件系统只读、端口由 $PORT 决定。CapRover 介于两者之间：在 Web UI 输入镜像名（如 nginx:latest 或你的自有镜像）点 Deploy 即可，也可用 captain-definition 文件配合 CLI；由于底层就是 Docker，任何能打包成容器的应用都能一键上线。

手续快不等于全都好。Heroku 的“快”建立在标准化户型上——你不许敲承重墙（不能改文件系统），而 CF 和 CapRover 虽然登记慢，但屋子的改造自由度明显更大。

T部署=T声明配置+T推送+T构建启动\displaystyle T_{\text{部署}} = T_{\text{声明配置}} + T_{\text{推送}} + T_{\text{构建启动}}
部署总时间由三部分拼成。三平台在“推送”上速度接近，真正的差距在第一项（CF 要写 manifest，Heroku 可以一行不写）和第三项（CapRover 拉镜像通常比源码构建更快）。
  1. 声明配置时间写 manifest.yml、Procfile、captain-definition 的耗时；Heroku 用聪明的默认值把这步压到接近零。
    T声明配置T_{\text{声明配置}}
  2. 推送时间cf push / git push / caprover deploy 的网络传输耗时，三者都不大。
    T推送T_{\text{推送}}
  3. 构建启动时间平台编译源码或拉取镜像、启动进程、挂上路由的总耗时。
    T构建启动T_{\text{构建启动}}
  4. 比较结论看总账，Heroku 最快，CF 前期慢但重复部署有惯性优势，CapRover 居中且依赖镜像大小。
    THeroku<TCapRover<TCloud FoundryT_{\text{Heroku}} < T_{\text{CapRover}} < T_{\text{Cloud Foundry}}

3. 扩展能力：房间不够怎么办

入住之后，最怕的是客人变多、房间不够。三位房东的“加床”方式差别不小：Cloud Foundry 用 cf scale app -i 5 -m 2G 手动扩容，还提供 App Autoscaler 插件，能基于 CPU、内存和吞吐指标自动增减实例；它的路由层 Gorouter 负责负载均衡和蓝绿发布，属于企业级标配。Heroku 在控制台拖动滑块就能增减 dyno，Auto Dynos 会根据响应时间或吞吐自动伸缩，不过该功能要求 Performance 级别以上的 dyno。CapRover 的做法最简单直接——在服务页面点 +/- 调整 Docker Swarm 服务副本数，单机模式下秒级生效；但它没有内置的指标驱动自动伸缩，想实现要自己配合监控系统触发。

对入门者来说，记住一个判断标准：自动伸缩的成熟度从高到低大致是 CF、Heroku、CapRover。云原生领域有个经典公式，用来估算需要准备多少个“房间”：

CF 和 Heroku 都有“物业自动加床”的成熟方案；CapRover 则更像自己手动搬折叠床，够用，但少了一位机器人管家。选平台时，可以按这个公式把未来的流量峰值代进去算一算。

n目标=⌈QPS×t平均响应U目标×C单实例⌉\displaystyle n_{\text{目标}} = \left\lceil \frac{QPS \times t_{\text{平均响应}}}{U_{\text{目标}} \times C_{\text{单实例}}} \right\rceil
这是 Little's Law 的工程化应用：并发数等于每秒请求数乘以平均响应时间，再除以单实例可用容量并向上取整，就得到目标实例数。
  1. 并发请求数QPS 乘以单请求平均耗时，等于某一瞬间系统同时要“伺候”的请求总数，也就是需要同时住下的客人数量。
    QPS×t平均响应QPS \times t_{\text{平均响应}}
  2. 单实例可用容量每个实例最多同时处理 C 个请求，但别打满，要留出 U（如 70%）的安全余量。
    U目标×C单实例U_{\text{目标}} \times C_{\text{单实例}}
  3. 除法运算看总共需要几“瓶”实例才能装下全部并发。
    QPS×t平均响应U目标×C单实例\frac{QPS \times t_{\text{平均响应}}}{U_{\text{目标}} \times C_{\text{单实例}}}
  4. 向上取整实例数必须是整数，多一个比少一个更安全。
    ⌈⋯ ⌉\left\lceil \cdots \right\rceil

4. 生态支持：周边配套丰不丰

住得久了，你会发现小区周边的配套才是生活的关键。Cloud Foundry 自带一个庞大的“服务市场”（Service Marketplace），通过 cf create-service 一行命令就能绑定 MySQL、Redis、RabbitMQ、Spring Cloud 等数百种企业服务，还能与 LDAP、SSO、审计日志无缝集成。Heroku 的 Add-ons 市场同样丰富——Postgres、Redis、New Relic、Papertrail 等数百个第三方插件，在控制台点击即装、即绑定、即计费，体验最顺滑，但高端插件价格不菲。

CapRover 的哲学完全不同：它不建自有商城，而是把整个 Docker Hub 当成市场——任何公开镜像都能一键部署，同时内置几十个 One-Click App 模板（数据库、博客、监控等）。代价是没有商业化的托管插件生态，想用 New Relic 这类服务得自己搭 Prometheus + Grafana 那套监控。生态的价值可以用一个比值来看：

周边配套决定了你后续开发的“地气”。追求开箱即用选 Heroku，追求企业服务矩阵选 CF，愿意自己组装监控和中间件则选 CapRover。

V生态=C现成服务C自建服务\displaystyle V_{\text{生态}} = \frac{C_{\text{现成服务}}}{C_{\text{自建服务}}}
生态价值 = 租用现成服务的成本 ÷ 自建同类服务的成本。比值小于等于 1，说明“租”比“建”划算，市场生态健康；比值大于 1 说明市场里没有便宜货，不如自己动手。
  1. 现成服务成本在市场上租数据库、消息队列、监控的月度费用。
    C现成服务C_{\text{现成服务}}
  2. 自建服务成本自己部署运维同类服务的折算成本，包含机器和人力。
    C自建服务C_{\text{自建服务}}
  3. 比值判断Heroku Add-ons 单价高但接入快；CF 市场对企业批量采购友好；CapRover 没有统一市场，但镜像免费，自建成本低。
    V生态≤1⇒租划算V_{\text{生态}} \le 1 \Rightarrow \text{租划算}

5. 价格成本：租金账单算笔账

房租永远是选房最敏感的变量，而三位房东的账单结构截然不同。Cloud Foundry 软件本身免费，但“入住费”藏在别处：自己部署要支付 BOSH 集群的人力成本，商业发行版更是动辄数千美元一个月，适合预算充足、必须私有化的大企业。Heroku 在 2022 年取消了免费 dyno，最低档 Eco dynos 约 $5/月（共享资源、有休眠机制），Standard 1X 从 $25/月（512MB）起步，再加上 Postgres、Redis 等 Add-ons，一个像样的 Demo 轻松到 $50–150/月。

CapRover 是性价比之王：软件完全免费，你只需要一台 VPS，入门级 $5–12/月就能跑十几个小应用，同样的部署密度，月成本常常只有 Heroku 的五分之一。但要当心隐性账单，把三类费用都算进去：

租金算清楚之后，别忘了问自己一句：这账单里有多少是我能控制、多少只能听房东的？这就引出产权问题。

C月度=C订阅+C实例×N实例+C运维时薪×H运维\displaystyle C_{\text{月度}} = C_{\text{订阅}} + C_{\text{实例}} \times N_{\text{实例}} + C_{\text{运维时薪}} \times H_{\text{运维}}
月度总成本 = 订阅费 + 实例数量 × 单价 + 运维时薪 × 运维小时。Heroku 的订阅和实例费高、运维小时约等于零；CF 是订阅高、运维小时也高；CapRover 订阅为零、运维小时小、实例费就是整台 VPS 的价格。
  1. 订阅费平台收取的“物业费”——Heroku 订阅、CF 商业版授权，CapRover 为 0。
    C订阅C_{\text{订阅}}
  2. 实例费用每个运行单元（dyno、容器、VM）按月计费，N 个实例就是单价乘 N。
    C实例×N实例C_{\text{实例}} \times N_{\text{实例}}
  3. 运维人力自己花在平台运维上的小时数乘以工时单价，CF 自建时这一项是吞金兽。
    C运维时薪×H运维C_{\text{运维时薪}} \times H_{\text{运维}}
  4. 求和比较三项加起来才是“真实租金”，只看单价不看运维是选型里最常见的账本错误。
    C月度C_{\text{月度}}

6. 托管模式：产权归谁说了算

同样是租房，“产权”性质决定你能改动多少、数据放在哪。Cloud Foundry 可以部署在私有云、VMware、OpenStack 甚至裸机上，支持 org/space 多租户隔离，数据主权牢牢握在自己手里，因此深受金融、政务、医疗等强合规行业青睐。Heroku 则是纯公有云托管——底层跑在 AWS 上，用户完全不碰基础设施，但数据在平台方管辖之下，涉及数据出境或等保合规时就要谨慎。

CapRover 走的是自托管路线：安装在你自己的 VPS 或物理机上，支持单机和多节点 Swarm 集群，数据 100% 在自己手里；可高可用、备份、安全加固这些也全得自己负责。这里可以引入一个“管控指数”来理解三者的差异：

产权越自主，责任也越重。想清楚你更怕“数据失控”还是“运维费心”，托管模式自然就有了答案。

Q管控=1−T外部依赖T总运营\displaystyle Q_{\text{管控}} = 1 - \frac{T_{\text{外部依赖}}}{T_{\text{总运营}}}
管控指数 = 1 − 外部依赖工时 ÷ 总运营工时。指数越高，运营工作越少依赖平台方；Heroku 几乎包办所有故障恢复和打补丁，指数最低；CapRover 什么都自己来，指数最高；CF 通过私有化部署把外部依赖压到很低。
  1. 外部依赖时间依赖平台处理的事件（宕机恢复、安全补丁、网络问题）折算成的工时。
    T外部依赖T_{\text{外部依赖}}
  2. 总运营时间应用生命周期里所有运维相关工时的总和。
    T总运营T_{\text{总运营}}
  3. 补集计算用 1 减去依赖占比，剩下的就是“自己说了算”的比例。
    1−T外部依赖T总运营1 - \frac{T_{\text{外部依赖}}}{T_{\text{总运营}}}
  4. 数值解读指数越高越自主，适合合规要求高的组织；指数越低越省心，适合追求速度的团队。
    Q管控∈[0,1]Q_{\text{管控}} \in [0, 1]

7. 选型建议：我的房该怎么选

看完三份合同，最后一步是决策。大企业、强合规场景（金融、医疗、政务）优先选 Cloud Foundry：私有化部署、审计日志、SSO、多租户治理一应俱全，长期成本可预期。中小团队、快速验证阶段优先选 Heroku：五分钟上线、生态顺手，适合现金流充足、抢时间的创业期。独立开发者、成本敏感型项目优先选 CapRover：一台 VPS 跑全家桶，自由折腾又省钱。常见的演进路线是：MVP 先用 Heroku 验证，规模起来后迁到 CapRover 降成本；或者小团队先用 CapRover，业务复杂后再评估是否上 CF。

技术选型说到底是一个加权评分问题。不要凭感觉拍板，先把五个维度各打 0–10 分，再乘上你的战略权重：

这场找房记走到尾声：没有绝对最好的平台，只有最匹配的合同。把五个维度摆上桌、把权重写清楚，三位房东的优劣自然水落石出。

S选型=wD D+wE E+wB B+wC C+wG G\displaystyle S_{\text{选型}} = w_D\,D + w_E\,E + w_B\,B + w_C\,C + w_G\,G
其中 D 是部署便利、E 是扩展能力、B 是生态支持、C 是成本、G 是合规治理，五个权重之和为 1。先想清楚“我最缺什么”，再给分数，而不是反过来用感觉选平台。
  1. 五个维度D 部署便利、E 扩展能力、B 生态支持、C 成本、G 合规治理，每项按团队需求打分。
    D,E,B,C,GD, E, B, C, G
  2. 权重向量五个权重相加等于 1，权重越大代表战略上越重视。
    wD+wE+wB+wC+wG=1w_D + w_E + w_B + w_C + w_G = 1
  3. 加权求和每一项等于“分数 × 重视程度”，累加得到综合分。
    S选型=∑wixiS_{\text{选型}} = \sum w_i x_i
  4. 决策输出选总分最高的房东，并反问自己：这个权重真的符合团队战略吗？如果重合规却给了 G 最低权重，分数就会说谎。
    SCF:SHeroku:SCapRoverS_{\text{CF}} : S_{\text{Heroku}} : S_{\text{CapRover}}

AI 应用场景

场景 1：初创团队 48 小时上线 AI 表情识别 Demo

阶段：模型推理服务部署 / MLOps 发布

解决的问题：传统方式要自己租 GPU 服务器、配置环境、写部署脚本，至少折腾一周。用 CapRover 把模型服务（FastAPI + ONNX）打成 Docker 镜像，在 Web 面板点一下部署，域名和 HTTPS 自动就绪，几十分钟就能得到一个能对外演示的链接。

具体案例：一支 3 人 AI 团队给学校做“课堂专注度分析”POC，用 CapRover 在一台 $20/月的 VPS 上部署前端、推理服务和 PostgreSQL，两周迭代了 5 版，最终拿下正式合同。

场景 2：企业内部开发者平台（IDP）用 Cloud Foundry

阶段：平台工程 / 内部工具链建设

解决的问题：大组织里各团队重复搭环境、申请资源排期长。把 Cloud Foundry 定位成内部 PaaS 后，开发者一条 cf push 就能自助发布微服务，平台团队统一管控密钥、日志、审计，实现“内部开发者平台”的标准化。

具体案例：某银行 AI 中台团队基于 Tanzu 自建 Cloud Foundry，数据不出内网，模型服务与风控系统共享同一个多租户平台，顺利通过银保监合规审计。

场景 3：创业者用 Heroku 快速给投资人演示

阶段：MVP 验证 / 对外演示

解决的问题：Demo 必须跑在一个可随时分享的公网 URL 上。Heroku 配合 git push 与托管 Postgres，几分钟就能部署一个 LLM 客服机器人，当晚就能把演示链接发给投资人。

具体案例：一位独立开发者在深夜把 AI 客服原型推到 Heroku，第二天上午给投资人演示实时对话效果，靠“看得见摸得着”的 Demo 拿到了种子轮意向。

Python 演示

python47 行
# -*- coding: utf-8 -*-"""PaaS 选型评分器: 按团队关心的维度为三个平台打分并给出推荐""" WEIGHTS = {    "deploy": 0.30,  # 部署便利, 越省事越高分    "scale":  0.20,  # 扩展能力, 自动伸缩越强越高    "eco":    0.15,  # 生态支持, 现成服务越多越高    "cost":   0.20,  # 成本, 越便宜越高分    "gov":    0.15,  # 合规治理, 私有化与审计越强越高} PLATFORMS = {    "Cloud Foundry": {"deploy": 6, "scale": 9, "eco": 8, "cost": 4, "gov": 10},    "Heroku":        {"deploy": 10, "scale": 7, "eco": 9, "cost": 5, "gov": 6},    "CapRover":      {"deploy": 8, "scale": 6, "eco": 8, "cost": 9, "gov": 7},}  def score(name, weights):    """加权求和得分: S = sum(w * x)"""    return sum(weights[k] * PLATFORMS[name][k] for k in weights)  def monthly_cost(subscription, per_instance, instances, ops_hours, hourly_rate):    """月度账单 = 订阅费 + 实例费 + 运维人力"""    return subscription + per_instance * instances + ops_hours * hourly_rate  def main():    print("=== PaaS score (tune WEIGHTS by team) ===")    for name in PLATFORMS:        print(f"{name}: {score(name, WEIGHTS):.1f} pts")    best = max(PLATFORMS, key=lambda n: score(n, WEIGHTS))    print(f"Best match: {best}")     print("\n=== Rough monthly cost ===")    bills = {        "Heroku":        monthly_cost(25, 25, 4, 0, 0),        "CapRover":      monthly_cost(0, 20, 1, 2, 40),        "Cloud Foundry": monthly_cost(1200, 0, 0, 10, 100),    }    for name, bill in bills.items():        print(f"{name}: about ${bill}/month")  if __name__ == "__main__":    main()
目的：把正文第 7 节的“加权选型评分公式”变成可运行的脚本，同时输出三种平台的粗略月度账单，帮你在技术选型会上快速给出量化结论。
  1. WEIGHTS = {...}权重就是“你说什么最重要”的数字化：想省钱就把 cost 调高。
  2. PLATFORMS = {...}三位房东的五维评分表，由前六节对比总结而来，0–10 分。
  3. def score(name, weights):实现选型公式 S = Σw·x 的核心函数。
  4. sum(weights[k] * PLATFORMS[name][k] for k in weights)一行代码把“分数 × 权重再累加”写完。
  5. def monthly_cost(...)提醒你别只看订阅费，实例费和运维工时都得进账单。
  6. max(PLATFORMS, key=lambda n: score(n, WEIGHTS))直接找出综合分最高的平台。

常见误区

误区我听说 Heroku 是免费的，学生时代用过，现在项目肯定也能白嫖。于是抱着零成本预期，把预算直接算成 0。

正解Heroku 在 2022 年正式取消了免费 dyno，最低档 Eco dynos 要 $5/月，而且共享 CPU、有休眠机制。想真正省钱，可以转向 CapRover——软件免费，只需一台自有的 VPS。

为何常见：网上大量老教程和问答社区还停留在"free dyno"时代，加上 Heroku 名气太大，让人误以为是公益平台。

误区Cloud Foundry 名字里带"Cloud"，那它应该就是和 AWS 一样的公有云提供商吧？

正解CF 是开源的 PaaS 软件，本身不卖云资源。要用它，要么部署在自己的服务器上（私有化），要么购买 VMware Tanzu、IBM Cloud 这类基于 CF 的托管服务。名字里的"Cloud"指的是它帮你抽象掉基础设施，不是说它自己是机房老板。

为何常见：中文语境下“云”常与“云厂商”混用，加上 CF 官网总展示大型数据中心图片，很容易产生联想。

误区CapRover 基于 Docker，那不用 Docker 命令肯定玩不转，还是不碰为妙。

正解恰恰相反，CapRover 的产品哲学就是“远离 Docker 命令行”。Web UI 上点几下、填个镜像名就能部署，Docker 知识只在你想做定制化（多阶段构建、自写 Dockerfile 优化）时才派得上用场。

为何常见：技术传闻把“基于 Docker”等同于“必须会 Docker”，让对容器有恐惧感的初学者直接放弃。

误区PaaS 就是全托管，我推完代码就可以安心睡觉，出什么事都是房东的责任。

正解PaaS 免掉的是“服务器运维”——硬件、系统、网络、补丁。但“应用运维”还在你肩上：容量规划（几个实例够用）、监控告警、成本治理、发布节奏。Heroku 睡一觉可能账单就爆了，CF 的扩缩容策略也得有人调。

为何常见：厂商宣传“免运维”过于顺口，小白容易把“免服务器运维”扩大解释成“免全部运维”。

误区一旦用了 Heroku 的 Postgres，这辈子就绑死在它家了，所以不敢选。

正解如果你的应用遵守 12-factor 规范（环境变量配置、无状态、日志输出到 stdout），在三个平台之间搬家并不难——代码本质上都是“跑一个 Web 进程”。真正粘人的是配套服务，但数据库、队列这些大都有标准协议，换了个连接串就能切走。CapRover 用 Docker 镜像迁移更是常规操作。

为何常见：听到“厂商锁定”就恐惧，实际上锁定程度取决于你怎么写应用，而不是平台本身。

面试题

Q1. PaaS 的核心价值是下列哪一项？

单选题 · easy

  • A.提供虚拟机让你手动装环境
  • B.托管应用环境免去服务器运维← 正确答案
  • C.只提供对象存储的服务
  • D.自动帮你编写全部业务代码

答案：B。PaaS 的承诺是“拎包入住”——B 对应房东把服务器、系统、中间件全包办；A 只是给你一台能 SSH 的虚拟机（那是 IaaS）；C 只租了一间储藏室；D 等于请人替你写代码，与平台托管无关。

Q2. Heroku 部署应用的主要方式是？

单选题 · easy

  • A.通过 Docker 拉取镜像启动
  • B.上传 war 包到管理后台
  • C.git push 推送代码即部署← 正确答案
  • D.用 FTP 上传 HTML 文件

答案：C。Heroku 的标志性动作就是 git push heroku main，相当于刷身份证后机器人把行李拖进房间；A 描述的是 CapRover 的镜像部署，B 是老式应用服务器的手工操作，D 比静态网站托管还原始。

Q3. Cloud Foundry 中描述应用声明配置的文件是？

单选题 · mid

  • A.Procfile 进程声明文件
  • B.manifest.yml 清单配置文件← 正确答案
  • C.Dockerfile 镜像构建文件
  • D.package.json 包管理文件

答案：B。manifest.yml 是 Cloud Foundry 的“入住登记表”，声明应用名、内存、路由和服务绑定；Procfile 属于 Heroku，负责声明 web/worker 进程类型；Dockerfile 属于容器世界；package.json 只是 Node 项目的依赖清单。

Q4. CapRover 底层基于哪种容器编排技术？

单选题 · mid

  • A.Kubernetes 容器编排
  • B.Docker Swarm 集群← 正确答案
  • C.Apache Mesos 资源调度
  • D.HashiCorp Nomad 调度器

答案：B。CapRover 是跑在 Docker Swarm 上的“壳”，它把 Swarm 的服务副本、网络、更新策略包装成 Web 界面；Kubernetes 是另一套编排体系，并非 CapRover 的底座。

Q5. 在 Heroku 中，dyno 指的是什么？

单选题 · mid

  • A.dyno 是数据库资源的计量单位
  • B.dyno 是应用进程的运行容器← 正确答案
  • C.dyno 免费且数量不受限制
  • D.dyno 只支持运行 Go 应用

答案：B。dyno 就是 Heroku 的最小运行单元——一个装着应用进程的轻量容器，web 和 worker 都由它承载；它不是数据库单位，也谈不上免费，规格不同价格从 $5 到数百美元不等。

Q6. 下列哪个方案最适合在自有 VPS 上搭建高性价比 PaaS？

单选题 · easy

  • A.Amazon Web Services 三大云之一
  • B.Microsoft Azure 微软的云服务
  • C.CapRover 轻量级开源 PaaS← 正确答案
  • D.Cloud Foundry 企业级平台

答案：C。CapRover 的设计目标就是“在一台自己的 VPS 上几分钟搭出 PaaS”；AWS/Azure 是云厂商而非 PaaS 软件；Cloud Foundry 要部署整套 BOSH 集群，一台小 VPS 根本背不动。

Q7. 使用 PaaS 之后，团队通常仍需负责哪些工作？

多选题 · mid

  • A.应用代码更新与发布上线← 正确答案
  • B.服务器硬件采购与排障
  • C.容量规划监控与告警处理← 正确答案
  • D.机房供电散热与布线

答案：AC。PaaS 免掉的是“服务器运维”：硬件（B）、机房（D）都与用户无关；但发布（A）和容量监控（C）属于“应用运维”，依然得自己负责。别把房东的职责和自己的职责混为一谈。

Q8. 哪些平台支持通过增加副本或实例进行横向扩展？

多选题 · mid

  • A.Cloud Foundry 用 cf scale 扩容← 正确答案
  • B.Heroku 通过增加 dyno 扩容← 正确答案
  • C.CapRover 调整服务副本数量← 正确答案
  • D.Excel 表格手动调整行数

答案：ABC。三个平台都支持横向扩展，只是方式不同：cf scale、dyno 滑块、Swarm 服务副本数。D 是干扰项，但也提醒我们：扩容是平台能力，不是表格里的手工活。

Q9. 某应用 QPS=2000、平均响应 50ms、单实例并发容量 20、目标利用率 70%，至少需要几个实例？

单选题 · hard

  • A.5 个实例仅覆盖六成需求
  • B.8 个实例满足目标利用率← 正确答案
  • C.12 个实例超出实际需要
  • D.14 个实例造成资源浪费

答案：B。并发数 = 2000 × 0.05 = 100；单实例可用容量 = 20 × 0.7 = 14；100 ÷ 14 ≈ 7.14，向上取整得 8。A 的 5 个实例只能扛 70 个并发会过载；C、D 资源浪费。

Q10. 2022 年之后 Heroku 取消免费 dyno，其最低档 Eco dynos 的月费约为多少？

单选题 · hard

  • A.完全免费无需付费
  • B.每月大约 5 美元← 正确答案
  • C.每月大约 25 美元
  • D.每月大约 100 美元

答案：B。Eco dynos 约 $5/月，共享资源且有休眠机制；Standard 1X 才是 $25/月。把“最低档”和“标准档”记混，是这道题最常见的翻车点。