7.2 云原生：立体车场与弹性调度

7.2 云原生：立体车场与弹性调度

第二款新型列车改的不是车，是车场。云原生把"服务器"从需要申请、装机、照料的固定资产，变成可编程、可生灭的调度资源——平面车场升级成立体车场，车位随班次自动增减。本节讲容器与编排改变了什么、弹性伸缩的经济学怎么算、上车前要补的底盘，最后顺带看一眼智能化工具正在改写哪些工位。

从平面车场到立体车场

传统部署的痛点不在功能在环境：应用与操作系统、依赖库、配置盘根错节，"我机器上能跑"成为工程界的千年梗；扩容要走采购装机流程，流量洪峰来了只能干瞪眼。云原生用三层改造解决：

• 容器：把应用连同运行时打包成标准化"车厢"——在任何车场上都能直接挂接，环境不一致被物理消灭；
• 编排调度：车场的自动调度系统——车厢挂了几路、挂在哪条线、挂多少节，声明好期望状态，系统自动对齐；车厢故障自动拉起新的，流量高峰自动扩编；
• 基础设施即代码：车场本身也用代码描述（第 2.5 节的实践），环境从"申请来的"变成"生成出来的"，分钟级重建。

图 7-2：平面车场与立体车场的调度对比

弹性伸缩的经济学

弹性伸缩常被讲成技术炫技，其实是一笔清楚的账：传统模式按峰值备资源，峰值一天只有几小时，其余时间全部闲置；弹性模式按当前负载付钱，洪峰临时扩编、退潮即时缩编。云梯的账单对比：

[演算] 云梯对账服务 · 资源账单对比

负载特征：每月月末三天为峰值，其余时间为均值的两成。
  峰值需要 12 个计算单元，均值只需 2 至 3 个。

传统固定备机：
  按 12 单元常备（冗余另计）
  月成本 = 12 单元 × 30 天 单价

弹性伸缩：
  平日 2 至 3 单元 × 27 天 + 峰值 12 单元 × 3 天
  月成本 ≈ 2.5 × 27 + 12 × 3 = 103.5 单位天
  对比固定 = 12 × 30 = 360 单位天
  节省 ≈ 七成

代价（写进账本的成本）：
  伸缩策略要调：扩太慢压站，缩太快抖动
  冷启动延迟：扩编的新车厢要几秒到几十秒才能接客
  可观测要求提高：车是流动的，日志指标要能跟着车厢走
​

结论不是"弹性永远省"——负载平稳的服务，弹性省不了几文钱，反而白交复杂度学费。负载波动大、可预测性差的服务才是弹性的目标客户。

智能化工具：新工位上新的人机分工

顺着装备升级往下看，智能化辅助正在改写几个工位的分工表：代码补全与生成助手在装配线上替人打下手（作者仍对每行代码负责，走查标准一寸不让）；智能巡检开始读日志找异常模式，给运维值夜班减负；测试用例生成尝试从需求文本里提候选场景，产出仍需测试员按边界值法复核。把这些工具当"新工位的自动化"看待最稳妥——第 6 章的原则原样适用：机器干重复的，人干判断的，机器的产出同样要过检测线。

⚠️ 云原生最大的误区是把"上云"当终点。云原生是一套能力（容器化、声明式、可观测、自动化），云只是承载——没有这些能力的服务器搬上云，只是把贵的手工换了个地方。

资源配额与成本哨兵

弹性车场最大的新风险是"看不见的账单"——资源按秒计费后，浪费从"机房里闲着的服务器"变成"配置文件里多写的两个零"。治理要靠配额与哨兵：命名空间配额给每个服务划定资源上下限，防止单个服务的配置失误吃光全场资源；成本哨兵每天汇总各服务的实际用量与申请量，申请远大于用量的（申请八核常年只用两核）自动开单降配。云梯上线成本哨兵的第一季度，账单降了三成——降下来的不是业务，是当初"宁多勿少"的粗放申请。弹性时代节约的功夫从采购谈判移到了配置评审，功夫没少，只是换了地方。

容量规划：弹性也要算账

"反正会自动扩"是弹性车场最危险的口头禅。弹性兜的是短期波动，兜不住趋势性增长——流量半年翻了五倍，自动扩容只会忠实地把你扩到账单爆炸。容量规划在云原生时代没有消失，只是换了形态：定期用压测校准"单个计算单元的承载水位"，据此推算下一季度的资源预算与成本曲线；给扩容设预算上限告警——自动扩容触顶时通知人而不是无限扩张。机器负责秒级的伸缩，人负责季度级的容量，分工清楚，账单与性能才同时在线。

无状态与有状态：车厢的两种脾气

编排调度顺利与否，取决于你有没有分清车厢的两种脾气。无状态服务（算完即走，不记得上一个请求）最听话——随时生灭、随意搬家、坏一个补一个，弹性伸缩就是为它们发明的。有状态服务（数据库、消息队列、带本地会话的应用）是另一种生物——它们记得东西，搬走之前要安排好"记忆"的去处。新手最贵的错误是把有状态应用当无状态调度：实例一漂移，用户会话全丢；存储卷跟不上，扩出来的新实例读到空数据。改造的次序因此明确：先把会话外置、把文件上对象存储、把本地缓存换成集中缓存，让应用尽量变得无状态；真正有状态的部分（数据库等）交给专门的运维形态，不与无状态车厢混编。这一步分不清，弹性就是灾难的加速器。

两个高频疑问

问：数据也要"云原生化"吗？ 存储的云原生要分外谨慎。无状态的计算层可以随意生灭，数据层的每次迁移都要考虑兼容、备份与回滚——"数据库跟着应用一起容器化"在多数业务里是把最不该流动的东西放上了传送带。务实的分界：缓存与队列大胆弹性，主数据存储求稳，跨区容灾单独立项。

问：智能化运维工具能替代值班吗？ 能替代的是值班的重复段：告警收敛、常见故障的预案执行、巡检报表。替代不了的是预案之外的第一响应——新故障模式的判断、止损与破案的取舍。把智能化当"值班的副手"最稳：它把常规事件处理完，把真正需要人的复杂情况连同整理好的上下文一起递过来。工具接管得越多，剩余人岗的能力要求反而越高，培训预算要跟着涨。

本节要点回顾

• 容器消灭环境不一致，编排把期望声明变成自动对齐，基础设施即代码让环境可生成。
• 弹性伸缩的经济账：负载波动大才省得多，平稳负载不值得交复杂度学费。
• 冷启动延迟与伸缩策略调优是弹性的内含成本，账要提前算。
• 智能化工具是新工位的自动化：机器打下手，人守判断，产出照过检测线。
• 底盘四件套不齐别硬上：代码化、容器制品、可观测、会用调度系统。
• "上云"不是终点，能力才是。

车型车场都升级了，最后一节给全线路铺上连续安保。