腾讯新闻推荐架构升级：2 年、 300w行代码的涅槃之旅

腾讯云开发者

发布于 2024-06-06 09:45:54

3551

发布于 2024-06-06 09:45:54

程序员最大的幸福是看到自己的代码跑在千万人的设备上，程序员最大的不幸是去维护千万人设备背后的老代码。腾讯新闻，是一个有着十多年历史、海量用户规模的经典业务，其背后的系统走过了门户时代，走到了推荐算法时代。随着时间的推演，老旧架构面临着那些经典的问题：可用性差，服务不稳定；扩展性差，开发周期长，迭代效率低；200 多个代码仓库，300 多万行代码，编程语言、协议混用…… 叠加上推荐算法的时代命题，如何对腾讯新闻的推荐架构做升级成了业务进一步发展的内在要求。本文从业务场景介绍入手，详细介绍了腾讯新闻推荐架构升级过程中的目标设定，架构设计和实践过程，值得仔细品阅，转发点赞收藏一键三连。

01、前言

我们先来简单回顾下腾讯新闻的发展历程，腾讯新闻源于03年成立的门户网站腾讯网，成立之初，抓住了中国互联网崛起的东风，位列四大门户（搜狐、新浪、网易）之一；2010年伴随着智能手机的普及，也抓住了移动互联网普及的浪潮，第一批推出了腾讯新闻的客户端，经过了一系列交互和内容的创新，于2014年移动端的用户数更是达到了峰值的 DAU2.5亿，位列资讯类 APP 第一位，一度也达到了应用总榜的第一，这是截止到当时唯一触达榜首的资讯类 APP，由于这些傲人的成绩，腾讯新闻在2015年强势拿到了腾讯集团的“名品堂”，该奖项授予那些曾经影响到腾讯集团发展历程的里程碑式的应用，应该算是腾讯新闻最高光的时刻，时至今日腾讯深圳总部大楼上高悬的还是腾讯新闻的 logo：

万事万物的发展，基本都要遵循生命周期的规律，一个互联网产品也会遵循一定的发展曲线，经历了2015年的高光时刻，自身业务逻辑的膨胀以及外部环境的变化，腾讯新闻也迎来了生命周期上的阵痛期，业务形式和技术架构都要求拥抱变化。

02、腾讯新闻业务介绍

2.1 发展阶段

谈到腾讯新闻的业务，我的理解里面大致将他划分为三个阶段：

第一个阶段：我把它称之为以类目为索引的橱窗式内容陈列阶段，这也是所有门户网站的内容组织形式，就像一个大的“内容超市”，你会看到各类内容，按照一个大的分类体系（按照颗粒度不同少则几十大则几百上千）来组织内容然后呈现给用户：

分类体系示意

这个阶段的持续时间，我们对应到腾讯新闻发展的历史进程之中，大概是在2003-2020年，但是我认为这个阶段在2015年之前是比较成功的，2015年之后就有所变化，为什么会这么说，我个人感觉这跟互联网内容生产的模式息息相关，在2015年之前互联网的内容生态呈现如下的特点：

内容创作门槛较高，内容的供给主要存在于专业化的团队、因而内容的多样性比较差，集中度比较高，原因是内容创作机构也自然而然的按照品类进行了衍生，各大机构倾向于在自己擅长的品类里面深耕。
内容消费的渠道比较多元，纸媒、电视、PC（各个媒体的官网），消费呈现出很强的地域性特点，但是内容消费的品类比较单一，大家的消费主要集中在热点内容上，当然这跟内容的生产效率是有直接相关性的。

因而各家门户之间比拼的更多的是运营的功力，如何能够更快的覆盖热点，能够提供独家内容的消费渠道。腾讯新闻在内容运营方面是符合这个时代的特点的（“打造精品，自我变革”），同时发力移动端也比较早，因而在这个阶段获得了快速的发展。

第二个阶段：我把他称之为个性化引擎驱动的瀑布流阶段；这个阶段的开始源于个性推荐资讯类 App 的盛行，从时间节点上看，我觉得应该在2015年左右，但是腾讯新闻真正将个性化分发能力作为一个重点发力的时间点大概在2020年。这个阶段的主要特点是：

