腾讯新闻PUSH架构升级之路

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

10/30晚7:30鹅厂面对面直播继续！

01

腾讯新闻 PUSH 平台介绍

PUSH 是腾讯新闻内容重要的分发渠道，新闻 PUSH 平台承担着将新闻资讯触达到新闻用户、满足用户及时获取精品资讯的需求。

总体上，新闻 PUSH 链路分为两部分：

1.1 PUSH触发

按触发方式的不同，新闻 PUSH 分为三类：

• 人工 PUSH：运营在 push cms 系统指定要发送的文章、要触达的人群包，人工触发push发送；这类 PUSH 目前主要用于推送热点事件/热点资讯等；
• 自动化 PUSH：周期性地给用户计算他可能感兴趣的内容，这类推送由后台自动触发；
• 功能性 PUSH：由业务系统触发，主要是为了实现一些业务功能通知，比如评论通知、关注通知等；

1.2 PUSH下发

对于所有 PUSH 触发 的PUSH 进行调度（包括避让、打散和频控等）和触达（通过自有通道或厂商通道推送给用户）

新闻业务对新闻 PUSH 平台最重要的要求是：

• 要保证精品咨讯触达的及时性： 新闻 PUSH 最重要的是要体现“新”，因为腾讯新闻用户有及时获取热点/突发资讯的诉求，用户经常有这样的体感，有热点突发事件时，所有 App 都会尝试第一时间向用户发起推送，用户大概率会点击收到的第一个推送。在了解了相关热点事件后，对于后续其它 App 的推送，对用户而言就没信息量了，大概率会被忽略，甚至可能会被用户视为一种打扰，影响用户体验。从我们实验数据来看，当P USH 下发延迟降低 50%，PUSH 点击量会提升 10%。 所以新闻 PUSH 一直以来的目标是：热点资讯需要第一时间触达给用户，要做到“全网首推”；
• 要保证推送的用户体验和较好的拉起效率： PUSH 是新闻重要的促活手段，需要有较好的促活效率，这要求保证用户较好的推送体验，因为用户如果感觉推送体验不好，用脚投票，把 App 的 PUSH 系统开关给关了，这对 PUSH 而言就基本上就永远丧失了给这个用户推送的机会了。这就要求要尽量保证在合适的时间点给推送用户感兴趣的内容，推送要有合理的频次，相邻 PUSH 之间要有合理的时间间隔，推送内容要做合适的打散。

其实这两个要求其实在一定层面上是有冲突的，如果要保证推送的及时性，就要求尽量减少计算，拿到消息消息后无脑推到消息通道，这个肯定最快；如果要保证良好的推送用户体验，就需要做很多的判断、考量和计算，这些考虑越多就需要做更多的计算和 io 操作，会影响推送的及时性；最近几年，业务成本的考虑也是 PUSH 关注的重点，需要削减使用的机器和资源，就要求用更少的机器如何发得更快更好。

总结而言，之前新闻 PUSH 业务的突出问题主要有以下几方面。

1.3 PUSH 推送速度慢

我们团队从 2022 年年中开始接手新闻 PUSH 平台。交接工作刚启动，就遇到了一次 S 级热点事件——一个国际级突发新闻。那天晚上，全网用户都在密切关注它的最新进展。 这个事件有两个特点：热度极高、且并非完全突发——早在一个月前就已经有明确预告，因此运营部门提前布置了应急预案。我们刚接手系统时，对整个下发链路还不够熟悉，只能凭直觉扩容机器，希望能抗住峰值。结果现实很快给了我们一记当头棒喝。 当晚，很多内部同事都装着多个新闻 App，一眼能看到谁家的推送更快。那晚我们的延迟问题非常明显，甚至有用户在热点过去一个多小时后才收到通知。事后有专门的评测团队做了分析，指出“PUSH 下发耗时过长，高活用户 P90 均值达 20 分钟”，报告还发到了高层群里——对我们来说，那无疑是一次刻骨铭心的教训。

1.4 开发效率和问题排查效率低

