计算机系统中的控制

服务流量上升后，扩容决策可能已经发出，而新实例仍在启动。若控制器把“已经请求的容量”当成“已经可用的容量”，或反过来忽略待生效动作，就容易产生错误判断。本篇用简化模型连接采样与延迟、约束与鲁棒性。

先选对状态与单位

令 $q_k$ 为时刻 $k$ 的等待请求数，${\lambda }_k$ 为到达率（请求/s），单实例处理能力为 $\mu$（请求/s），$n_k$ 为实际可用实例数，步长 $\Delta t$ 为秒。一个流体近似是

$$q_{k+1}=\max \{0,q_k+\Delta t({\lambda }_k-\mu n_k)\}.$$

它把工作量当作可连续分割、实例同质、服务能力固定；没有逐请求的服务时间、在途任务、重试、失败或负载均衡细节。因此可以解释积压变化，不能直接输出真实 p99 延迟。

取 $\mu =10$、$n=4$、$\lambda =70$，每秒增加30个等待请求。若新容量20 s后才生效，期间就可能积压600个请求。最终扩到7个实例只做到到达与处理相等，已有积压不会自动下降；还需要额外容量或流量回落。

决策、命令与生效是三个时间点

一个简化容量建议可以写成

$$n_k^{\ast }=\lceil \frac{{\hat{\lambda }}_k+q_k/T_{\mathrm{clear}}}{\mu }\rceil .$$

${\hat{\lambda }}_k$ 是估计到达率，$T_{\mathrm{clear}}>0$ 是希望清理积压的时间。前一项匹配新流量，后一项安排消化旧积压。取到达70、积压600、$T_{\mathrm{clear}}=30$，需要 $(70+20)/10=9$ 个实例，而不是7个。

这是一条教学策略，不是 Kubernetes HPA 的实现，也没有对任意延迟的稳定保证。实际命令还会受到最小/最大实例数、每次变化上限、启动延迟与缩容约束影响。若每次建议9个都错误地“再增加9个”，就连控制量的绝对值与增量也混淆了。

流量在20–100 s从20增至70请求/s，然后回到20；每10 s决策一次，每实例10请求/s，最多12个实例。控制器使用当前流量与积压，命令在指定延迟后按顺序生效。分别显示建议数、命令数和可用数；缩容窗口在历史建议中取最大值。这个对称生效延迟是教学简化，真实扩容和缩容不一定具有相同动态。

平滑策略付出了什么？

容差忽略小幅指标变化，稳定窗口利用近期建议避免立即反向调整，速率限制约束一次或一段时间内的容量变化。这些措施可能减少抖动，也会推迟响应或增加空闲成本。窗口不是平均滤波的同义词：取历史最大值和取均值是不同策略。

Kubernetes HPA 按周期读取指标并调整期望副本数，其基础比例关系为

$$n_{\mathrm{desired}}=\lceil n_{\mathrm{current}}\frac{m_{\mathrm{current}}}{m_{\mathrm{target}}}\rceil .$$

官方算法还处理容差、缺失指标、尚未就绪的 Pod、多指标选择以及扩缩行为。缩容稳定窗口参考窗口内的最高建议，并不是简单要求“连续若干次都低于目标”。具体字段与默认值需按部署版本核对。HPA 官方机制

积压、利用率和延迟不能互换

低CPU利用率可能来自I/O等待，高CPU利用率也不必然等于请求排队。平均延迟与尾延迟取决于服务时间分布、调度与负载等因素。没有合适模型时，用一种指标直接换算另一种会把测量误差引入反馈。

在适当的稳定、长期平均条件下，Little 定律联系系统内平均数量、有效通过率与平均逗留时间。它不能用来把一次瞬时队列长度除以瞬时流量就称为p99。后续排队论将讨论这些条件；这里的状态更新只做工作量收支。

如何迁移到 TCP 与硬件？

TCP以ACK、丢包、RTT或ECN等信号调整发送行为，反馈存在网络往返延迟；不同拥塞算法的状态与控制律并不相同。把所有TCP写成PID，会丢掉协议细节。回看TCP时，可以标出观测、状态和动作，保留原算法。

电源电路则通过电压/电流测量调整功率级，能量储存和补偿网络形成动态。跨领域迁移的是建模与分析方法，不是同一组增益。

自检

70请求/s到达，单实例10请求/s，积压600个。扩到7个实例后会在多久清空？

延长缩容稳定窗口一定更好吗？

实践检查

记录原始指标时间戳、采样时间、决策时间、命令与实际可用时间；检查待执行动作是否会重复计算。回放正常流量、突发、持续过载、冷启动与指标缺失，分别报告积压、成本和动作频率。测试中的良好表现支持该条件下的行为判断，不是对所有工作负载的稳定性证明。