随着智能手机功能的增强和网络资费的下降，内容消费的渠道逐步收缩到了移动端，用户的消费呈现出多元化；
内容创作的门槛下降，信息几何倍数增加，消息触达用户的效率大幅提升，但是用户获取有效信息的效率下降；

由于信息量陡增，原有新闻擅长的精细化运营的模式，受到了极大的冲击，所以在2016-2020这个时间段，新的内容生产模式跟新闻原有的运营方式以及组织架构产生了摩擦，应该算是一个阵痛期，陆续涌现出了一些问题：

热点无法第一时间触达用户，相比于早年可预期的热点运营，由于消费渠道和流量的集中，很多热点的爆发呈现出了很强的随机性，很容易通过微博等关系引擎引爆，原有的人工运营的模式无法第一时间跟进并且做出差异化。
由于运营偏向于定制化，后端系统架构过于分散，缺乏复用性，需求迭代的效率受到了严重的制约。
场景分立的系统导致了整体的可用性压力比较大。
整个机器的运营成本也比较高。

从2021年开始，虽然当时业务上还存在一些摇摆，但是从架构上我们确立了以推荐引擎驱动的分发模式，因而也正式开启了长达2年的系统架构升级之路。

2.2 业务分类

虽然整个腾讯新闻里面场景众多，从细分来看超过了400个场景，但是从底层本逻辑来看，我们可以将所有场景总结为两大类：

个性化推荐的场景：

该类场景的特点是：所有系统的请求由用户主动触发，由于用户的作息和使用手机的习惯存在差异，因而请求数量存在周期性规律，同时由于所有请求由用户主动行为触发，因而活跃用户占比较高。同时，为了提升用户的消费行为，我们也会倾向于使用更加复杂的模型，同时由于热点事件的热点事件影响大，业务场景多，策略的复杂度高，整个系统以消费深度和留存作为主要的优化目标。

个性化推送的场景：

该类场景的特点是：请求通过系统触发，覆盖的用户量级极大，不活跃用户占比高超过正常水平，计算密集度高 QPS 超过数十万，需要兼顾时效性和个性化，以拉活和拉新为主要目标。

03、新闻推荐架构升级的背景

在展开架构升级的过程之前，我们先来思考两个核心的问题：

1、当我们的产品处于一个高频、多变的迭代之中的时候，我们如何才能保持我们系统架构的生命力？

常见的架构设计问题

各个场景的产运是路上行驶的各种规格的车辆，我们的系统就是一条条的公路，优秀的架构升级不是要大家不开私家车改坐公交车（放弃业务逻辑独立的系统统一），也不是给每辆私家车修建一条专属道路（业务主导系统建设，成本高昂，养护不易），而是建设一条公共的高速公路（逻辑复用），合理架设桥梁，安置信号灯（控制收口），让各类车辆，往来穿梭，并行不悖（高并发）。

2、判断一个系统架构好坏的评价标准是什么？

可用性：主要是指一个系统在满足功能要求的前提下，在一定时间内正常运行的程度，我们可以用如下的公式来定义：

可用性是衡量一个系统健康度的最基础的指标，可用性存在问题，其他指标也就无从谈起。

可扩展性：主要是指系统处理增加的负载、用户数量、数据量或复杂业务逻辑的能力，一个扩展性好的系统架构，在应用上述问题的时候，不需要进行频繁的重构或者替换。可扩展性是系统架构能够长期有效运行并满足未来需求的关键衡量指标。良好的扩展性设计使得系统能够在不牺牲性能和稳定性的前提下，适应不断变化的业务迭代需求。

可运维性：主要是指系统在运行过程中的运营成本、以及进行维护、升级以及 bug 修复的难易程度，通常包含几个方面的要求：整个系统的可解释性、可测试性、文档完整度、配置化程度、自动化、容错性以及可监控性等。

了解了前面提到的两个核心问题，我们带着这两个核心问题，来观测升级前的腾讯新闻整体的架构：

老的架构示意

我们可以看到腾讯新闻是一个迭代非常频繁的业务产品，同时原有的架构延续了门户网站时代：水平分层，场景自治的设计理念，该设计在早期以运营为主体的阶段，给了产品和运营团队极大的灵活性，但是到了当下个性化引擎驱动的时代，就暴露了很多的问题，我们从上面提到评价系统架构的三个标准层面去看，可以看到以下的问题：

