# 31 · 云原生与部署平台选型

> 一句话点题:**云原生(Cloud Native)不是「上 Kubernetes」,而是把部署、扩缩、回滚、观测、故障恢复做成一套可重复的工程能力。部署平台选型,本质是在问:你的团队现在值不值得为这些能力支付复杂度。**

---

> **🧰 技术栈选型篇第 5 章 · 本章只练一件事**
>
> [30 章](30-API与服务通信选型.md) 讲服务之间怎么通信。本章往下看一层:服务到底跑在哪里,怎么发布、怎么扩容、怎么回滚、谁来值班。小系统要的是少操心,大系统要的是可控和自治;选错平台,每天都在交复杂度税。

---

## 开场:你选的不是机器,是运维模型

新人常问:

```
   用虚拟机,还是容器?
   用 Serverless,还是 Kubernetes?
   自建,还是上云?
```

架构师会先问另一组问题:

- 谁负责发布?
- 谁负责扩容?
- 谁负责告警?
- 新版本坏了谁能回滚?
- 证书、密钥、配置、日志、指标、权限谁管?
- 出事时团队看不看得懂平台?

所谓部署平台,不是一台机器或一个控制台,而是**从代码变成线上服务的整条路径**:构建、配置、密钥、发布、健康检查、流量切换、自动扩缩、日志指标、故障回滚。

> **判断要点:**平台越省心,通常越少控制权、越可能有厂商绑定;平台越可控,通常越吃团队运维能力。没有高级低级,只有这笔复杂度现在值不值。

---

## 一、四个台阶:不是成熟度排名,是复杂度价格表

可以把常见部署形态粗略看成四层:

```
   PaaS(平台即服务) / 托管应用平台
      → 最省心,适合 MVP / 小团队 / 标准 Web 应用

   托管容器平台(Managed Containers)
      → 仍然省心,但有容器和服务边界

   Serverless(无服务器计算)
      → 适合事件驱动、突发流量、后台任务

   Kubernetes / K8s(容器编排平台)
      → 控制力最强,也最吃平台能力
```

不要把这四层理解成「越往后越高级」。一个三人团队用 PaaS 稳稳上线,比自建 K8s 天天修集群更健康。反过来,如果你已经有几十个服务、多个团队、复杂流量治理,继续把所有东西塞进简单平台,也会变成瓶颈。

> **架构智慧:**选部署平台像选交通工具。去楼下买菜,自行车最好;跨城搬家,卡车最好。问题不在卡车是不是更先进,而在你是不是正在搬家。

---

## 二、什么时候 Kubernetes 值得上

Kubernetes 解决的不是「怎么运行一个容器」,而是**怎么管理一群不断变化的容器**:

- 调度:把容器放到合适节点。
- 扩缩:按负载增减副本。
- 服务发现:服务实例变了,调用方仍能找到它。
- 滚动发布:逐步替换版本。
- 自愈:实例挂了自动拉起。
- 资源隔离:限制 CPU、内存、权限。
- 声明式配置:描述目标状态,平台负责逼近目标。

它适合的信号通常是:

| 信号 | 说明 |
|---|---|
| 服务数量多 | 需要统一调度、发布、资源治理 |
| 多团队独立部署 | 团队之间不能互相排队发版 |
| 复杂流量治理 | 灰度、金丝雀、蓝绿、区域路由变成常态 |
| 需要混合云/私有化 | 要跨环境保持部署模型一致 |
| 有平台团队 | 有人把 K8s 封装成内部开发者平台,而不是让所有业务团队啃配置 |

如果你只是一个标准 Web 应用 + 一个数据库 + 一个队列,K8s 多半不是收益,而是负担。你会提前买下证书、Ingress(入口流量)、网络策略、镜像仓库、集群升级、权限控制、节点资源、可观测性这一整套复杂度。

---

## 三、Serverless:不是不用管服务器,而是换了一组限制

Serverless(无服务器计算)的价值是:

- 按需扩缩,低流量时成本低。
- 适合事件触发,比如上传文件后转码、定时任务、Webhook 处理。
- 团队少管机器,更多关注函数逻辑。

它的代价也明确:

- 冷启动:长时间不用后首次请求可能慢。
- 运行时限制:执行时间、内存、网络、依赖包大小都有边界。
- 可观测性和本地调试更难。
- 厂商绑定更强。

所以 Serverless 特别适合「短、散、事件驱动」的任务,不适合所有东西。把一个复杂长流程硬拆成几十个函数,没有工作流编排、trace 和重试纪律,会变成另一种难维护。

---

## 四、部署策略本身就是架构

部署平台不能只看「能不能跑」,还要看坏版本上线时怎么收场:

| 能力 | 要回答的问题 |
|---|---|
| **健康检查** | 平台怎么知道实例真的能接流量? |
| **回滚** | 新版本坏了,能不能快速回到旧版本? |
| **渐进发布** | 能不能灰度 / 金丝雀(Canary) / 蓝绿(Blue-Green)切流量? |
| **配置与密钥** | 配置、密码、证书是否和代码分离,并可审计? |
| **基础设施即代码**(IaC) | 线上资源是否可版本化、可审查、可重建? |