之前 PUSH 链路特别长，新闻 PUSH 内部有 30+ 个模块，同时还依赖其它两个跨业务团队。经常一个需求开发要改多个模块，要团队几个人一起开发，约定交互协议，开发后再联调测试，在多个模块起联合实验；然后还得给中台提需求，然后匹配中台的排期后，才能完成需求上线；这一系列操作就拉长了 push 需求的leadtime。

线上有 case 时，问题排查也需要串联多个模块，关联多个模块数据，甚至需要跨部门拉上其它这边来一起来排查，排查效率非常低。push case 非常多，比如用户为什么收到了/没收到某条 push 之类的典型 case，之前需要关联链路20来个模块的日志，还要联合中台一起排查，每次 case 排查时间都在天级；之前在case 排查上，每天都耗费我们大量的人力。

既要持续提升 PUSH 触达的及时性、又要持续提升推送的用户体验和拉活效率，还要持续降低运营成本，客观而言，在技术上是一个较大的挑战。本文主要详述，我们如何通过技术架构升级来支撑这个既要&又要&还要的目标。

02

老架构存在的问题

所有业务的问题都来源于技术架构，原架构问题如下：

2.1 模块链路过长，内耗过多

一条快速PUSH，从推送内容过审后，到最终发出去，最长要经过18个模块，另外还需要经过中台多个模块。一条待推送的数据最多要经历 17 次内部 rpc 转发，多个模块之间腾挪流转，各种网络 rpc，各种内耗，肯定发得慢。

一个最典型的例子，原架构有个模块叫scheduler，它主要负责决定一个push该不该发，直观上感觉它里面应该囊括了各种过滤策略，但是原架构做成了多个微服务。scheduler 模块里本身有一些过滤逻辑，另外有一个叫做 filter 的模块，专门负责品牌、开关等硬规则过滤；另外有一个叫做 policy 的模块，专门负责配额等软规则过滤；所有过滤规则都通过后，进入一个叫做 channer 模块，就决定下这次推送走哪个通道；然后又走到一个叫 worker 的模块里，而它只做对接下游中台的协议适配。

总体上看，原链路就是过度微服务化了：模块多会导致数据流转的低效，模块间网络 rpc 会浪费处理耗时；其次会影响迭代效率，模块数不是越多越好，因为经常一个需求需要改多个模块，做多次上线；同时模块过多也对联调&测试效率，影响线上 case 排查效率。这就违反了“模块内高内聚，模块间低耦合”的架构设计原则，进而会影响业务迭代效率。

2.2 依赖服务有瓶颈

上文提到的 S 级热点事件时，我们将下发服务机器扩了一倍，但是下发速度并没有提升，说明瓶颈不在下发服务本身下，而是在依赖服务上；通过链路debug，我们定位到了链路瓶颈：号码包拉取。

在发送人工 push，运营会指定受众人群包（几百万到几亿不等），这时候需要分页拉取该号码包数据进行处理；之前老架构使用了底层平台的人群包服务，新闻所有 push 人群包都上传到了该人群包服务，当发送指定人群包，需要请求平台侧接口分页拉取人群包数据，当时因为平台侧人群包功能实现比较复杂，能支持一些比较高级的能力，因此这个分页接口耗时比较长。但其实我们只用到了最简单的数据分页的功能，完全可以采用更简单的实现方案，以减少接口耗时。

2.3 链路稳定性不好

2.3.1 容错能力差

之前链路基本无容错能力，发生了过一次因上游未按约定协议跟我们请求交互，导致我们服务挂了半天，是一次典型的 P0 级事故。

2.3.2 缺少节点自动故障转移

scheduler 负责 push 调度，原架构为了提升处理效率，scheduler 里做了本地缓存；为了避免缓存失效，起了一个服务 dispatch 消费触发侧生产的待推送的消息，然后按照用户设备号一致性哈希来 sharding，通过 rpc 请求对应的 scheduler，scheduler接受到请求后，塞入到它本地的内存队列里，如果队列满了就直接丢弃。

它原来存在有这些问题：dispatch无脑往下游转发，sharding规则非常僵硬，一个用户的push一定要打到某个节点，未做故障转移；当某节点异常满载时，dispatch还是会往这个节点打，导致丢消息或者是 push发送得慢。而且当节点满载时，有限的cpu还需要耗费在rpc解包、无法插入内存队列而丢弃之类的无用消耗上。

