随着时间的推演,老旧架构面临着那些经典的问题:可用性差,服务不稳定;扩展性差,开发周期长,迭代效率低;200 多个代码仓库,300 多万行代码,编程语言、协议混用……
叠加上推荐算法的时代命题,如何对腾讯新闻的推荐架构做升级成了业务进一步发展的内在要求。本文从业务场景介绍入手,详细介绍了腾讯新闻推荐架构升级过程中的目标设定,架构设计和实践过程,值得仔细品阅,转发点赞收藏一键三连。
01
02
内容创作门槛较高,内容的供给主要存在于专业化的团队、因而内容的多样性比较差,集中度比较高,原因是内容创作机构也自然而然的按照品类进行了衍生,各大机构倾向于在自己擅长的品类里面深耕。 内容消费的渠道比较多元,纸媒、电视、PC(各个媒体的官网),消费呈现出很强的地域性特点,但是内容消费的品类比较单一,大家的消费主要集中在热点内容上,当然这跟内容的生产效率是有直接相关性的。
随着智能手机功能的增强和网络资费的下降,内容消费的渠道逐步收缩到了移动端,用户的消费呈现出多元化; 内容创作的门槛下降,信息几何倍数增加,消息触达用户的效率大幅提升,但是用户获取有效信息的效率下降;
热点无法第一时间触达用户,相比于早年可预期的热点运营,由于消费渠道和流量的集中,很多热点的爆发呈现出了很强的随机性,很容易通过微博等关系引擎引爆,原有的人工运营的模式无法第一时间跟进并且做出差异化。 由于运营偏向于定制化,后端系统架构过于分散,缺乏复用性,需求迭代的效率受到了严重的制约。 场景分立的系统导致了整体的可用性压力比较大。 整个机器的运营成本也比较高。
03
可用差,事故频发:可用性不足99%,21年线级别的事故超过 xx 次。 可扩展性差,开发周期长,迭代效率低:一个需求联动前后端多个模块,数十位开发, 拉大群,开大会,一开2、3小时,联调效率低,开发周期超过一个月。 成本高昂:推荐架构成本超过了 xxw/m,线全年机器运营成本接近 x 个亿。 问题排查效率低,实验效率低,系统的可解释性差:定位一个系统问题,横跨多个工具, 占用各个环节研发人力,实验迭代周期长,很多需求不经验证直接上线。
场景多,策略多,服务多:400+场景,1000+策略,2000多个物理服务(包含存储引擎),场景之间复用程度低,基础设施不统一。 仓库多,代码多,语言多,协议多,代码质量差,发布流程不规范:200多个代码仓库, 300多万行代码,php,c++,golang,java,python 混用,brpc,http,grpc 协议混用, 单测覆盖率极低,不足10%,分支开发,随意打包镜像发布线上环境。 内容种类多,时效多,特征多,使用混乱:小视频、短视频、长视频、问答、专题、事 件、微博、cp 等10多种分发介质,几十种分发时效,内容侧特征1000多个,画像侧特征 1000多个,特征生产链路私搭乱建,特征存储零星分布,各类 redis 数百个。 工具庞杂,九龙治水,控制不收口:各类运营工具,几十个运营工具干预线上分发逻辑。 监控缺失,告警缺失:没有一个端到端的监控页面,主端的核心二级频道缺少监控和告警,靠产运人工发现系统问题反馈。
04
05
时效性不足:倒排打分更新和文章入池受限于定时任务的间隔,延迟短则十几分钟,长则数个小时。 扩展性不足:受限于单个物理机的内存,无法横向扩容。 成本高:由于各个物理池,读写负载差异很大,导致分割的小集群利用率偏低。 可用性差:采用 crontab 的任务调度,rsync 离线文件传输来更新,发布效率低,数百个物理池,运维难度大,监控无法面面俱到,可用性不足99%。 问题排查效率低:10多种介质,300多个场景,几十种时效(短则数小时长则2年种类繁多),没有易用的排查手段,基本靠人工,刀耕火种,很多问题得不到解答。
时效性提升:批处理升级为流式更新。 扩展性提升:采用主从分片的方式,提升横向的扩展性。 成本控制和可用性:统一的集群服务,资源共享,统一监控。
数据一致性问题:流式更新过程中丢消息带来的数据偏移问题。 性能问题:高强度读写并发的情况下,如何保证延迟的稳定。 迭代效率问题:统一分布式索引的架构下,如何同时满足不同业务场景的实验诉求。
更新频繁,动态特征秒级更新。 索引有序,拉链独立打分。 范围查询频繁。
在线 cpu 核数由 xxx 核下降至 xxx 核,节省了62% 在线内存由 xxT 下降至了 xxT,节省了30% 集群的平均耗时由 xms 下降至 xms,节省了61% 亿次 pv 的调用成本 xx 元,下降至 xx 元,节省了63%
召回类型多样(倒排、模型、协同、生态等),服务众多。 业务召回占比高,业务逻辑多变,实验频次高。 访问的波动性强,受热点事件影响大。 场景统一控制规则多,例如:场景统一时效,质量等级等。
性能差。 召回效率低。 控制不收口,迭代效率低。
中控模块的网络扇出,下降了20% 召回模块的整体的cpu利用率下降了10% 倒排类召回的召回效率提升了30% 修改场景过滤规则上线效率由天级减少到分钟级。
半在线推拉结合的架构,拉活占腾讯新闻 DAU 的 xx% 周期性计算,计算密集度高,资源敏感,吞吐相对可控。 可分发集合小,保持在 xxw 量级之间。 时效性跟用户微信活跃时间相关,直接影响拉活效果。
时效性差,小时级更新。 可维护差,多个加工任务。 成本高,多个 redis。
新文章入库时效从小时级到分钟级,提升了90% 24小时内曝光文章占比提升了 xx%,每天拉活用户 uv 增加 xxw+ 索引整体成本,下降了40%
运营对内容的掌控力强、实验灵活。 链路复用性差、成本高、服务运维难度大。 内容时效差,入库延迟小时级、天级。
服务运维难度大幅下降,成本下降显著,节省90% 运营无法感知内容变化,规则上线耦合开发人力。 pv 级别的查询过滤运算,在线成本高,影响服务稳定性。
供给和分发解耦,运营所见即所得。 内容实验效率,周级别提升至天级,优化了80% 索引需求开发效率提升,策略修改分钟级生效。 在线索引过滤性能提升,节省 cpu12%
迭代效率低,抽取逻辑没有统一规范,上线新的特征,需要修改多个模块,需要3天以上的开发周期。 特征不一致,依赖的元数据在时间上有差异,各个模块自己维护的抽取逻辑,存在不一致。 特征缺乏管理,由于抽取逻辑的分散,特征上线较为随意,同时使用上溯源困难,特征只增不减,线上特征超过2000+。 可用性差,上线新的特征需要频繁重启,在线服务,代码异常容易引发稳定性问题;离线样本链路缺乏管理,特征生产时常断流。 成本高,采用了抽取后落盘的方式,跨模型,跨模块实验无法复用,在线精排阶段需要抽取大量的实验特征,cpu 核数超过 xxw 核,成本超过 xxxw。
特征生命周期管理 模型配置管理 特征进退场管理 特征监控 特征溯源 特征实验 高效特征服务 算子化 通用抽取库 模型打分组件(TF 和无量) 特征上报 明文样本流 样本生成 通用离线抽取框架 FM
原始数据(画像、正排、用户行为)生产和使用不收口。 没有统一的在线特征服务框架,各模块各自为战。 缺乏通用的算子化和配置化抽象,开发耗时高。 没有明确的研发流程指引。
借力打力,模块化治理。 内容侧特征生产和使用收口至正排服务。 用户侧特征收口至画像平台。 用户行为收口至大同。 提供多场景的特征服务框架,满足不同场景的特征服务诉求。 集成了ispine框架支持业务和抽取流程算子化、配置化。 依托平台,制定统一的研发流程规范,简化算法上线流程,涉及在线服务的部分由工程统一治理,保证质量和效率。
抽取逻辑的不一致,离在线抽取逻辑以及在线各个模块抽取逻辑分散维护,产生的不一致问题。 元数据有差异,预估时刻和样本生成阶段原始数据不一致。
抽取逻辑的一致性解决方案:
元数据的一致性保证
用户特征一致性:在线特征服务采用了 TraceID 级别的缓存,缓存用户侧画像和 context 内的动态行为信息。 内容特征一致性:中心化的 Item 级别的缓存,通过 Item+timestamp 来进行内容级别的缓存。 路由一致性:在线通过一致性 hash 回调的方式,来进行 featureDump。
核心抽取库的性能,直接影响了离在线抽取的性能。 特征抽取流程优化,大量模型实验,模型之间特征重合度,高达90%以上,避免重复抽取是影响性能的关键。 网络优化,如何减少明文现场带来的网络开销,是性能优化的关键。
特征众多,以精排模型为例特征数量 xx 个,一次排序600-1000篇文章,37.5w-50w 次的计算。 数据结构不合理,智能指针大量的引用计数,内存对象包含动态类型,内存构造析构频繁,一次精排调用至少进行了 37.5w 次。 存在大量的重复计算,在特征服务内部计算会分 batch,每个 batch 里面 User 侧的特征存在重复计算的问题。 存在冗余计算的问题,抽取配置是模型特征的超集。
特征众多的问题:建立完善的特征评估和进退场机制,及时下线无用特征,提升在线抽取效率。 冗余和重复计算问题:打通新闻特征平台和无量之间的模型配置,避免无效的特征抽取;优化计算流程,一次请求分 batch,user 侧特征只抽取一次。 减少动态内存申请和释放:采用内存池实现对象的复用;特征使用 POD 类型,可以字节复制(memset,memcopy) ,内存对齐,计算友好;使用原始指针替换智能指针。 采用中心化缓存的方式,存储重的特征现场,同时通过请求回调的方式避免冗余数据写入,来实现网络资源的优化。 按照场景设置 namespace,namespace 内部共享样本抽取流程,一次抽取多模型使用。
特征抽取库的性能提升了一倍,抽取阶段耗时下降了50%。 CPU利用率相对下降39%,优化了 xx 核。 精排打分出口 avg 下降 xxms,节省了23%,推荐引擎的出口耗时 avg 下降了 xxms,p99.9耗时下降了 xxms。
对于终端用户的可解释性(简单,易懂,高度抽象) 对于系统参与者的可解释性 (详细,全面,直击要害)
新闻是一个运营和个性化并重的信息流产品,内容供给和推荐涉及的环节众多,横跨多个团队 新闻延续了之前腾讯网的架构,上百个场景独立部署,几百个代码仓库,代码不能主干开发,数据采集和上报各自为战,数据缺失严重。 原有的 Debug 工具各个模块自建,面向模块自身,而非面向业务场景,导致工具庞杂,上下游无法串联。 数据的实时性不够,关键消费数据的更新只能做到 T+1,且维度单一。 针对推荐侧有状态的模块例如(分布式索引、画像、曝光),缺乏有效的 Debug 手段和工具。关键数据的呈现采用原始 KV 的方式,可读性差,易用性低。 针对开发人员缺少必要的模拟请求、结果分析的工具。 增长(Push、插件)、主端推荐,存在重复建设的问题。 由于推荐系统的复杂性,成为了产品、运营和技术之间的鸿沟,问题发现往往在产品和运营侧,问题的定位往往在技术侧,问题排查占用了非常多的研发人力。
设计一套全新的数据采集协议和数据采集架构,提升数据的准确性和时效性。 面向业务场景设计 Debug 链路,而非面向模块,打通上下游。 深入理解平台用户诉求,结合业务场景优化体验,提升易用性。 合理设计离在线架构,降低对于业务系统的影响,优化存储效率节省成本。 工具收敛,一站式定位问题。 通过平台的建设,发现新闻推荐系统的问题,推动新闻推荐架构升级。 在解决好新闻自己问题的同时,抽象出通用的推荐引擎白盒化能力反哺BG内的其他类似场景,推动整个平台演进至 BG 乃至行业内领先的水平。
30天内任意内容,秒级可查,可追溯,在线消费核心指标分钟级更新。 3小时后,在线任一用户 Trace,分钟级回捞,实时可查。 负反馈信息实时采集,自动抽样,一站式分析。
异常请求识别,网关限流。 完善的降级流程和操作手册。 方便的人工介入能力,一键生效。 各阶段柔性降级,层层兜底。 针对可预见热点的快速扩容机制。 完善的监控和告警机制建设,第一时间发现问题,解决问题。 联动123平台,解决基础设施稳定性问题,例如:容器负载不均,网络拥堵、单节点异常等。
06
代码规范: 大仓的开发模式,统一代码标准:单侧覆盖率大于70%,圈复杂度小于5,代码重复率小于8%。 统一协议规范,采用 BG 的 trpc-cpp 协议,替换原有的 brpc、http 等。 发布流程规范: 所有在线服务发布均接入蓝盾流水线,执行严格的单测、diff 流程。 二进制灰度能力建设,建立了金丝雀发布机制,保证端到端的稳定性。 策略灰度能力,基于方圆策略平台建设了策略灰度能力,避免错误配置引起全线崩溃。 问题排查流程规范: 打通伽利略监控到 oncall 平台的通路,自动提单,故障 MTTR<60分钟。 针对重点场景建设了监控大盘并制定了相应的问题排查手册。 通过企微建立了 slo 长效的跟踪机制,及时发现及时响应。 需求开发流程规范: 所有的需求开发均接入 Tapd 需求管理平台,通过 Tedi 平台进行迭代效率的监控,及时发现问题,保证迭代效率。 建立规范的需求价值衡量机制,避免无效需求对于系统架构的侵蚀。 引入技术评审机制,避免垃圾设计对于存量系统的影响。
07
本文由高可用架构转载。技术原创及架构实践文章,欢迎通过公众号菜单「联系我们」进行投稿