这就是为什么 GitOps(以 Git 作为运维事实源)重要:它把「线上应该长什么样」从人工点控制台,变成版本化、可审查、可回滚的声明。对小团队,这可能只是一份简单配置;对大组织,会变成平台工程的黄金路径。

> **架构智慧:**部署不是最后一步,部署是架构的一部分。一个不能快速回滚、不能定位版本、不能解释配置来源的平台,会把每次上线都变成赌博。

---

## 五、最稳的演进路径

```
   MVP / 单体阶段:
      托管应用平台 + 托管数据库 + 简单 CI/CD

   多服务阶段:
      容器化 + 托管容器平台 + 标准日志/指标/密钥

   多团队阶段:
      托管 K8s + 平台团队 + GitOps + 服务目录 + 权限治理

   强监管 / 私有化 / 混合云:
      K8s 或私有云平台,但必须接受更高运维成本
```

这条路径和 [04 章](04-十大核心架构模式.md) 的「单体优先」、[15 章](15-组织即架构.md) 的「平台工程」是同一件事:**先让业务跑起来,再把反复出现的运维复杂度收敛成平台能力。**

---

## 六、部署平台选型表

| 判断信号 | 更倾向的选择 | 为什么 | 警惕代价 |
|---|---|---|---|
| 1–5 人团队,MVP,标准 Web 应用 | PaaS / 托管应用平台 | 少操心,发布链路短,把时间留给业务验证 | 控制权少,迁移成本可能较高 |
| 单体或少量服务,需要环境一致性 | 托管容器平台 | 解决「我电脑能跑线上不能跑」,但不吞下 K8s 全套复杂度 | 仍要处理镜像、配置、日志、健康检查 |
| 多服务、多团队、独立部署 | 托管 Kubernetes | 统一调度、扩缩、发布、隔离和生态 | 没平台团队时,复杂度压到业务团队 |
| 事件驱动、突发流量、后台任务 | Serverless + 队列 | 按需扩缩,不用长期养机器 | 冷启动、限制、可观测性和厂商绑定 |
| 强监管、私有化、混合云 | 私有云 / 自管 K8s | 满足数据边界、合规、可移植性 | 运维成本最高,需要专职平台能力 |

---

## 🎯 随堂检验

<Quiz
  question="一个 4 人团队正在做第一个 SaaS MVP,只有一个后端服务、一个前端、一个数据库。大家想直接上自建 Kubernetes,理由是「以后肯定要规模化」。最合理的判断是?"
  :options="['直接上自建 Kubernetes,越早越专业', '优先选 PaaS 或托管容器平台,把发布、日志、数据库备份先跑顺;等服务数量、团队数量、独立部署需求真的出现,再评估托管 K8s', '不要部署到云上,必须买物理机']"
  :answer="1"
  explanation="MVP 阶段最稀缺的是业务验证速度,不是平台控制权。自建 K8s 会提前引入大量运维复杂度,但此时还换不到多团队自治、复杂调度、统一治理这些收益。"
/>

<Quiz
  question="评估一个部署平台时,最该优先问哪组问题?"
  :options="['它是不是最近最火、Logo 好不好看', '它能否支持健康检查、回滚、灰度发布、配置密钥管理、日志指标接入,以及团队是否养得起它的复杂度', '它能不能让我们完全不用写测试']"
  :answer="1"
  explanation="部署平台选型不是追热点,而是看它是否支撑生产发布和故障恢复。健康检查、回滚、渐进发布、配置密钥、可观测性和团队能力,才是架构判断里的核心变量。"
/>

---

## 本章小结

- **云原生不是工具清单**:核心是自动化、弹性、可恢复、可观测、可重复发布。
- **部署平台选的是运维模型**:省心 vs 控制权,简单 vs 可治理,低门槛 vs 平台能力。
- **Kubernetes 不是默认答案**:它适合多服务、多团队、复杂治理;小团队过早上 K8s 往往是过度设计。
- **部署策略是架构的一部分**:健康检查、回滚、灰度、密钥、IaC/GitOps 决定出事时能不能收场。
- **从简单开始,按信号升级**:先托管、再容器、再平台化,让真实痛点决定复杂度投入。

> **承上启下**:部署平台负责让系统跑起来、发得出去、坏了能退。下一章 [32 · 可观测性与可靠性技术栈选型](32-可观测性与可靠性技术栈选型.md),我们补上另一半:系统跑起来之后,你能不能看得见、叫得准、救得回。

---

## 相关链接

- 方法论本体:[04 · 十大核心架构模式](04-十大核心架构模式.md) · [06 · 质量属性与取舍](06-质量属性与取舍.md) · [12 · 为失败而设计](12-为失败而设计.md)
- 组织配套:[15 · 组织即架构](15-组织即架构.md) · [24 · 审查清单](24-审查清单AI产出默认缺什么.md)
- 案例对照:[PatchDesk](../cases/patchdesk-saas/README.md) · [CodePilot](../cases/codepilot-agent/README.md)