可用差，事故频发：可用性不足99%，21年线级别的事故超过 xx 次。
可扩展性差，开发周期长，迭代效率低：一个需求联动前后端多个模块，数十位开发，拉大群，开大会，一开2、3小时，联调效率低，开发周期超过一个月。
成本高昂：推荐架构成本超过了 xxw/m，线全年机器运营成本接近 x 个亿。
问题排查效率低，实验效率低，系统的可解释性差：定位一个系统问题，横跨多个工具，占用各个环节研发人力，实验迭代周期长，很多需求不经验证直接上线。

为什么老的架构适合个性化驱动的业务诉求，个性化引擎由于引入了模型打分，为了使得系统能够快速的逼近当下的最优解，往往迭代速度会更加的迅速，链路也相对会更长；同时，新闻是一个发展超过了20年的老业务，在发展过程中累积了相当的历史债务，主要体现在如下方面：

场景多，策略多，服务多：400+场景，1000+策略，2000多个物理服务（包含存储引擎），场景之间复用程度低，基础设施不统一。
仓库多，代码多，语言多，协议多，代码质量差，发布流程不规范：200多个代码仓库， 300多万行代码，php，c++，golang，java，python 混用，brpc，http，grpc 协议混用，单测覆盖率极低，不足10%，分支开发，随意打包镜像发布线上环境。
内容种类多，时效多，特征多，使用混乱：小视频、短视频、长视频、问答、专题、事件、微博、cp 等10多种分发介质，几十种分发时效，内容侧特征1000多个，画像侧特征 1000多个，特征生产链路私搭乱建，特征存储零星分布，各类 redis 数百个。
工具庞杂，九龙治水，控制不收口：各类运营工具，几十个运营工具干预线上分发逻辑。
监控缺失，告警缺失：没有一个端到端的监控页面，主端的核心二级频道缺少监控和告警，靠产运人工发现系统问题反馈。

04、新闻推荐架构升级的目标和演进路线

4.1 目标

有了前面的铺垫，我们可以用一句话，来概括我们架构升级的目标：在保证业务逻辑独立性的前提下，实现架构的复用，提升系统架构的健壮性（保证用户体验）、可扩展性（提升迭代效率）、可运维性（降低维护成本）。

这里面有个非常核心的前提，“保证业务逻辑的独立性”，为什么这个前提很重要，因为我们从历史经验来看，很多公司技术路线演进过程中，是牺牲掉了部分业务逻辑独立性换来的。比如，早些年业界提出了“大中台，小前台”的中台架构理念，但是随着时间推演，业务蓬勃发展下，业务逻辑独立性的诉求逐步增加，中台逐步成为了限制业务独立发展的枷锁，这也就不难理解最近，业界又开始拆中台的风潮了。

于我个人而言，我不反对建设一个技术中台，但是这里面有个很重要的原则，就是我们要来定义什么样的组件适合成为一个中台，以及业务和中台的关系如何界定。譬如说：数据资产管理、容器平台、机器学习平台这些作为中台，基本是可以达成共识的。但是长在这些公共组件之上的推荐引擎部分，能不能拿了作为中台，很多公司在这些方面有不同的看法，我个人认为要结合业务的发展阶段来看。如果一个业务早期，需要快速验证业务模型，快速试错，当然接入一个统一的引擎中台，无疑是最快速、成本最低的做法；同样业务如果处于生命周期的中后段，处在一个维稳状态，没有太多的迭代前提下，也比较适合中台这种集中式托管的方式。但是如果这个业务正处在一个快速发展的上升期、以及平台期亟需寻找第二增长曲线的阶段的时候，捆绑在中台，无疑对于业务的迭代效率就会产生制约。这个阶段中台的角色作为一个孵化器往往是比较合适的，给业务提供一些基础的组件，同时类似开源社区的方式，允许业务自己维护自己的代码版本。

4.2 路径

有了上面的认识之后，我们如何来推进我们的架构升级？我们先要做什么，后要做什么？