2.4 链路处理无优先级区分

运营人工发的 PUSH 和自动化 PUSH 都使用同一个下发链路，热点突发事件资讯多由运营人工发送，而自动化 PUSH 多发一些用户可能感兴趣的内容，其实它对于推送速度并没那么敏感；当有人工推送的热点突发内容时，自动化 PUSH 会和它一起争抢有限的链路资源。

另外，在链路总吞吐量一定的情况下，其实处理顺序可以调整，让链路资源有限保证人工推送的热点突发内容的发送；

2.5 技术栈不统一

之前 push 下发链路有 C++/Go 两种技术栈，技术栈不统一不利于代码复用，影响需求迭代效率。push下发链路本质上是一个高 io 型的流程，其实可以完全可以统一到 Golang 技术栈。

2.6 链路测试效率低

push 链路业务逻辑比较多，在日常密集业务需求迭代中，新功能我们可以在线上通过构造对应的功能 case 来进行冒烟测试，但是比较难评估是否影响了线上已有的业务逻辑。之前缺乏有效的回归测试手段，由于担心影响线上业务指标，为了验证是否影响线上已有业务逻辑，我们大的修改都会开比较长的小流量实验验证，比如我们在做调度架构升级时，开了一个近两个月的小流量实验，测试效率比较低也会导致需求迭代效率比较低。

03

架构优化方案

3.1 全链路业务闭环：消息通道自建

之前新闻 PUSH 依赖于平台侧的消息通道，业务侧主要负责 PUSH 调度，即业务侧决定触发和过滤，平台侧负责 PUSH 触达给用户终端。

由于 PUSH 是新闻增长护盘的重点方向，有较频繁的业务迭代，对底层消息通道我们有较多的业务需求，在业务迭代过程中我们发现平台侧需求 leadtime 比较长，无法满足业务侧迭代效率的要求；在经平台侧这边商量且同意后，我们完成新闻push消息通道的自研，直接对接厂商推送并搭建了长链接通道，实现了 push 全链路在业务侧的全闭环。我们在自建 push 消息通道时，对原来的架构做了重写：

✓ 精简链路，模块整合，减少系统复杂度

去掉我们不关心的无用功能，将原链路15个模块，代码 68 万行整合为了6个模块，代码共8.6万行；通过代码精简能减少系统复杂度，有助于提升业务迭代效率；同时能避免模块之间的rpc通信开销，提升链路处理效率；

✓ 客户端/服务端交互接口整合，提升数据通信成功率

以前 PUSH 注册依赖于注册&绑定&上报三个接口请求，任何一次请求出错，push 注册就会失败；我们在新流程里将注册&绑定&上报需要的所有数据，都一起传给新接口，由服务端在一个接口里实现注册、绑定和上报；将注册成功率从90%提升到了99.9%；

✓ 与新闻技术技术架构保持统一

将原架构发现/rpc技术栈的基础组件升级为腾讯新闻自用的基础组件，尽量使用我们熟练使用的技术栈，以提升业务开发&运维效率；

✓ 优化了原来链路一些不合理的地方

对原来链路的限流机制、通道选择策略做了优化，增加了必要的功能，比如小流量实验环境的支持

3.2 统一技术栈

之前 push 链路有 C++/Golang 两种技术栈，除了 push 推荐服务外， 其它 C++链路模块全部使用 Golang 模块进行了重写，以提升业务迭代效率和链路稳定性。

3.3 链路整合升级，提升效率

一个架构如果如果过度微服务化了，会带来各种问题：

1）模块间耦合严重，影响研发效率：本来是一个模块应该完成的工作，硬拆成了2个模块，有改动需要都需要改两个模块，需要模块间联调测试，影响需求迭代效率；

2）架构效率低：拆成微服务后，函数本地调用变成了RPC网络调用，需要增加大量的拆包、解包的操作，资源白白浪费在这些无用的内耗上了；

