波仔
☁️ 第四章 构建云服务的技术
📄 一句话概括

Cloud Foundry 是开源 PaaS 的代表，它的卖点浓缩成一条命令：cf push——你只交代码，识别语言、装依赖、打包、起实例、配路由、做健康检查、挂负载均衡这些全自动；代价是平台替你做的那部分，你就改不了，所以它适合【标准应用、想快点上线】的团队，不适合【要精细控制】的场景。

📝 本节和前面几节的关系

上一节（4-17）讲的是【怎么攒出一套 IaaS】——把机器、网络、存储变成可分配的资源。这一节往上走一层：IaaS 给你的是空机器，你还得自己装环境；而 PaaS 直接把【能跑应用的平台】给你。

这个层次的差别，第二章的 包含开发环境的 PaaS 已经讲过（那一节讲【PaaS 卖的是已经搭好的那一半】）。这一节讲的是它的开源实现长什么样，以及它和现在主流的容器平台是什么关系。

一、cf push 一条命令，底下发生了什么

先把这条命令拆开。你输入：

cf push 我的应用

平台自动完成：

步骤 平台做了什么
1. 识别 看你的代码目录，判断是什么语言（Java、Node、Python、Go…）
2. 装依赖 按语言自动拉取并安装依赖
3. 打包 把代码和运行环境打成一份可运行的镜像
4. 起实例 按你要求的数量启动
5. 配路由 分配一个可访问的地址
6. 健康检查 起来之后确认它真的能服务
7. 挂负载均衡 把流量分给这几个实例
8. 出日志 统一收集输出，供你查看

关键在【你不需要写的东西】：没有 Dockerfile、没有 YAML、不用配负载均衡、不用管域名——这些东西要么由平台推断，要么由平台自动决定。

这就是 PaaS 的本质：把【部署】这件事从【配置工作】变成【一次提交】。

二、动手 Demo：两条路的操作量差多少

看到什么算成功：

==================================================================================================
【Demo 18】PaaS 的基础软件：cf push 与写一堆 YAML 的差别
==================================================================================================
  Cloud Foundry 是开源 PaaS 的代表。它的卖点浓缩成一条命令：

    cf push 我的应用

  底下自动做的事：识别语言 → 装依赖 → 打包 → 起实例 → 配路由 →
  做健康检查 → 挂负载均衡 → 出日志。

  同一个应用，两条路的操作量对比：

  环节                  Cloud Foundry       Kubernetes
  --------------------------------------------------------------------------------------------
  声明运行环境          框架自动识别        写 Dockerfile
  打包                  buildpack 自动      写构建配置，跑镜像构建
  部署描述              一条命令            写 Deployment / Service 等 YAML
  对外访问              自动给域名          配 Ingress 或负载均衡
  扩缩容                改一个数字          改副本数，或配自动扩缩规则
  需要懂多少底层        很少                要懂容器、网络、存储
  --------------------------------------------------------------------------------------------
  代价是灵活度：平台替你做的那部分，你就改不了。
  所以两类平台的分工越来越清楚：
    · 只想快点上线、应用是标准的十二要素应用 → PaaS 省事
    · 需要精细控制、要跑有状态服务或特殊网络 → Kubernetes

  补充一个现实：官方站点 2026 年仍在维护这套项目，
  但它的定位正在从【独立平台】转向【跑在 Kubernetes 之上的高层抽象】。

读结果：

30 秒实验

在能联网的机器上（或看文档），搜【Cloud Foundry 教程 cf push】或【Heroku 部署 一条命令】，做一件事：

看它的【快速开始】页面，数一数从【本地代码】到【网上可访问】需要几步。

做完这个你会看到一件事：这类平台的快速开始通常只有三步——登录、选一个运行环境、push。而同一个应用如果用容器平台部署，快速开始通常是一页甚至几页的清单。这个差别就是抽象层次的价格标签。

