如何设计一个推荐调度系统：算法平台核心架构

原创于 2025-08-26 08:45:54 发布 · 661 阅读

4 ·

CC 4.0 BY-SA版权

文章标签：

#架构

部署运行你感兴趣的模型镜像

👉目录

1 前言

2 推荐是什么

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

4 总结与展望

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

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

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

扫码报名加入

01

前言

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

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

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

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

02

推荐是什么

2.1 推荐是什么

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

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

分类	职责	备注
在线服务 - Online Service	实时处理用户请求提供低延迟推荐响应支持高并发访问实现毫秒级推荐结果返回	结合策略、离线计算生成的基础数据（特征/索引/模型）以及实时上下文信息，快速分析并筛选出用户可能感兴趣的Item，最终完成个性化推荐。
离线计算 - Offline Computation	周期性更新用户画像进行大规模数据预处理完成候选集预计算训练和优化推荐模型	定期基于最新数据重新加工基础特征、模型或索引，为在线服务提供更新后的数据支持。

2.2 一个典型的推荐流程

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

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

2.3 整体感知

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

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

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

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

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

03

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

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

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

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

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

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

3.1 不同视角的诉求

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

视角	分类	详述
工程同学《关键词：稳定》	【稳定性】系统运行是否稳定可靠	系统部署方案需要综合考虑以下因素： 1. 场景特点：￮包含多个主场景和若干小场景，重要性各不同￮流量规模较大￮ RT（响应时间）受策略复杂度和数据量影响显著￮不同场景对召回失败的敏感度不同（如瀑布流场景需要支持近似无限刷） 2. 部署目标：￮资源利用率最大化￮系统稳定性保障￮关键场景的容错能力（特别是对召回率敏感的场景）
	【可观测性】实验过程是否易于监控和管理	1. 多路实验中，哪些实验的RT较高且容易超时？（大促期间常用手段：对实验进行降级，包括关闭实验或减少召回数量等） 2. 哪些实验的运行效果未达预期？（例如：某实验预期召回50个结果，但实际召回仅30个左右）需要让算法同学能够及时发现这些异常情况，以便快速采取干预措施。
	【性能表现】系统处理能力是否高效	例如在召回环节中，当数据量级较小时，召回数据量对效果有显著正向影响；但当超过一定阈值后，收益会逐渐递减。因此需要考虑以下几个问题： 1. 数据存储方案的优化 2. 召回耗时问题，包括：检索耗时 / RPC传输耗时 / 数据解压缩耗时等
算法同学《关键词：效率》	【实验效能】实验迭代速度是否达标	推荐策略本身没有绝对的最优解，只有在特定阶段相对更有效的方案。算法工程师的日常工作就是通过持续实验来验证策略效果：包括调整参数、优化策略、观测数据指标等。当策略在观察周期内呈现正向效果时，就会逐步扩大流量或全量上线；若效果不理想，则终止实验并尝试其他方案
算法同学《关键词：效率》	【资源分配】流量分配策略是否科学合理	这里存在一个矛盾：系统总流量有限，但我们需要进行更多实验。一方面，为了保证实验数据的可信度，流量分配比例不能过小；另一方面，为了快速筛选出较优策略并持续迭代，又需要尽可能多地尝试不同方案。

3.2 系统进化

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

3.2.1 推荐1.0阶段

背景：

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

整体概览

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

小结

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

视角	关注点	ACTION	备注
工程同学	【稳定性】系统运行是否稳定可靠	部署层面，场景隔离【依据场景重要性区分：独立部署/混合部署】	稳定性这块不大建议妥协，尤其注意避免非关键场景影响到核心场景
	【可观测性】实验过程是否易于监控和管理	可以观察的是系统qps/rt等，太细的比如单独某一路等不方便	某一个召回策略的还不大容易观察，耦合较重
	【性能表现】系统处理能力是否高效	基础数据放内存	服务内存要留有一部分buffer用于数据更新，总不能先clear再put吧！
算法同学	【实验效能】实验迭代速度是否达标	实验跟随系统，周期发版	算法同学少，迭代数量不多
算法同学	【资源分配】流量分配策略是否科学合理	简单AB实现	人群简单分流，垂桶实验差不多够了

3.2.2 推荐2.0阶段

背景：

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

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

实验迭代效率低【公司采用双周发版制，对算法额外开放单周发版权限，仍无法满足快速实验验证的需求】；

实验流量资源紧张【一群人抢流量：小A To 小B：你实验做完了没？给我点流量呗】；

问题排查效率低下【老板：为什么给我推荐的是这双鞋？小C：我看下哪路来的，扒了半天代码和日志】

整体概览

优化后如下：

系统监控

核心分析框架：

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

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

小结

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

视角	关注点	ACTION	备注
工程同学	【稳定性】系统运行是否稳定可靠	依据场景重要性区分：独立部署/混合部署
	【可观测性】实验过程是否易于监控和管理	最细维度（“策略级别”）的监控 + 时光机	1. 有了最细维度的“抓手”，方便算法同学实时干预； 2. 时光机，其实就是记录vip人物的推荐细节，查询时候图形化展示每一步的相关item
	【性能表现】系统处理能力是否高效	基础数据放内存
算法同学	【实验效能】实验迭代速度是否达标	采用“热加载”形式，支持实验随时上线	1.实验流程标准化解耦 • 采用分层架构设计，将原有耦合代码拆分为6个独立层级（注：融合层为可选组件，支持按需裁剪策略，相关合并操作可在执行阶段完成） • 各层级策略间无依赖关系，支持并行执行（配备超时熔断机制保障系统稳定性） 2. 动态构建能力建设 • 实现算法引擎的实时打包部署能力 • 支持实验策略的热更新机制，确保策略迭代零延迟
算法同学	【资源分配】流量分配策略是否科学合理	建设AB平台，引入多种多样的分流策略	垂直实验 + 分层正交试验

3.2.3 推荐3.0阶段

背景：

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

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

• 流量资源紧张【实验6层结构，每层可承载的实验数量已达上限】；

• 召回能力受限【数据规模与多样性持续增长，即使采用最高配置的机器，内存仍成为瓶颈】；

• 实验框架僵化【现有6层结构无法灵活调整，部分业务场景可能需要更少或更多层级】；

• 策略复用性差【大量重复逻辑散落在不同策略中，修改维护成本高，影响迭代效率】

整体概览

优化后如下：

图执行

核心执行机制要点：

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

Trace链路

核心设计思想：

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

小结

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

视角	关注点	ACTION	备注
工程同学	【稳定性】系统运行是否稳定可靠	依据场景重要性区分：独立部署/混合部署
	【可观测性】实验过程是否易于监控和管理	运行时的过程具像化【Trace链路】	“鸟瞰图”，可观察整体，也可以深入局部
	【性能表现】系统处理能力是否高效	数据外置（C++引擎）	其他选择：es、redis等
算法同学	【实验效能】实验迭代速度是否达标	摒弃6层固化配置，支持灵活编排【DAG图】	将策略分解成算子，提升复用度
算法同学	【资源分配】流量分配策略是否科学合理	支持配置实验	结合上述的灵活编排，再加上对参数进行配置实验，差不多类似无限层实验了

04

总结与展望

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

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

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

欢迎大家一起交流探讨！

-End-

原创作者｜程红星

感谢你读到这里，不如关注一下？👇