对于频繁迭代的地方，单独抽成单独的微服务是有助于提升迭代效率的；但是我们review历史push需求，都比较分散，没有集中到一个特定的地方，我们按照“一个需求尽量只用改一个模块”的原则，对原来的push链路的所有模块进行了整合升级：

✓触发侧合并为了1个模块：

将原来触发侧的5个模块合并为1个模块；

✓调度侧合并为了1个模块：

将原来调度侧的5个模块合并为了1个模块；

✓ 将消息通道侧模块做了整合：

如上所述，我们将push消息通道原来15个模块合并为了5个；

经过链路整合后，以前一个 PUSH 消息最多要经过 18 个模块，17次内部链路rpc转发；升级后，只用经过 3 个模块，只用经过 2 次 rpc 转发；这样就显著提升了链路效率；而且模块减少后，业务需要迭代无需开发多个模块，避免模块之间联调和测试，提升了业务迭代效率；同时，线上 case 排查时，无需做多模块的日志 join，提升了 case 排查效率。

3.4 系统瓶颈专项优化：自建号码包服务，提升号码包获取速度

如上文所述，之前号码包的拉取慢是系统的主要瓶颈所在，而在我们这个场景比较简单，因此我们考虑自建号码包服务，针对于我们自己的需求来定制开发，以提升服务性能。我们的需求只有一个，就是对离线包进行分页，并提供服务接口返回指定页的数据。

✓ 画像中台圈选兴趣包，并按页切成若干个小文件，每个兴趣包一个文件夹，并上传到cos，兴趣包里带着数据版本号；

✓ 构建包管理服务，提供获取指定兴趣包指定页数据的能力；包管理服务定期从cos上check是否有更新的数据（比较本地数据版本和cos最新的数据版本），如果有，则拉取最新的数据更新本地数据；当接收到拉取指定包指定页数据的请求后，则定位到对应文件夹读取对应页文件数据并返回；

✓ 集群有个数据一致性哨兵，定期检查集群节点的数据版本，当发现集群数据版本不一致时，给集群所有节点发信号，强制让每个节点同步cos上的最新数据，让集群所有节点数据跟最新数据保持一致。

3.5 漏斗尽量前置：在线过滤改成离线预处理，避免在线处理耗时

运营在发PUSH时会选择受众人群包，同时会指定系统、品牌等筛选项，之前的处理流程是先把人群包一股脑发到链路里，然后在下发链路里根据用户画像数据，对数据进行实时过滤。在线过滤增加了链路下发的耗时。

其实系统&品牌过滤完全可以前置到离线侧，我们将号码包按品牌和系统维度进行了拆分，比如“社会”包按android/ios、huawei/oppo/vivo/honor/xiaomi，拆成了13个包，当运营选择指定的筛选项时，直接拉取对应的号码包，这样就避免了在线过滤的耗时，减少了下发的延时。

3.6 提升程序整体吞吐量：将单IO操作自动聚合成批量操作

push下发链路有大量io操作，比如获取用户维度的多路数据（比如用户系统、品牌、下发&曝光&点击历史等），获取文章维度的多路数据（文章正排数据等）。链路其实主要耗时还是在io部分，如果能提升io吞吐量，就能提升PUSH链路的吞吐量，减少下发延时；io操作批处理肯定能提升吞吐量。

但是在具体业务流程中，不同push类型、不用品牌用户，处理逻辑会有不同，因为每个push的处理流程可能都不一样，无法直接批处理。所以之前调度主链路流程是从队列里按单个消费进行处理的。

为了提升链路吞吐量，我们对每一类io操作做了一个类，对外暴露一个单个io请求接口，外部调用该接口后，将请求压入一个异步队列，同时开始等待结果的返回；这样该类io请求都会在该异步队列里进行了汇聚。

下层会开若干个处理协程，批量从异步队列消费出若干请求任务，拼成批量的io请求，然后拿到批量io结果，按序向上层返回io结果；

这样对上层而言，看到的还是单个的同步io接口，上层业务逻辑开发流程无需做改造，底层其实已经自动做了io的批量聚合，显著提升了链路吞吐量。

3.7 构建推送优先级：优先推送热点突发内容，优先保证高价值用户及时性体验