常见误区

  1. 错误：PaaS 是 IaaS 的升级版，所以应该尽量用 PaaS。——纠正：它们是不同的取舍，不是高下之分。PaaS 省事，但它要求应用符合平台的假设（无状态、标准语言、标准依赖），并且平台不提供的能力你就没有（特殊的网络配置、自定义内核参数、非标准的中间件）。所以选型标准是：你的应用是不是【平台允许的形状】，而不是【哪个层次更高】。

  2. 错误：PaaS 只能跑简单的小应用。——纠正：限制不在应用大小，在应用【是否标准】。很多大型系统同样跑在 PaaS 上——只要它们被设计成无状态、可水平扩展、依赖外部服务。反过来说，一个很小的应用如果必须写本地文件、必须固定 IP、必须绑某个内核版本——那它在 PaaS 上反而不行。判断标准始终是应用的性质，不是规模。

  3. 错误：有了 Kubernetes，PaaS 就没用了。——纠正：它们在不同的抽象层次上，于是【谁更方便】取决于你的运维能力。Kubernetes 更灵活、生态更大，但它把【怎么写部署】这件事还给了你；PaaS 把这件事拿走，代价是失去控制。所以很多云服务商的做法是【在 Kubernetes 上再搭一层 PaaS 式的体验】——两层一起提供，让团队按需要选择。这不是替代关系，是叠加关系。

  4. 错误：cf push 快，所以它【不用管运维】。——纠正：运维成本被转移了，不是消失了。平台替你做的是【应用部署与调度】，但平台本身要不要人维护？日志要看吗？容量要规划吗？出故障要找谁？ ——这些都还在。所以 PaaS 省的是【应用团队的运维】，不是【组织的运维】；用托管型 PaaS 时，这部分由服务商承担（这也是它按资源收费的原因之一）。

自测三问（点开对答案） 1. 【平台替你做的那部分，你就改不了】这句话，举一个具体的例子说明后果。 —— 比如**网络**。PaaS 自动给你一个域名、自动挂上负载均衡——很方便；但如果你的应用需要**固定的出口 IP**（比如对端系统要求白名单），或者需要**非标准的端口映射**（比如跑一个 UDP 服务），**自动配置的那套往往做不到**。这时要么放弃这个需求，要么换平台。**这就是抽象的代价：它把【默认正确的做法】固化下来，而你的需求一旦偏离默认，就没有路走。** 2. 为什么说【应用是不是十二要素应用】决定了能不能用 PaaS？ —— 因为**平台要在任意节点上随时启停和迁移你的应用**。这要求应用：**不把状态存在本机**（否则换台机器数据就没了）、**配置从环境变量读**（否则换个环境就要改代码）、**可以被安全地并行运行多个实例**（否则扩缩容会出问题）。这些正是【十二要素】的核心内容。**所以不是【PaaS 限制了应用】，而是【能被任意调度的应用，必然长这个样子】。** 3. 如果一个团队既想要 PaaS 的省事，又偶尔需要底层控制，该怎么选？ —— **按【服务】分别选，而不是按【公司】统一选**。日常的、标准的服务走 PaaS（省事、上线快）；少数确实需要精细控制的（比如特殊网络要求、有状态数据库、性能敏感的核心组件）走容器或虚拟机（灵活）。**同一份系统里两种并存是常态**，而且它们可以通过标准接口互相调用。**这种【按需分配抽象层次】的做法，本质上和 2-5 讲的【把麻烦换到合适的人手上】是同一种思路。**
⚠️ 2026 现状：Cloud Foundry 与 PaaS 的今天
  • 这个项目仍在维护，官方站点和社区活动都还在进行，一代产品迭代到了【在 Kubernetes 上实现同一套 PaaS 体验】的方向——说明它选择的活法是【成为一层高层抽象】，而不是继续做独立平台。
  • 但生态重心确实转移了。多数用户和人才都在往容器平台迁移，相关的招聘需求这几年明显下降——这对学习者的实际意义是：理解 PaaS 的思想（抽象、约定优于配置、平台即产品）比记住某一个具体产品更重要，因为这些思想被继承到了后来的所有平台里。
  • 反过来说，PaaS 的核心主张在 2026 年反而更被认可了：让开发者只关心代码——这个目标现在以【内部开发者平台】【平台工程】这样的形式重新流行起来。所以这一节讲的东西没有过时，只是换了实现它的载体。

相关笔记