刷一条短视频、点一次商品、读一篇新闻……你看到的下一条内容，背后都有一只“看不见的手”在毫秒之间完成决策：召回→粗排→精排→干预→返回。这只手就是推荐系统的调度中枢。今天，腾讯云架构师技术同盟成员为你拆解如何从零到一、再到亿级流量，用 3 个阶段、9 张图、1 条 Trace 链路，把推荐调度做成可热插拔、可观测、可无限实验的平台系统。无论你是 1.0 的初创团队，还是 3.0 的大厂中台，都能在这里找到复制即用的演进路线。

关注腾讯云开发者，一手技术干货提前解锁👇

「腾讯云架构师技术同盟」是腾讯云为架构领域知名专家与从业精英打造的专业技术社交圈，通过多样的技术交流会议、社群专业探讨、权威内容输出，打造业界领先的架构师专业技术组织。同盟共创，携手同道，关注每一位中国架构师成长。

扫码报名加入

01、前言

日常生活中，类似场景无处不在：

1. 阅读新闻时，刚看完一篇就自动推送相关文章（"这篇看起来也不错"——忍不住又点开）
2. 浏览商品时，查看某件商品后立即出现相似推荐（"这件好像也挺好"——不自觉又点击查看）

不知大家注意到没，这些场景中的“它”，总是能精准捕捉我们的兴趣点，仿佛比我们自己更懂想要什么。

其实，这个神奇的“它”就是——推荐系统。

02、推荐是什么

2.1 推荐是什么

用一句话概括，推荐系统就是通过分析用户行为和数据，预测并推送你可能感兴趣的物品（item），从而提升（转化率/用户留存/购买量等）的核心技术。

根据功能定位，主要分为在线服务和离线计算。

• 实时处理用户请求
• 提供低延迟推荐响应
• 支持高并发访问
• 实现毫秒级推荐结果返回

结合策略、离线计算生成的基础数据（特征/索引/模型）以及实时上下文信息，快速分析并筛选出用户可能感兴趣的Item，最终完成个性化推荐。离线计算 - Offline Computation

• 周期性更新用户画像
• 进行大规模数据预处理
• 完成候选集预计算
• 训练和优化推荐模型

定期基于最新数据重新加工基础特征、模型或索引，为在线服务提供更新后的数据支持。

2.2 一个典型的推荐流程

一个典型流程通常包含以下关键环节：

标准招聘流程，同样遵循漏斗式筛选机制：确定需求→筛选简历→初试→复试→确定人选，（整体呈现金字塔结构，随着筛选标准逐级严格，候选人数呈指数级递减）。

2.3 整体感知

在建立对推荐系统的基本认知后，下面将通过一个精简架构图，系统性地梳理以下核心流程：

1. 数据流向：在线服务与离线计算的协同机制；
2. 调度逻辑：从召回到排序的完整决策链路。

（该示意图将帮助您直观理解各模块的交互关系与系统运作全貌）

从上面这张图上，我们可以观察到：

1. 每个推荐请求的处理实际是一个多系统协同工作的复杂过程；
2. 这些系统各司其职，有一个核心调度模块来统筹整个推荐流程的执行。

03、推荐是什么：深聊推荐调度中枢

本文重点探讨的正是这个扮演“中枢大脑”（Central Brain）角色的流程调度系统。

作为推荐引擎的核心协调者，它主要负责：

1. 流程编排：按照预设的推荐策略，有序调度召回、排序、干预等环节的执行；
2. 资源调配：合理分配计算资源，平衡效果与性能的诉求；
3. 策略执行：根据业务规则动态调整推荐逻辑；
4. 异常处理：监控各环节执行状态，确保推荐流程的鲁棒性。

这个调度系统既要保证各环节的高效协同，又要具备足够的灵活性来支持业务策略的快速迭代；

其设计质量直接影响着推荐系统的整体性能和实验效率。

3.1 不同视角的诉求

在系统开始设计前，我们不妨了解下干系方的诉求，这对于我们设计好系统至关重要。

3.2 系统进化