这里面我想提一个可能在推荐系统架构设计里面不太常被人提及的概念”领域驱动设计（Domain-Driven Design, DDD）”。

领域驱动设计（Domain-Driven Design，简称 DDD）是一种软件开发方法论，它专注于创建一个以业务领域为核心的软件模型。DDD 由 Eric Evans 在2004年提出，其核心思想是通过领域模型来定义业务和应用边界，确保业务模型与代码模型的一致性。DDD 的目标是帮助开发人员更好地理解和建模业务领域，将业务领域的知识和逻辑融入到软件设计中，从而提高软件的质量和可维护性。

为什么这里要提这个概念，因为我们在实际工作中发现，很多系统设计是缺乏底层理论支撑的，只是为了解决单点的问题。这样随着业务迭代，日积月累，必然导致积重难返。我们架构设计首先需要理解底层的业务逻辑，这跟 DDD 的理念不谋而合，因为 DDD 的第一步就是领域建模。

领域模型是 DDD 的核心，它描述了业务领域中的概念、实体、关系和业务流程。通过领域模型，我们可以将业务领域的知识转化为计算机可理解的语言，实现业务逻辑与技术实现的统一。

所以我们系统重构的首要问题，是面向数据要素建模。

数据基础决定上层架构，历史债务治理，首要进行数据治理，数据收敛带动架构统一推荐系统里面最核心的数据要素是什么：用户、内容、特征、策略。

数据收敛带动架构融合

我们希望围绕推荐系统内部的四个核心要素，进行统一的平台化治理，将数据要素的读写进行统一的收口，然后在此基础上，按照推荐的漏斗进行一个微服务改造，提升系统整体复用性和扩展性，具体的执行路径如下图式：

演进路线

05、架构升级的关键路径

平台建设

为了实现整个底层数据模型的统一，我们花了接近2年的时间，进行了底层数据平台的建设，并推送了多个场景对底层数据依赖的统一，下面我们找两个有代表性的平台进行一个简单的展开，在建设这些平台过程中遇到的问题以及核心的思考。

5.1 索引平台

问题与挑战

XX平台架构

老的新闻索引服务，没有所谓平台的抽象。基本都都是按照分发场景对于内容池的要求（内容的质量、时效、安全等级、内容的分类），进行的离线加工，并且推送到在线的物理机进行在线访问的，主要存在以下的问题：

时效性不足：倒排打分更新和文章入池受限于定时任务的间隔，延迟短则十几分钟，长则数个小时。
扩展性不足：受限于单个物理机的内存，无法横向扩容。
成本高：由于各个物理池，读写负载差异很大，导致分割的小集群利用率偏低。
可用性差：采用 crontab 的任务调度，rsync 离线文件传输来更新，发布效率低，数百个物理池，运维难度大，监控无法面面俱到，可用性不足99%。
问题排查效率低：10多种介质，300多个场景，几十种时效（短则数小时长则2年种类繁多），没有易用的排查手段，基本靠人工，刀耕火种，很多问题得不到解答。

新的架构设计

新的索引架构

新架构的设计要点：

时效性提升：批处理升级为流式更新。
扩展性提升：采用主从分片的方式，提升横向的扩展性。
成本控制和可用性：统一的集群服务，资源共享，统一监控。

新架构的技术挑战：

数据一致性问题：流式更新过程中丢消息带来的数据偏移问题。
性能问题：高强度读写并发的情况下，如何保证延迟的稳定。
迭代效率问题：统一分布式索引的架构下，如何同时满足不同业务场景的实验诉求。

应对措施

一致性问题：

参考大数据处理的常用的一致性架构 Lambda 架构，流批一体进行定期的校准。

Lambda 架构

Kappa 架构

性能问题：

采用了全内存的方式，支持多线程进行读写请求，同时结合业务特点进行了定制化的调优，比如：分片的方式、底层的数据结构。

1、数据结构的选型：

首先是底层数据结构的选型问题，我们如何确定底层的数据结构，需要结合新闻的推荐的场景特点：

更新频繁，动态特征秒级更新。
索引有序，拉链独立打分。
范围查询频繁。

选型的对比：

选型的原则：增、删、改、查效率稳定，简单可依赖。

2、拉链构建方式的优化：

