波仔
☁️ 第二章 构建系统优先考虑云服务的时代
📄 一句话概括

PaaS 卖的是"已经搭好的那一半"——它替你省下的不是钱，是"把通用部件再实现一遍"的这段时间；而那部分时间从来不写进需求文档，却总是吃掉项目的前两周。

📝 本节和前面几节的关系

上一节（是导入服务器还是利用 IaaS）停在 IaaS——机器归你，其余归你。这一节往上走一层。

标题里的【包含开发环境】是关键：PaaS 的特点是它替你把"从代码到能跑起来"之间的所有环节都准备好了。所以它特别适合两类场景——需要快速起步的新项目，以及像物联网、人工智能这种要用到一堆不同组件的场景。这两类正是本节要算的账。

一、PaaS 到底"包含"了什么

用一句话说清 IaaS 和 PaaS 的差别：

"已经配好"这四个字里包含的东西相当多：运行时的版本、依赖的管理、日志往哪儿去、配置怎么下发、进程挂了谁来拉起、发布怎么做、扩缩容谁来触发。这些东西每一样单独看都不难，但它们加起来就是一笔不小的工作量，而且技术含量不高、重复度极高。

二、通用部件：自建要几天，托管要几分钟

通用部件 自建要做什么 用 PaaS 之后
用户认证 搭 LDAP/OAuth，写对接 勾选即可，10 分钟
日志收集 装采集器＋存储＋检索 开箱，按量计费
消息队列 装 MQ，还要自己做高可用 开箱，托管
缓存 装 Redis，还要做集群 开箱，托管
全文搜索 装 ES，调参＋扩容自己做 开箱，托管
定时任务 自己写调度，防重复触发 开箱，托管
应用监控 装探针＋做告警规则 开箱，默认就有

这张表最值得注意的是右边那列的措辞——"开箱"。

它代表的不是"少写点代码"，而是"少操一份心"。 以消息队列为例：自己装 MQ，你要处理的不只是安装，还有它自己挂了怎么办、积压了怎么办、磁盘满了怎么办。这些都不是"写代码"能解决的问题，而是运维问题——而 PaaS 把这些运维问题变成了服务的一部分。

三、物联网＋人工智能：一条七段链路

这两类场景特别值得单独讲，因为它们有一个共同特点：要用到的东西特别多，而且都不该自己造。

环节 要做什么 有没有托管版
① 设备接入 支持 MQTT 等协议、扛住并发 有（IoT 接入服务）
② 消息缓冲 削峰、保证不丢 有（托管消息队列）
③ 流式处理 清洗、聚合、算时间窗 有（流计算）
④ 数据存储 存原始数据与结果 有（对象存储＋数仓）
⑤ 模型训练 要 GPU、要排队调度 有（托管训练平台）
⑥ 模型推理 部署、扩缩、按调用计费 有（托管推理服务）
⑦ 业务应用 把结果给人看 要自己写

七段里六段有现成的。

这条链路最能说明"不自己造"的价值：如果你要自建，第①②③段就要三套不同的系统，而且每一套都不是你们的核心业务——你造它们不会让产品更好，只会让上线更晚。而到了第⑦段（把结果给人看），才是真正体现你们业务理解的地方。

四、开发环境：搭一次要多久

除了运行环境，PaaS 还有一项常被忽略的交付物——开发环境：

搭建项 自建（5 天） PaaS（30 分钟）
服务器与操作系统 采购、装系统、配网络 选个规格，1 分钟
运行时与依赖 逐个装、对准版本 镜像里自带
数据库 装、初始化、开权限 点一下，10 分钟
缓存与消息队列 又两套要装要调 点一下，5 分钟
持续集成与部署 搭 CI、写流水线 自带，绑定仓库即可
环境复制给同事 再走一遍全流程 同一条命令，1 分钟

最后一行最值得记住——"环境复制给同事"。

自建环境下，新人入职要花几天才能把开发环境跑起来，而且每个人的环境还不完全一样，于是出现"在我这儿是好的"这种经典问题。有了 PaaS，环境变成了一条命令——这不只是省时间，它是把"环境差异"这个故障来源直接删掉了。

（这也呼应了第一章 从系统运用角度看云计算的优越性 里那笔时间账：开发环境从 20 天压到 15 分钟，省下的 17 天主要就是"审批＋采购"。）

五、动手 Demo：把通用部件与链路都列出来

# 七段链路里，哪几段有托管版
chain = [("设备接入", True), ("消息缓冲", True), ("流式处理", True),
         ("数据存储", True), ("模型训练", True), ("模型推理", True),
         ("业务应用", False)]
hosted = sum(1 for _, ok in chain if ok)
print("共 %d 段，有托管版的 %d 段，要自己写的 %d 段"
      % (len(chain), hosted, len(chain) - hosted))

实跑输出：

