31 · 云原生与部署平台选型
一句话点题:云原生(Cloud Native)不是「上 Kubernetes」,而是把部署、扩缩、回滚、观测、故障恢复做成一套可重复的工程能力。部署平台选型,本质是在问:你的团队现在值不值得为这些能力支付复杂度。
🧰 技术栈选型篇第 5 章 · 本章只练一件事
30 章 讲服务之间怎么通信。本章往下看一层:服务到底跑在哪里,怎么发布、怎么扩容、怎么回滚、谁来值班。小系统要的是少操心,大系统要的是可控和自治;选错平台,每天都在交复杂度税。
开场:你选的不是机器,是运维模型
新人常问:
用虚拟机,还是容器?
用 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 章 的「单体优先」、15 章 的「平台工程」是同一件事:先让业务跑起来,再把反复出现的运维复杂度收敛成平台能力。
六、部署平台选型表
| 判断信号 | 更倾向的选择 | 为什么 | 警惕代价 |
|---|---|---|---|
| 1–5 人团队,MVP,标准 Web 应用 | PaaS / 托管应用平台 | 少操心,发布链路短,把时间留给业务验证 | 控制权少,迁移成本可能较高 |
| 单体或少量服务,需要环境一致性 | 托管容器平台 | 解决「我电脑能跑线上不能跑」,但不吞下 K8s 全套复杂度 | 仍要处理镜像、配置、日志、健康检查 |
| 多服务、多团队、独立部署 | 托管 Kubernetes | 统一调度、扩缩、发布、隔离和生态 | 没平台团队时,复杂度压到业务团队 |
| 事件驱动、突发流量、后台任务 | Serverless + 队列 | 按需扩缩,不用长期养机器 | 冷启动、限制、可观测性和厂商绑定 |
| 强监管、私有化、混合云 | 私有云 / 自管 K8s | 满足数据边界、合规、可移植性 | 运维成本最高,需要专职平台能力 |
🎯 随堂检验
- A直接上自建 Kubernetes,越早越专业
- B优先选 PaaS 或托管容器平台,把发布、日志、数据库备份先跑顺;等服务数量、团队数量、独立部署需求真的出现,再评估托管 K8s
- C不要部署到云上,必须买物理机
- A它是不是最近最火、Logo 好不好看
- B它能否支持健康检查、回滚、灰度发布、配置密钥管理、日志指标接入,以及团队是否养得起它的复杂度
- C它能不能让我们完全不用写测试
本章小结
- 云原生不是工具清单:核心是自动化、弹性、可恢复、可观测、可重复发布。
- 部署平台选的是运维模型:省心 vs 控制权,简单 vs 可治理,低门槛 vs 平台能力。
- Kubernetes 不是默认答案:它适合多服务、多团队、复杂治理;小团队过早上 K8s 往往是过度设计。
- 部署策略是架构的一部分:健康检查、回滚、灰度、密钥、IaC/GitOps 决定出事时能不能收场。
- 从简单开始,按信号升级:先托管、再容器、再平台化,让真实痛点决定复杂度投入。
承上启下:部署平台负责让系统跑起来、发得出去、坏了能退。下一章 32 · 可观测性与可靠性技术栈选型,我们补上另一半:系统跑起来之后,你能不能看得见、叫得准、救得回。
相关链接
- 方法论本体:04 · 十大核心架构模式 · 06 · 质量属性与取舍 · 12 · 为失败而设计
- 组织配套:15 · 组织即架构 · 24 · 审查清单
- 案例对照:PatchDesk · CodePilot
💬 评论