扩一次容，不只是多开几台机器
想象一家餐厅会按客流增减桌位。普通餐厅搬几张桌子就行；但如果每张桌上都摊着尚未结账的订单，调整座位前还得保存、搬运并恢复这些记录，动作就会慢很多。
流处理平台也有类似难题。Apache Flink 是处理持续数据流的开源引擎。任务要长期接住不断到来的数据，自动扩缩容（autoscaling）则根据负载增减计算资源：配得太多，机器长期闲置；只按平均流量配置，流量突增时又会出现积压。
Netflix Technology Blog 披露，截至 2026 年，公司仍在生产环境同时运行两套 Flink autoscaler，并逐步向 Apache Flink 社区的开源方案收敛。两套系统并存并非简单的重复建设，而是平台历史与工作负载变化共同留下的结果。本文事实均来自 Netflix 单一机构信源，相关规模、时间与结论没有独立材料交叉印证。
第一套，是没有现成答案时自己造的
Netflix 称，公司自 2017 年开始使用 Flink，约在 2019 年开发了第一套 autoscaler。当时没有适合其平台的成熟方案，自研是现实选择。
如今，这个平台的规模已经很大。据 Netflix 自报，它在多个 AWS 区域运行超过 30,000 个 Flink 作业。多数作业由托管平台 Data Mesh 自动生成，绝大多数用户不需要直接操作 Flink。换句话说，平台团队面对的不是少数工程师手工照看的任务，而是一批数量庞大、需要自动管理的长期作业。
这些作业的负载还会随每日周期、产品发布和区域故障切换而波动。若所有作业都按峰值准备资源，会造成浪费；若只按平均负载准备，突发流量又可能让数据越积越多。到这个规模，靠人逐个调节已经不现实。
供稿片段在第一套 autoscaler 的技术细节处截断，因此无法进一步说明它依据哪些指标决策、怎样预测资源需求，或实际节省了多少成本。
第二套，补的是旧系统没打算覆盖的范围
后来，Apache Flink 社区提供了另一套 autoscaler。Netflix 称，这套开源方案能处理其自研系统从未设计支持的工作负载，因此公司把它引入生产环境。
这里的关键是工作负载已经分化。一端是简单的单算子作业——可以理解为只做一步处理，例如在 Kafka topic 之间搬运记录；另一端则是包含分支、join（把不同数据流按条件合并）以及数 TB 状态的复杂 pipeline。Netflix 还有一批规模较小但持续增长的自定义作业，用于 personalization、Ads 和 Live events 等场景。
所谓“有状态”，是说计算不能处理完一条数据就忘掉，还要保留累计计数、窗口结果或用户会话等历史。扩缩容时，这些状态必须重新分配到新的工作节点，不能只开关机器。
Netflix 默认的扩缩容流程是先创建 savepoint——一份可用于恢复作业状态的保存点——再优雅停止作业，最后按新的并行规模重启。大型有状态作业完成一次调整可能需要数分钟。也就是说，扩容本身有代价：如果判断不准或动作过于频繁，保存、传输和恢复状态的成本，可能抵消增加资源带来的收益。
两套系统真正暴露了什么
这段经历最值得关注的，不是“自研还是开源”谁天然更好，而是基础设施会随平台一起变旧。第一套系统解决了当年没有成熟方案的问题，却也被当时的工作负载边界塑形；后来出现的新任务超出这条边界，社区方案才成为补充乃至收敛方向。
它也提醒人们，流处理扩缩容不是简单的资源预测题。系统不仅要判断任务需要多少资源，还要考虑调整一次要付出多少迁移成本。规模越大、状态越重，错误决策的代价越明显。
Netflix 目前选择逐步向开源方案靠拢。这意味着维护两套基础设施本身也构成成本。但材料没有披露迁移比例和时间表，因此这更像一个正在进行的平台演进，而不是已经完成的替换。
局限与未知
- Netflix 没有公开两套 autoscaler 的具体覆盖范围、决策算法和效果指标，无法比较它们的准确率或成本收益。
- “超过 30,000 个作业”“数 TB 状态”等数字均为 Netflix 自报，材料未给出统计口径、快照日期或原始数据。
- 公司只说会逐步收敛到开源方案，尚未披露完整迁移计划，也无法判断旧系统何时退出生产环境。