单链

多链

对比

拉链长度跟性能的关系

最终我们选择多链作为我们底层的倒排构建方式：跨场景内容量级差异大，要闻 xxw，二级频道 xxx 万，线上稳定性优先，尽可能减少 pv 查询级别的复杂度，每天 xx 亿 pv，通过配置管理减少拉链无序扩张。

3、分片方式的优化：

term Hash 方式

doc 哈希

考虑索引服务本身对于性能和稳定性的极致要求，我们最终还是选择了doc哈希的方式。

4、分片数量的问题：

另外一个核心的问题：分片数量是不是越多越好？答案显然是否定？分片的多少对于一个系统性能的影响也是非常大的。

分片多：并行度高，单次请求效率高，追增量快；代理扇出大。

分片少：代理扇出小，召回效率高；并行度低，容量小，追增量慢。

分片数量

5、整个在线架构分层：

当新闻推动精品资讯战略，内容池由千万缩减到百万，单分片可以承载整个索引数据的时候，三层架构是否还具有良好的性能？

6、性能优化的收益：

在线 cpu 核数由 xxx 核下降至 xxx 核，节省了62%
在线内存由 xxT 下降至了 xxT，节省了30%
集群的平均耗时由 xms 下降至 xms，节省了61%
亿次 pv 的调用成本 xx 元，下降至 xx 元，节省了63%

场景赋能：

认知：任何技术的出现都是为了解决业务的问题，技术的优化必须贴合业务场景，面优于线优于点，路线正确优于细节正确。

1、个性化推荐场景：

传统的召回索引架构

场景业务特点：

召回类型多样（倒排、模型、协同、生态等），服务众多。
业务召回占比高，业务逻辑多变，实验频次高。
访问的波动性强，受热点事件影响大。
场景统一控制规则多，例如：场景统一时效，质量等级等。

传统架构的问题：

性能差。
召回效率低。
控制不收口，迭代效率低。

新的召回索引体系

优化成果：

中控模块的网络扇出，下降了20%
召回模块的整体的cpu利用率下降了10%
倒排类召回的召回效率提升了30%
修改场景过滤规则上线效率由天级减少到分钟级。

2、个性化推送的场景

老的推送场景架构

半在线推拉结合的架构，拉活占腾讯新闻 DAU 的 xx%
周期性计算，计算密集度高，资源敏感，吞吐相对可控。
可分发集合小，保持在 xxw 量级之间。
时效性跟用户微信活跃时间相关，直接影响拉活效果。

老的架构问题：

时效性差，小时级更新。
可维护差，多个加工任务。
成本高，多个 redis。

新的架构

优化成果：

新文章入库时效从小时级到分钟级，提升了90%
24小时内曝光文章占比提升了 xx%，每天拉活用户 uv 增加 xxw+
索引整体成本，下降了40%

迭代效率问题：

在谈迭代效率问题，之前我们回头思考下，老架构发生的缘由是什么？答案显而易见，独立物理池的方式，给了运营对内容池干预的最大的灵活性，而且相互之间不影响。

独立池

运营对内容的掌控力强、实验灵活。
链路复用性差、成本高、服务运维难度大。
内容时效差，入库延迟小时级、天级。

完全去池化

服务运维难度大幅下降，成本下降显著，节省90%
运营无法感知内容变化，规则上线耦合开发人力。
pv 级别的查询过滤运算，在线成本高，影响服务稳定性。

逻辑池+统一索引架构

优化成果：

供给和分发解耦，运营所见即所得。
内容实验效率，周级别提升至天级，优化了80%
索引需求开发效率提升，策略修改分钟级生效。
在线索引过滤性能提升，节省 cpu12%

5.2 特征平台

特征质量直接决定了推荐效果的上限，特征服务是推荐系统最核心的基础服务。

老的特征链路

问题与挑战