在链路吞吐量一定的情况下，一个推送任务小到几百万，大到一两亿的发送量，都需要处理时间。这时候先处理比后处理的时延要少。其实可以考虑对链路发送进行调度：

• 链路优先保障热点突发PUSH的发送，我们建立了任务优先级队列，当有热点突发PUSH在发送时，其它PUSH延迟发送；
• 同一个PUSH任务，对用户推送顺序也做了排序：活跃度高、历史push点击率高、预估商业化价值高、对push时延敏感的用户优先发送；

通过优先级调度，最大程度保障了热点突发内容和高价值用户的推送及时性的体感。

3.8 提升链路稳定性：增加自动故障恢复能力

为了提升链路吞吐量，调度节点进程通过 LRU cache 缓存了大量数据，所以在推送消息处理的 sharding 方式上采用了按设备号一致性哈希。很多时候某个节点异常时，会出现慢而不死的情况：处理能力陡降，但是节点存活正常。北极星未能把它摘掉，相当一部分设备会打到该节点，即使该节点已经满载了，之前架构为了避免缓存失效而导致处理耗时增加，还是会一致性哈希将流量打往该节点，导致这部分用户处理耗时异常增加，甚至发送失败。

新架构对于推送任务sharding做了优化：在一致性哈希的基础上，每个节点计算出4个固定的backup；当某节点的失败率或处理耗时超过一定阈值时，将该节点的流量均匀低分给他的backup。通过这种方式就支持单节点异常时的自动故障恢复。

3.9 构建push链路自动化测试能力

• 构建了接口自动化回归测试流程
  • case覆盖push链路的核心逻辑
  • 合并master时自动触发回归测试流程的执行；
• 构建了自动化diff测试流程 diff流程大体思路都类似，通过录制线上流量的真实请求和返回结果，在测试环境进行回放，观察同一请求下，返回结果是否会有差别；如果无差别，说明测试环境跟线上一样，上线不会引起线上数据异常；如果有差别，就需要分析这些差别是否是符合预期的。 diff测试基本能回归到线上所有业务逻辑分支，能弥补回归测试覆盖度有限的问题。
• 主要挑战 push依赖的数据变化比较快，导致在同一时间，同一请求的返回结果会不同；比如push为了避免重复下发同一篇文章，会依赖于下发历史数据，线上录制了刚下发的某篇文章，在测试环境去回放肯定就不能下发了，因为线上刚把这篇文章写入到下发历史里，导致回放请求时返回结果是不能下发了，这样自然就产生了diff；
• 解决方案 在流量录制时，除了录制请求之外，同时录制各个依赖数据，在回放时，依赖数据以依赖数据为准，通过这种方案就避免了依赖数据易变而引入diff的问题。

04

架构升级效果

4.1 push运营成本显著降低

通过持续的 push 架构优化，新闻 push 总运营成本下降70%；

4.2 PUSH链路性能（吞吐量）显著提升

通过持续的 push 架构优化，显著提升了 push 链路的性能，push推送量（出口）峰值吞吐量提升了3.5倍；

4.3 热点突发（全国/快速）PUSH全链路耗时下降明显

热点突发（全国/快速）PUSH内部链路耗时P90下降了90%

内部链路耗时指的是从push审核通过到推送给厂商的时间，即我们内部链路总的耗时时长；

热点突发（全国/快速）PUSH全链路耗时（包括内部链路耗时和厂商链路耗时）下降了90%

全链路耗时指的是从push审核通过到用户收到PUSH时间，即包括内部链路和厂商链路总的耗时时长；

我们完成一些架构升级后，还是评测团队对了评测，腾讯新闻的PUSH已经领先于竞品1～4分钟了。

4.4 提升了PUSH点击效果

push推送速度提升后，push点击数据也能看到明显受益，热点突发PUSH点击pv提升了10%，push大盘点击UV也能看到显著的正向收益；

线上收不到PUSH的用户客诉也减少到25年H1 0 例，提升了用户产品体验。

4.5 稳定性良好

push链路主要重构完成后，PUSH链路稳定性&质量明显提升，2025.02以后 0 故障。

-End-

原创作者｜颜勇