在电商和导购类平台里推荐系统的实时性几乎决定了用户的下单转化率。用户滑到某个商品卡片系统必须在几百毫秒内判断“该不该推”“推哪个”背后依赖的是一整套从实时特征计算到模型在线推理的链路。这篇文章我会完整拆解一套我参与设计的导购平台商品推荐引擎架构基于Flink做实时特征工程配合TensorFlow Serving承载在线推理把用户从点击行为发生到推荐结果返回的延迟压到500毫秒以内。我会从整体设计思路、核心细节、实操过程、踩坑记录四个维度展开尽量把每一步“为什么这么做”讲透适合正在搭建或重构推荐系统的工程师参考。1. 整体设计与思路拆解1.1 为什么推荐引擎需要实时特征工程传统的推荐系统大多走离线链路凌晨用Spark批处理把前一天的用户行为、商品热度、类目偏好算好写入特征库白天在线服务直接读取。这种做法在商品动销率不高的平台够用但放到导购平台场景下就有明显问题。导购平台的特点是“人找货”和“货找人”并存用户决策周期短情绪化点击多。昨天用户看了某款口红但没买今天早上另一款同色系口红突然因为某篇种草文火了离线特征根本感知不到这个变化。用户的实时兴趣漂移、商品瞬时热度、当前场景的上下文信息这些通通需要在秒级甚至毫秒级完成计算并反馈到推荐结果里。我接手这套引擎时产品方给的核心指标有两个推荐结果点击率提升至少15%用户从点击行为到刷出下一次推荐结果的响应时间不超过800毫秒。离线特征体系只能做到T1更新点击率天花板明显响应时间倒是够但效果有限。要想突破只能上实时链路。Flink在这里扮演的角色就是“实时特征计算引擎”它负责把Kafka里源源不断的用户行为事件流、商品信息变更流、库存价格变更流做流式关联、窗口聚合、特征拼接最后把计算好的特征实时写入在线存储供推理服务读取。整套链路里Flink不是唯一的组件但它是所有实时特征计算的中枢。1.2 Flink与TensorFlow Serving分工的本质边界很多团队在做推荐系统时容易陷入一个误区试图让Flink去做模型推理或者让TensorFlow Serving顺带把特征拼接也干了。这两种做法我都见过也都在生产环境里踩过坑。Flink擅长的是无界流处理它的状态管理、事件时间处理、窗口机制、checkpoint容错都是为“持续不断的数据流计算”设计的。但Flink不适合做高并发的单条请求推理因为模型推理需要的是低延迟、高吞吐的服务能力这正好是TensorFlow Serving这类专用推理服务器的强项。TensorFlow Serving的优势在于模型版本管理、热加载、自动批处理dynamic batching、基于gRPC的高效通信。它只做一件事——接收特征向量返回预测分数。但它不负责特征计算你把原始行为日志直接塞给TensorFlow Serving没有任何意义模型要的是拼接好、清洗好、规整成固定维度的特征向量。所以整个架构的本质分工是Flink负责“从原始事件到可用特征”的流式加工TensorFlow Serving负责“从特征向量到预测分数”的高性能计算。中间的桥梁是一个在线特征存储通常用Redis或者阿里的Tair这类kv存储Flink算好的特征写进去推理服务启动时读出来拼装成完整向量。1.3 方案选型背后的对比与取舍在定这个架构之前我对比过几套替代方案这里把选型逻辑记录下来方便后来人参考。第一套备选方案是“纯Spark Streaming Redis PMML在线推理”。Spark Streaming的微批模式延迟在秒级对于导购场景的实时性要求来说偏慢而且Spark Streaming的本质是批处理状态管理和窗口计算不如Flink灵活。PMML虽然能做到跨平台模型部署但只支持逻辑回归、GBDT这类传统模型深度学习模型完全没法走这条路。第二套备选方案是“Flink Flink ML 自研推理服务”。Flink ML在做在线学习方面确实有潜力但当时它的生态成熟度还不足以支撑生产级在线推理尤其是深度学习模型这块Flink ML的算子覆盖远不如TensorFlow完整。第三套就是最终采用的“Flink TensorFlow Serving”。这套组合的优势在于Flink的实时计算能力和TensorFlow Serving的专用推理能力都是各自领域经过大规模验证的两者之间通过特征存储解耦各自可以独立扩容和升级。缺点是需要维护两个分布式系统运维成本更高但这个代价换来的实时性和灵活性在当时看来是值得的。2. 实时特征工程的核心细节与实操要点2.1 事件接入层Kafka Topic的设计与序列化选型实时特征工程的起点是行为事件接入。我们当时在Kafka里按事件类型建了多个Topicuser_click用户点击、user_view商品曝光、user_collect收藏、user_cart加购、order_create下单、item_info_change商品信息变更、price_change价格变动、stock_change库存变动。Topic分得细有几个好处一是下游Flink作业可以按需订阅不需要消费全量数据再过滤二是不同事件的吞吐量差异很大点击数每秒上万条下单数每秒可能只有几十条分开建Topic方便分别调整分区数和消费并发。序列化方案我们用了Avro配合Confluent Schema Registry做Schema管理。当时很多团队直接用JSON我看过他们的生产环境最大的痛点是字段变更时下游作业全部要跟着改稍有不慎就出现反序列化异常。用Avro之后Schema演进方便很多字段新增和废弃都有明确的兼容性规则。这里有一个实操细节很多人忽略Flink消费Kafka数据时如果使用Avro序列化建议在Flink作业里指定专用的DeserializationSchema而不是用Flink自带的GenericRecord。直接转成POJO对象可以让后续的算子逻辑清晰很多也能利用Flink的类型系统在序列化时拿到更优的性能。2.2 窗口计算与状态管理用户实时兴趣画像的构建推荐引擎里最重要的实时特征就是用户当前的兴趣向量。我采用的方案是Flink的滑动窗口加KeyedState实现。具体做法以userId为key开一个10分钟长度、5秒滑动一次的窗口统计用户在这段时间内点击过的商品类目分布、价格带分布、浏览过的店铺List。窗口计算用Flink的增量聚合函数每次只保留聚合结果不缓存窗口内的所有明细数据避免状态量过大。窗口计算得出的类目分布是一个稀疏向量比如“美妆0.6、服饰0.2、数码0.2”这个向量会直接写入特征存储的user_realtime_profile字段。推荐服务读取这个字段时就能知道这个用户此刻的兴趣重点在哪个类目上。但滑动窗口有一个问题窗口长度固定用户兴趣变化的速度不一致。有人逛了5分钟就下单有人逛了一小时还在犹豫。我当时用了一个折中的办法同时维护多个不同时间长度的窗口特征3分钟短期兴趣、15分钟中期兴趣、60分钟长期兴趣三个维度的特征拼接在一起让模型自己学习不同场景下应该更相信哪个时间尺度的信号。状态管理方面Flink的KeyedState默认使用RocksDB作为状态后端时会有序列化和反序列化开销但对大状态场景几乎是唯一选择。我的建议是如果每个用户的状态只有几KB且并行度不高用FsStateBackend配合Heap就可以如果用户量大、状态量大就必须上RocksDB同时把state.backend.rocksdb.memory.managed配置调大避免频繁的磁盘IO。2.3 维表关联实时拼接商品画像的关键路径实时特征不能只算用户侧商品侧的实时属性同样关键。商品标题、类目、品牌、价格、库存这些信息变化频率不高但会在关键时刻影响推荐结果——比如某个商品突然降价了它应该立即获得更高的推荐权重。Flink关联维表有几种常见方案查外部存储Redis或MySQL、广播维表、异步IO。我最终用的组合是高频维表走广播流低频维表走异步IO查Redis。广播维表的适用场景是维表数据量不大几万条以内、更新频率不高、但每条数据都需要跟主数据流做关联。我们的商品基础信息维表虽然总量有几十万条但热门商品的子集大概两万条符合广播的条件。将这份热点商品维表做成BroadcastStream每个并行子任务都保存一份全量数据关联时纯内存查找速度快且不依赖外部存储。低频维表走异步IO这里的“低频”指的是关联操作不是每条事件都触发比如用户在浏览一件衣服时我需要顺带查一下该店铺的30天销量和评分这个数据放在Redis里用Flink的AsyncFunction异步发起查询配合连接池和超时控制可以显著提升吞吐。实操时有一个坑不得不提维表关联的时间对齐问题。广播维表是定期更新的更新前后同一个key可能关联到不同的值。如果关联的特征用于模型打分这个不一致性会导致特征跳变。解决方案是给维表数据加一个version时间戳写入特征存储时记录版本号服务端读取特征时如果发现同一批特征里版本不一致以多数版本为准或者丢弃该次推荐。2.4 特征存储选型与特征拼接的细节特征存储是整个实时特征工程和在线推理的中转站。我们用的是Redis Cluster主要看中它的读写延迟低、集群模式支持水平扩展。Redis中key的设计遵循一个原则特征按不同的粒度拆分避免大key。用户粒度特征key是rec:user:{userId}:profile商品粒度特征key是rec:item:{itemId}:profile上下文特征key是rec:ctx:{scene}:{date}:{hour}。每个key的value都是一个Hash字段名是特征名字段值是特征值。Hash结构的优点是推荐服务读取特征时可以只取自己关心的字段不需要反序列化整个对象。缺点是字段多了之后内存开销大。所以特征数量控制在每个key不超过50个字段超过的部分拆到第二个key。特征拼接的细节在推理侧但特征存储侧已经决定了拼接的效率。我当时的做法是让Flink把同一用户的所有实时特征聚合到一个Redis key里推理服务一次MGET就能拿到所有在线特征再加上离线服务预取的静态特征拼成完整向量只需要几毫秒。关于特征拼接还有一个容易忽略的坑特征字段的顺序。TensorFlow Serving的模型输入是固定的FeatureSpec训练时定义了什么顺序线上推理就必须一模一样。所以Flink写特征存Redis时要按模型特征清单的字段顺序来不能随意调整否则推理结果会打折扣。3. 在线推理架构的搭建与核心环节实现3.1 TensorFlow Serving的部署与模型管理TensorFlow Serving的部署本身不复杂我踩过的坑都在模型管理、版本控制和生产调优上。模型训练完成后导出为SavedModel格式这是TensorFlow Serving唯一认识的模型格式。导出时需要指定serving_input_receiver_fn它定义了线上推理时输入张量的结构。我建议在导出时就把特征向量的维度和dtype定死不要用变长输入变长输入会显著增加推理服务的调度开销。我们当时用的是Docker部署TensorFlow Serving的官方镜像直接拉下来把模型目录挂载到容器里。模型目录里按版本号建子目录models/rec_model/1、models/rec_model/2、models/rec_model/3TensorFlow Serving启动时会自动扫描目录并加载最高版本的模型。这里的版本控制有个细节TensorFlow Serving默认加载最高版本模型但新版本上线前需要灰度验证。通过配置model_config_list可以精确控制加载哪些版本配合一个简单的流量切分逻辑——将小部分请求带上model_versionx的标签发到指定版本验证通过后再切全量。线上模型的更新频率也是一门学问。推荐模型我建议不要频繁更新每天更新一次就够了太频繁会导致线上效果波动而且难以评估是模型更新贡献的还是实时特征贡献的。我们的节奏是凌晨离线训练早上6点自动部署新模型这样平台用户高峰期始终用的是当天最新的模型。3.2 推理服务的请求-响应链路优化用户请求进入推荐服务后完整链路是接收请求、解析用户上下文、从特征存储拉用户实时特征和商品特征、拼接成模型输入向量、通过gRPC调用TensorFlow Serving、拿到预测分数、按分数排序过滤、返回推荐列表。这条链路每一步都可能成为瓶颈我逐项优化过。gRPC调用的超时设置为50毫秒超过直接降级用离线分返回兜底避免用户长时间等待。连接池大小设置为TensorFlow Serving最大并发数的1.5倍充分利用其多线程模型。TensorFlow Serving自带的动态批处理器Dynamic Batching值得好好研究。它会把一小段时间窗口内的多个请求合并成一个batch一次性喂给模型推理充分利用GPU或CPU的向量化能力。但批处理会增加第一个请求的等待时间需要权衡。经过压测我将batch_timeout_microseconds设置为3000微秒即最多等3毫秒就发出批次这样单请求延迟只增加几毫秒但整体吞吐提升约30%。3.3 GPU与CPU的选型取舍TensorFlow Serving的推理硬件选型要看模型复杂度和QPS要求。我们的模型是DeepFM加上部分注意力结构embedding维度不算大单次推理耗时在CPU上约8毫秒这个量级其实不需要上GPU。GPU适合的场景是单次推理耗时超过20毫秒、QPS要求极高、且模型结构复杂比如包含大尺寸Transformer结构。GPU的优势在于并行计算吞吐高但推理延迟不一定比CPU低因为引入了数据拷贝和kernel launch的开销。导购推荐场景的模型通常不会太重用多核CPU实例配合动态批处理反而性价比更高。我们最终用的是8核16G的容器实例每个实例部署一个TensorFlow Serving显式设置了CPU线程数为4并发数上限为200。容量规划是按照高峰期QPS的2倍冗余配置确保大促时不会被打垮。3.4 模型全链路一致性验证这部分是最容易被忽略的。特征工程在Flink侧计算模型在TensorFlow侧训练两边各干各的如果特征计算逻辑和训练时的特征处理逻辑不一致再好的模型也是白搭。我要求算法团队在训练时把特征处理的代码流程完整记录下来包括缺失值填充方式、归一化参数均值和方差、类别特征的映射字典。这些元信息统一存放在配置中心里Flink作业和推理服务都从配置中心读取同一份配置。上线前必须做一致性校验取当天的真实日志数据离线批量跑一遍特征工程得到离线特征同时把日志同速回放到Flink作业里得到在线特征然后比较两者差异。误差允许在万分之一以内超过这个阈值就需要排查原因。4. 常见问题与排查技巧实录4.1 Flink作业停止消费或延迟飙高的排查Flink作业最常见的故障是消费延迟持续上涨这个问题的排查思路我总结成一个固定流程。先看Kafka的消费组Lag指标确认到底是Flink没拉数据还是拉了数据但处理不过来。Flink这边看Web UI的Backpressure状态和繁忙程度如果subtask显示HIGH状态说明处理能力到瓶颈了再看GC日志如果频繁Full GC多半是状态后端有问题。状态后端的坑我遇到过一次典型场景大促期间用户量暴增每个人维护的窗口状态数据量翻了好几倍RocksDB的写放大导致磁盘IO成瓶颈。当时紧急调整了并行度从32扩到48同时把Sink端的写入批量加大延迟从叶秒级降回了秒级以内。还有一个隐蔽的坑Checkpoint超时导致作业反复重启。Checkpoint interval设置了60秒但超时时间默认只有10分钟。大促时状态量大一次checkpoint可能要8分钟勉强能过后来加了一次维度表和状态的数据增大checkpoint直接超时作业不断把状态回滚到上一个checkpoint形成恶性循环。后来把timeout调整成20分钟同时优化了RocksDB的压缩策略才算稳定。4.2 TensorFlow Serving内存泄漏与OOMTensorFlow Serving本身比较稳定但长时间运行后大概率会遇到内存持续上涨的问题。排查时我先用jstat观察堆内存变化发现Old区占用量只增不减GC后无法回收。后来定位到是动态批处理模式下请求张量的生命周期过长。查了官方文档确认是默认配置下请求队列的容量过大导致积压的请求张量占用了大量堆内存。调整方案是显式设置max_batch_size和batch_timeout_microseconds同时把模型加载数量从多个版本改为只保留最新两个版本。这个问题的隐藏风险在于内存泄漏不会立刻引发OOM而是逐渐蚕食堆内存最终在高峰期触发OOM导致容器重启。容器的自动重启机制虽然能快速恢复但这段时间的请求全部走了降级策略推荐质量大幅下滑直接影响当天的转化率指标。所以对推理服务的监控要特别关注老年代内存的增长趋势设置合理阈值提前预警。4.3 特征不一致引发的线上效果波动这应该是推荐系统最让人头疼的问题了。现象是模型刚上线那两天效果很好第三天开始点击率逐日下滑无论是回滚模型版本还是重新部署效果都回不到上线初期的水平。排查了几天才找到元凶Flink作业在凌晨重启时消费Kafka的offset没有对齐导致部分用户的行为事件没有被计算进特征。这些用户的实时兴趣画像还停留在重启前的状态而模型的输入分布变了打分结果自然就偏了。这类问题防不胜防我后来干脆写了一版特征自检工具在Redis里对每个用户存一个特征最后更新时间字段如果发现某个用户的特征停留时间异常地长就自动触发一次该用户的特征重算。另外在Flink作业重启流程里强制加入offset校准步骤先暂停消费、确认checkpoint完成、再启动新作业从代码层面杜绝这类隐患。4.4 常见问题速查表问题现象排查方向解决方案Flink消费延迟持续上涨查看subtask繁忙度、GC日志、RocksDB IO调整并行度优化状态后端配置增大批量Checkpoint反复超时失败查看checkpoint大小和耗时曲线调大超时时间优化增量checkpoint策略推理响应时间突然变长看TensorFlow Serving的CPU和内存瓶颈调整动态批处理参数扩容推理实例推荐结果明显偏离用户近期行为检查实时特征是否长时间未更新自检工具主动重算修复offset对齐问题模型更新后效果剧烈下降对比新旧版本的特征分布和评分分布灰度切流快速回滚排查特征一致性问题Redis连接数打满检查Flink异步IO连接池和推理服务连接池大小调整连接池上限增加Redis集群分片数5. 一些经验心得整套系统从设计到上线耗时两个多月中间踩了很多坑最后稳定运行后的架构比最初的设想简化了不少。一个很深的体会是实时推荐系统的难点不在于单个技术组件有多强而在于所有组件拼接处的一致性。Flink侧保证的是“特征算得准”TensorFlow Serving保证的是“分数推得对”但两端一旦出现口径不一致整个系统就会出现各种玄学故障。所以我在团队里立了一个规矩每个特征从定义、计算、存储到模型消费必须有一个唯一owner来负责端到端的正确性任何一环的改动都要全链路回归验证。另外关于团队配置一个能跑通且稳定的实时推荐系统至少需要一个精通Flink流式计算的数据工程师、一个熟悉TensorFlow Serving部署和模型调优的算法工程化工程师、一个能写高质量在线服务的后端工程师。这三个角色缺一不可指望其中任何一个人包揽全部都不现实。最后说一个可以继续扩展的方向目前这套架构里Flink只负责了特征计算事实上Flink还可以承担实时样本生成和在线学习的职责把用户实时的反馈闭环到模型的增量更新中。这块我当时因为精力原因没有深入但架构上是完全兼容的Flink产出的实时样本可以作为在线学习的输入训练好的增量模型再通过TensorFlow Serving的热加载机制无缝切换这样整个推荐系统就拥有了真正意义上的自我进化能力。有条件的团队建议往这个方向走实时推荐系统的最终形态一定是“感知-计算-推理-学习”一体化的。