==================================================================================================
D8 包含开发环境的 PaaS：通用部件不用再自己搭
==================================================================================================
  【一】七个通用部件：自建要几天，用 PaaS 要几分钟

  通用部件          自建要做什么                      用 PaaS 之后
  ----------------------------------------------------------------------------------
  用户认证          搭 LDAP/OAuth，写对接             勾选即可，10 分钟
  日志收集          装采集器＋存储＋检索              开箱，按量计费
  消息队列          装 MQ，还要自己做高可用           开箱，托管
  缓存              装 Redis，还要做集群              开箱，托管
  全文搜索          装 ES，调参＋扩容自己做           开箱，托管
  定时任务          自己写调度，防重复触发            开箱，托管
  应用监控          装探针＋做告警规则                开箱，默认就有

  【二】物联网＋人工智能：一条七段的链路，六段有现成的

  环节                  要做什么                          有没有托管版
  ------------------------------------------------------------------------------------
  ① 设备接入            支持 MQTT 等协议、扛住并发        有（IoT 接入服务）
  ② 消息缓冲            削峰、保证不丢                    有（托管消息队列）
  ③ 流式处理            清洗、聚合、算时间窗              有（流计算）
  ④ 数据存储            存原始数据与结果                  有（对象存储＋数仓）
  ⑤ 模型训练            要 GPU、要排队调度                有（托管训练平台）
  ⑥ 模型推理            部署、扩缩、按调用计费            有（托管推理服务）
  ⑦ 业务应用            把结果给人看                      要自己写

  【三】搭一套开发环境：自建 5 天，PaaS 30 分钟

  搭建项                  自建（5 天）          PaaS（30 分钟）
  ----------------------------------------------------------------------------
  服务器与操作系统        采购、装系统、配网络  选个规格，1 分钟
  运行时与依赖            逐个装、对准版本      镜像里自带
  数据库                  装、初始化、开权限    点一下，10 分钟
  缓存与消息队列          又两套要装要调        点一下，5 分钟
  持续集成与部署          搭 CI、写流水线       自带，绑定仓库即可
  环境复制给同事          再走一遍全流程        同一条命令，1 分钟

  ④ PaaS 卖的是【已经搭好的那一半】。它替你省下的不是钱，
     是【把通用部件再实现一遍】的这段时间——而那部分时间，
     从来不会写进需求文档，却总是吃掉项目的前两周。

读这个输出：三张表连起来看，会发现它们的结构是一样的——左边是"要做哪些事"，右边是"已经做好了"。这个结构本身就是 PaaS 的定义。 而最该留意的是第三张表的最后一行："环境复制给同事"在自建时要"再走一遍全流程"，在 PaaS 上是"同一条命令"。这个差别背后是环境的一致性——而环境不一致是很多"偶发故障"的真正来源。

六、⚠️ 2026 现状

30 秒实验

想一想你现在（或曾经）负责的系统，把它的技术栈写成一条线：接入 → 消息 → 计算 → 存储 → 应用。

对每一段问一句："这一段有托管版吗？如果有，我为什么还是自己搭了？"

常见的三种答案：① 不知道有；② 担心被绑定；③ 一开始没规划，用着用着就长成这样了。如果答案是①或③，那么这一节省下的时间本来是可以拿到的。

常见误区

  1. 错误：PaaS 会限制技术选型，所以要自由就自己搭。——纠正：这个顾虑在过去成立，现在减轻了很多。今天的平台能力大多是按项提供的——你可以只用托管的消息队列，其余部分照旧自己决定。真正受限的是运行时环境（比如语言版本、依赖管理方式），而那部分恰恰是"按平台的规范来"最省事的地方。先问清楚"具体哪一项受限"，再决定要不要为了自由多花那两周。

  2. 错误：托管部件就是装好了给我用，我自己不用懂。——纠正：托管藏起来的是安装，不是原理。消息队列积压了要怎么办、缓存命中率上不去要查什么、搜索为什么慢——这些判断仍然在你这边。平台替你动手，不替你判断；对原理的理解程度，直接决定了你出问题时是十分钟解决还是十小时。

  3. 错误：开发环境搭 5 天只是一次性成本，忍一下就好。——纠正：它不是一次性，是按人头、按次数的重复成本。每来一个新同事、每换一台电脑、每次环境弄坏了要重来，都要再走一遍。而更贵的不是那几天，是"环境不一致"带来的排查时间——那种"在我这儿是好的"的问题，往往要耗掉好几个人半天。环境能一条命令复现，是把这一类问题从根上删掉。

  4. 错误：物联网和人工智能这么复杂，肯定得自己从头搭。——纠正：恰恰相反，越是组件多的场景，越不该自己造。七段链路里六段有托管版，说明这些环节已经足够标准化，标准化就意味着可以买。而你自己造的那些环节，多半也造不过专门做这件事的团队。把人力留给第⑦段（业务应用），才是这类项目正确的资源分配。

自测三问（点开对答案） 1. 为什么说 PaaS 省下的"不是钱，而是时间"？ —— 因为**它替掉的是一批技术含量不高、但重复度极高的搭建工作**——装运行时、配日志、搭消息队列的高可用、写发布流水线。这些工作如果外包给平台，账单上的数字未必更低；但它**把项目最前面的那段时间腾了出来**，而那段时间通常正是"上线时间"最紧的时候。**PaaS 的价值落在进度上，不在成本表上。** 2. 七段链路里，为什么"业务应用"这一段没有托管版，而且在表里是正常的？ —— 因为**这一段正是你们的业务理解所在**。前面六段（接入、缓冲、计算、存储、训练、推理）都是行业通用能力，谁做都一样；而"把结果给人看"这件事，取决于你们懂不懂这个行业、知不知道该给谁看什么。**如果这一段也有现成的，那说明这个业务本身没有门槛**——所以它要自己写，不是缺点，是这类项目分工的必然结果。 3. 为什么"环境复制给同事"这一行的差距，比"数据库搭建"那一行更值得重视？ —— 因为**数据库搭建只痛一次，环境不一致会一直痛**。它带来的不是延迟，而是**持续存在的、难以定位的干扰**——同一个程序在不同机器上表现不同，排查时先要花时间排除环境因素。**用一条命令消除这个变量，等于把一个长期存在的故障源直接删掉**，价值远超过省下的搭建时间。

相关笔记