迭代效率低，抽取逻辑没有统一规范，上线新的特征，需要修改多个模块，需要3天以上的开发周期。
特征不一致，依赖的元数据在时间上有差异，各个模块自己维护的抽取逻辑，存在不一致。
特征缺乏管理，由于抽取逻辑的分散，特征上线较为随意，同时使用上溯源困难，特征只增不减，线上特征超过2000+。
可用性差，上线新的特征需要频繁重启，在线服务，代码异常容易引发稳定性问题；离线样本链路缺乏管理，特征生产时常断流。
成本高，采用了抽取后落盘的方式，跨模型，跨模块实验无法复用，在线精排阶段需要抽取大量的实验特征，cpu 核数超过 xxw 核，成本超过 xxxw。

新的架构设计

新的架构全景

核心能力：

特征生命周期管理
- 模型配置管理
- 特征进退场管理
- 特征监控
- 特征溯源
- 特征实验
高效特征服务
- 算子化
- 通用抽取库
- 模型打分组件（TF 和无量）
- 特征上报
明文样本流
- 样本生成
- 通用离线抽取框架 FM

解决的核心问题：

迭代效率问题。

原有的特征链路

存在的问题：

原始数据（画像、正排、用户行为）生产和使用不收口。
没有统一的在线特征服务框架，各模块各自为战。
缺乏通用的算子化和配置化抽象，开发耗时高。
没有明确的研发流程指引。

简化后的链路

设计要点（工程保证效率，算法关注效果）：

借力打力，模块化治理。
- 内容侧特征生产和使用收口至正排服务。
- 用户侧特征收口至画像平台。
- 用户行为收口至大同。
提供多场景的特征服务框架，满足不同场景的特征服务诉求。
集成了ispine框架支持业务和抽取流程算子化、配置化。
依托平台，制定统一的研发流程规范，简化算法上线流程，涉及在线服务的部分由工程统一治理，保证质量和效率。

这里面有个非常关键的模块，在线特征服务，它的效率直接影响到了整个特征迭代的效率，我们充分对比了业务主流的解决方案：

场景赋能：

认知：特征服务应用场景广泛，为了保证多场景架构的通用性，需要结合场景进行架构抽象、规范化治理。

我们结合前面抽象出来的两类新闻的核心场景，抽象出来了两套通用的架构解决方案：

个性化推荐场景的通用架构

双塔&&个性化推送场景的通用架构

优化成果：

主端、手 Q 插件、微信插件模型特征开发效率由之前周级别缩短至0.5天以内，提升了90%了；配置化管理，一次配置离在线同时生效；数据和抽取逻辑解耦，避免算法工程同时操作线上代码，提升了在线服务稳定性至99.99%。

特征一致性问题

归因分析：为了提升迭代效率，采用了明文样本的特征保存方式，来达成数据和抽取逻辑解耦，同时引入了不一致的问题，体现在：

抽取逻辑的不一致，离在线抽取逻辑以及在线各个模块抽取逻辑分散维护，产生的不一致问题。
元数据有差异，预估时刻和样本生成阶段原始数据不一致。

分散的特征抽取架构

抽取逻辑的一致性解决方案：

中心化治理的抽取架构

元数据的一致性保证

元数据一致的架构

用户特征一致性：在线特征服务采用了 TraceID 级别的缓存，缓存用户侧画像和 context 内的动态行为信息。
内容特征一致性：中心化的 Item 级别的缓存，通过 Item+timestamp 来进行内容级别的缓存。
路由一致性：在线通过一致性 hash 回调的方式，来进行 featureDump。

优化成果：

达成了特征的完全一致性，整个样本拼接率 xx%提升至了94%，多个核心场景的业务指标提升显著。

性能优化

影响性能的关键环节：

核心抽取库的性能，直接影响了离在线抽取的性能。
特征抽取流程优化，大量模型实验，模型之间特征重合度，高达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。

5.3 推荐系统的可解释建设-Debug 平台

这里为什么把 debug 平台作为一个独立的模块单独出来讲，在我看来很多公司忽视了推荐可解释性平台建设的重要性，大家过分的依赖于数据本身的表现而忽略了背后的逻辑，从而导致了一个现象：就是往往我们做的每一个实验都是正向的但是累积一段时间下来，整体大盘指标反而没有任何进展。这跟当下的推荐优化过分依赖 ab 实验平台，忽略了可解性建设有直接的关系，很多方向的探索大家都处在“知其然，不知其所以然”的状态。

推荐系统的可解释性困局

可解释性的两层含义:

对于终端用户的可解释性(简单，易懂，高度抽象)
对于系统参与者的可解释性 (详细，全面，直击要害)

由于推荐系统的参与者众多，内容、用户量级巨大，架构复杂，因而构建一个可解释的系统面临了极大的挑战。

可解释性困局

新闻是一个运营和个性化并重的信息流产品，内容供给和推荐涉及的环节众多，横跨多个团队新闻延续了之前腾讯网的架构，上百个场景独立部署，几百个代码仓库，代码不能主干开发，数据采集和上报各自为战，数据缺失严重。
原有的 Debug 工具各个模块自建，面向模块自身，而非面向业务场景，导致工具庞杂，上下游无法串联。
数据的实时性不够，关键消费数据的更新只能做到 T+1，且维度单一。
针对推荐侧有状态的模块例如(分布式索引、画像、曝光)，缺乏有效的 Debug 手段和工具。关键数据的呈现采用原始 KV 的方式，可读性差，易用性低。
针对开发人员缺少必要的模拟请求、结果分析的工具。
增长(Push、插件)、主端推荐，存在重复建设的问题。
由于推荐系统的复杂性，成为了产品、运营和技术之间的鸿沟，问题发现往往在产品和运营侧，问题的定位往往在技术侧，问题排查占用了非常多的研发人力。

新闻 Debug 平台的设计目标

设计一套全新的数据采集协议和数据采集架构，提升数据的准确性和时效性。
面向业务场景设计 Debug 链路，而非面向模块，打通上下游。
深入理解平台用户诉求，结合业务场景优化体验，提升易用性。
合理设计离在线架构，降低对于业务系统的影响，优化存储效率节省成本。
工具收敛，一站式定位问题。
通过平台的建设，发现新闻推荐系统的问题，推动新闻推荐架构升级。
在解决好新闻自己问题的同时，抽象出通用的推荐引擎白盒化能力反哺BG内的其他类似场景，推动整个平台演进至 BG 乃至行业内领先的水平。

平台全景

架构全景

平台能力

核心链路设计

数据流转架构

30天内任意内容，秒级可查，可追溯，在线消费核心指标分钟级更新。
3小时后，在线任一用户 Trace，分钟级回捞，实时可查。
负反馈信息实时采集，自动抽样，一站式分析。

5.4 端到端的稳定性建设

新闻的业务特点：时效性强、热点突发多，导致 QPS 波动大，对系统稳定性冲击大。

稳定性治理的措施：

异常请求识别，网关限流。
完善的降级流程和操作手册。
方便的人工介入能力，一键生效。
各阶段柔性降级，层层兜底。
针对可预见热点的快速扩容机制。
完善的监控和告警机制建设，第一时间发现问题，解决问题。
联动123平台，解决基础设施稳定性问题，例如：容器负载不均，网络拥堵、单节点异常等。

自动容灾的架构设计

06、系统防劣化

原则：制定并且遵循标准、规范和最佳实践，构建防腐层避免新的技术债务的累积。

代码规范：
- 大仓的开发模式，统一代码标准：单侧覆盖率大于70%，圈复杂度小于5，代码重复率小于8%。
- 统一协议规范，采用 BG 的 trpc-cpp 协议，替换原有的 brpc、http 等。
发布流程规范：
- 所有在线服务发布均接入蓝盾流水线，执行严格的单测、diff 流程。
- 二进制灰度能力建设，建立了金丝雀发布机制，保证端到端的稳定性。
- 策略灰度能力，基于方圆策略平台建设了策略灰度能力，避免错误配置引起全线崩溃。
问题排查流程规范:
- 打通伽利略监控到 oncall 平台的通路，自动提单，故障 MTTR<60分钟。
- 针对重点场景建设了监控大盘并制定了相应的问题排查手册。
- 通过企微建立了 slo 长效的跟踪机制，及时发现及时响应。
需求开发流程规范：
- 所有的需求开发均接入 Tapd 需求管理平台，通过 Tedi 平台进行迭代效率的监控，及时发现问题，保证迭代效率。
- 建立规范的需求价值衡量机制，避免无效需求对于系统架构的侵蚀。
- 引入技术评审机制，避免垃圾设计对于存量系统的影响。