接下来我们分析公司不同阶段的适配方案（没有绝对优劣，关键要符合当前需求，避免过度追求复杂方案而导致与现有生产力脱节）。

3.2.1 推荐1.0阶段

背景：

公司目前只有几十人，数据量也很有限（相比xx的规模完全不在一个量级）

整体概览

小王接收到需求，设计了一个如下的系统：

小结

在算法同学较少、数据量不多情况下，我们接下来看上述不同视角的诉求是怎么最小化满足的

3.2.2 推荐2.0阶段

背景：

随着公司规模扩大，扩充了推荐团队，但实际数据量变化没那么大

小王通过NPS了解到系统主要问题：

实验迭代效率低【公司采用双周发版制，对算法额外开放单周发版权限，仍无法满足快速实验验证的需求】； 实验流量资源紧张【一群人抢流量：小A To 小B：你实验做完了没？给我点流量呗】； 问题排查效率低下【老板：为什么给我推荐的是这双鞋？小C：我看下哪路来的，扒了半天代码和日志】

整体概览

优化后如下：

系统监控

核心分析框架：

1. 宏观视角监控 - 提供整体运行态势的可视化呈现（如：展示所有实验桶及其运行状态） - 重点关注场景维度的聚合指标（如：各实验桶的健康度、吞吐量等）
2. 微观维度钻取 - 支持实验桶的组成分解（包含的具体实验及其配置） - 实现单个实验粒度的详细运行诊断（成功率、耗时等指标）

（该设计遵循从全局到局部的排查逻辑，与问题诊断的自然思路保持一致）

小结

在当前算法团队规模持续扩大，但数据量没明显变化的情况下，我们来探讨：如何有效满足前文所述的多维度需求？

3.2.3 推荐3.0阶段

背景：

公司壮大了，推荐团队组织本身和业务数据量均有成倍的增长，另外算法同学对编排灵活性以及策略复用度有了进一步要求

小王设计的系统此刻主要矛盾：

• 流量资源紧张【实验6层结构，每层可承载的实验数量已达上限】； • 召回能力受限【数据规模与多样性持续增长，即使采用最高配置的机器，内存仍成为瓶颈】； • 实验框架僵化【现有6层结构无法灵活调整，部分业务场景可能需要更少或更多层级】； • 策略复用性差【大量重复逻辑散落在不同策略中，修改维护成本高，影响迭代效率】

整体概览

优化后如下：

图执行

核心执行机制要点：

• 节点状态管理
  • 每个算子节点维护明确状态：待执行、执行中、执行成功、失败、超时等
• 自动触发机制
  • 节点完成执行后自动触发其后继节点的运行
• 执行依赖控制
  • 后继节点启动前需校验所有前序关联节点是否均达到终态（成功 / 失败 / 超时）
  • 避免因部分前序节点未完成导致的非预期执行
• 并行执行能力
  • 所有满足执行条件的节点均支持并行运行

Trace链路

核心设计思想：

1. 可视化流程监控
   1. 实现全流程状态可视化呈现，包括：
      1. 正常执行路径。
      2. 异常情况（错误/超时等）。
      3. 通过不同颜色标识的线段区分各类状态。
2. 一体化数据观测
   1. 集成所有基础数据与日志数据展示。
   2. 提供统一观测页面，消除多系统切换需求。

小结

在算法同学大幅增多、数据量成倍增长情况下，我们接下来看上述不同视角的诉求是怎么满足的。

04、总结与展望

通过不同阶段的进化（主要是系统用户/数据量的增长），调度中枢主要面临两大核心挑战：

1. 稳定性保障（基础数据应该如何存放？策略出问题时候该怎么处理？甚至场景挂掉该怎么办等）；
2. 效率优化（开发/测试/发布效率、以及问题排查效率） 其中稳定性层面：首先需要保证基本的场景可用性，这点是需要提前着手的；效率层面：一个完善的AB平台，与流量分配、实验姿势等息息相关。这两点前期需要花费比较大的心思，其他功能可采取渐进式迭代优化。

后续做细致还是有不少点的：比如dag图的剪枝/优化、cpu的利用率提升等。

欢迎大家一起交流探讨！

-End-

原创作者｜程红星