揭秘百度IM消息中台的全量用户消息推送技术改造实践

Posted 2023-05-26 im中国人

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了揭秘百度IM消息中台的全量用户消息推送技术改造实践相关的知识，希望对你有一定的参考价值。

本文介绍了百度现有IM消息中台系统的主要组成，并对比多种实现方案的优劣，以“公有信箱”通知读扩散的技术方案对现有IM消息中台系统进行改造，从而达成了低成本、高时效地实现全量用户通知推送需求。

本文内容由百度技术团队分享，原题“基于公共信箱的全量消息实现”，为了帮助理解，有较多修订、内容重组和重新排版。

1、引言

百度的IM消息中台为百度APP以及厂内百度系产品提供即时通讯的能力，提供包括私聊、群聊、聊天室、直播弹幕等用户沟通场景，并帮助业务通过消息推送触达用户。

如今，百度APP新增了一种需要以“低用户打扰”的形式触达全量用户的场景需求，而现有的IM消息中台主要是基于用户“私有信箱”通知拆分的机制（通俗了说也就是IM里的“扩散写”），所以如果不进行改造，是很难低成本、高时效的满足该场景诉求。

基于上述问题，本文介绍了百度现有IM消息中台系统的主要组成，并对比多种实现方案的优劣，以“公有信箱”通知读扩散的技术方案对现有IM消息中台系统进行改造，从而达成了低成本、高时效地实现全量用户通知推送需求。

技术交流：

- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》

- 开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）

（本文已同步发布于：http://www.52im.net/thread-4235-1-1.html）

2、全量用户消息推送需求背景

百度APP新增了需要通过IM实时通知触达全量用户的诉求，比如2022年12月7日解除疫情管控结束后，将经过筛选的官方政策解读、专题汇总、知识科普、实用工具类介绍等信息，通过官方号“x度小助手”下发触达到百度APP用户，从而来有效体现人文关怀，提高用户粘性。

在以IM消息服务进行全量用户消息触达时，需要满足以下诉求：

具体就是：

1）在触达范围上：希望尽量扩大用户触达范围，包括百度APP月活用户、以及非月活用户但是近期新注册或登录的用户；
2）在时效上：一次全量触达，希望短时间内完成（比如小时级、甚至分钟级），抢占时效性；
3）在用户打扰方面：消息触达不能给用户带来较大的打扰，每次消息下发，只触达一次，不能重复打扰用户（但是需要保留回访入口，满足用户二次查看的诉求）。

3、现有IM消息中台的技术痛点

我们现有的IM（即时通讯）服务中，每个IM用户对应一个用户信箱。

基于现有的IM技术实现方案，如果想完成全量用户的消息触达，需要把消息推送到每个用户的信箱（也就是IM中的扩散写）。

这样的话，要完成6亿以上的消息写入（假定每条占用存储4KB，每秒写入2W条消息），在消息写入时效性以及存储资源消耗上，都是很难接受的。

且现有的基于用户私有信箱的方案，在同时支持多条全量用户通知消息的场景下，扩展性也较差。

基于上述需求背景和技术痛点，我们本次的改造目的，就是要找到一种技术方案，从而在特定业务场景下通过改造后的消息服务，低成本、高时效的给全量用户推送内容一致的消息通知。

4、现有IM消息中台的主要技术实现

在讨论改造方案前，我们有必要介绍一下目前IM消息系统的现状，包括消息系统的组成、通知拉取模式、用户信箱等。

4.1 消息系统组成

从普通用户的直观体验上看，一个IM系统可以包括如下元素：

1）用户主体；
2）用户账号；
3）账号关系；
4）聊天会话；
5）聊天消息。

用自然语言串一下以上元素就是：

1）“用户主体”具有“用户账号”；
2）“用户主体”具有头像、昵称等用户属性；
3）“用户主体”通过“用户账号”登录IM系统，进行聊天；
4）“用户账号”之间的关注、屏蔽、免打扰等构成“用户关系”；
5）通过用户之间的互动环节可以产生“聊天消息”；
6）聊天记录构成了一个“聊天会话”。

下面这张图可能更直观一些：

从集成消息服务的业务方角度看：

1）一个IM系统可以包括消息客户端（消息客户端UI组件、消息SDK）和消息服务端；
2）IM消息可以作为一种服务，嵌入到各业务系统中，为业务系统提供“实时交互”能力；
3）业务通过集成IM服务，提升其用户体验；
4）业务APP集成IM SDK，通过IM SDK与IM Server交互，完成用户上行通讯能力；
5）业务APP Server通过与IM Server交互，完成通知下行触达用户。

下图为一个集成了IM SDK的业务架构图：

从使用场景来看，消息包括：

1）“私信消息”（包括用户上下行消息）；
2）“通知消息”（业务方给用户推送的下行消息）；
3）“群聊”、“聊天室”；
4）“直播间弹幕”等。

4.2 消息的通知拉取模式

百度的IM消息系统，采用通知拉取（notify-pull）模式来感知新消息、拉取新消息。

IM SDK登录时，与IM 服务端建立长连接（LCS, Long Connect Service），用户有新的消息时，通过长连接下发notify，实时通知用户的IM SDK。

实时notify不写用户信箱，因为noitfy不是消息（可以理解为提醒在线用户有新消息的信号），IM SDK根据这个信号，来服务端拉取消息。

业务方server或者其他用户给该用户发送消息后，经过IM业务处理模块，把消息写入接收者信箱，IM Server会根据用户的登录和路由信息，给消息接收者（私信场景下也包括“消息发送者”，用于消息的多端同步）发送新消息notify，接收到notify的IM设备，通过IM SDK来IM Server端拉取（pull）消息。

4.3 用户信箱介绍

为了暂存尚未拉取到IM SDK本地的离线消息，需要对消息进行服务端存储，而消息的离线存储是通过消息信箱服务完成的。

目前百度的IM用户消息信箱主要包括：

1）用户私有信箱；
2）群公共信箱（非下文提到的用户公共信箱）；
3）直播间弹幕mcast等。

用户信箱通过“消息所属应用”+“IM标识用户的唯一ID”来标识。

就一条消息而言：消息参与者有“消息发送者”和“消息接收者”，消息收发双方的信箱都是相互独立的（假设发送方删除了自己信箱的某一条消息，不会影响消息接受者信箱的消息）。

对于有查看历史消息诉求的一方来说：消息需要入该方的信箱，比如用户之间的私信（也就是一对一单聊）消息需要入发送者和接收者的信箱。

而对于全量用户消息通知的场景：消息不需要存储发送者信箱，而只需要存接收者的信箱。而用户的信箱排序，是基于信箱Timeline（详见《现代IM系统中聊天消息的同步和存储方案探讨》）。即消息在信箱内部基于时间线存储，每条消息对应一个unix 微秒时间戳（如第一条消息1679757323320865），用户进行信箱拉取时，基于时间范围正序或者逆序拉取。

如下为信箱Timeline的示例：

用户信箱中的每一条消息记录都包含四个主要部分：

1）“消息ID”；
2）“消息用户标识”；
3）“消息通用属性”；
4）“消息业务属性”。

下面详细介绍以上四个部分：

1）消息ID：为unix微秒时间戳，不需要全局唯一，只需要特定用户信箱范围内唯一即可；
2）消息用户标识：包括from_uid、to_uid、contacter；
3）消息通用属性：包括create_time、expire、is_read；
4）消息业务属性：包括category、type、priority、business_type、APP_id、msgkey、content等。

如下为一条消息记录示例：

5、全量用户消息推送技术方案选型

5.1 需求分析

目前百度的IM消息推送机制中，主要支持：

1）单播：消息推送方式，每次给一个用户推送一条消息;
2）批量单播：每次给小范围用户推送消息，比如30个;
3）广播：基于关注关系的推送，如给全量粉丝推送。

上述三种消息推送机制推送的消息，均需要存储服务端的用户私有信箱。为了完成百度APP 6亿以上全量月活用户的消息推送，目前有三种可选的方案，接下来我们逐一分析。

5.2 方案1：全流程从通知入口推送

该种方式下：需要获取全量的月活用户列表，经过IM Server推送入口，给每一个用户推送疫情相关通知。

该通知写入到用户信箱时：

1）若用户在线，在实时拉取该通知；
2）若用户离线，再下次登录IM服务时，拉取离线通知。

该种方案下：推送行为会覆盖IM的全流程，推送的通知会进入每个月活用户的私有信箱，服务压力大。其中增量用户不会收到通知推送（这里增量用户指的是不在月活用户列表的用户）。

5.3 方案2：跳过通知入口直接写信箱

该种方式跳过IM消息推送流程中的中间环节，直接把通知消息写入用户信箱。

由于跳过了中间流程直接写入信箱，通知写入速度主要取决于信箱底层存储的压力承受情况。

该种方案下，同方案1一样，无法给用户发送实时通知，依赖用户IM SDK的主动消息拉取（断链后重新登录/新消息提醒拉取），无法给增量用户发送通知。

该方案由于跳过中间环节直接写信箱，风险较大，无法直接提供给业务方使用，不建议如此操作。

5.4 方案3：公有信箱实现机制

该种公有信箱机制的逻辑是把通知消息写入“公共信箱”。在用户消息拉取时，合并“用户私信信箱”+“公共信箱”的消息。

5.5 三种方案比较

方案1和2都是写扩散方式，基于现有“用户私有信箱”的机制，把通知消息写入每个接收通知的用户私有信箱。

方案2与方案1的差别主要是跳过了消息中间流程，可以避免因为中间环节负载瓶颈导致整体消息写入速度过低。

方案3是读扩散方式，消息不用再写入接收通知的用户私有信箱，而只需要在公共信箱存储一份。在用户拉取消息时，实时拉取公共信箱的消息。方案③中可以采用内存缓存方案，解决对公共信箱的读压力。

本质上来说：方案3与方案前两种相比，是用读成本（CPU）换写成本（存储）。

6、基于公有信箱技术方案的全量用户消息推送实现

6.1 概述

基于上述方案3的思路，我们进行基于公有信箱的全量消息设计与实现。

该种方案中包含两个主要流程：

1）全量消息的管理；
2）用户私有+公有信箱的拉取。

6.2 全量消息的管理

全量消息管理主要分为：

1）运营O端操作平台：复用运营消息平台；
2）全量消息处理服务：复用IM服务的连接层、逻辑处理层、信箱代理、信箱处理。

运营O端平台为运营同学提供可视化界面，可以对全量消息进行编辑、预发布、发布、修改、停止、撤回等操作。

具体就是：

1）接入层：对接运营O端，进行参数校验、转发IM后端逻辑处理模块；
2）逻辑处理层：进行全量消息的创建、修改、停止、删除、撤回等逻辑操作；
3）信箱代理层：复用IM服务的信箱CRUD操作；信箱存储层公共信箱的底层存储。

全量消息管理流程：

6.3 用户信箱拉取

用户通过IM SDK，以长连接的方式，在逻辑处理层进行消息拉拉取。

在用户拉取信箱消息时，需要对“用户个人信箱”和“公有信箱”进行合并。于是每次用户信箱拉取，都需要进行信箱的合并拉取。

6.3.1）公共信箱内存缓存机制：

百度APP的IM用户，在IM SDK登录时需要拉取信箱中的消息。每次消息拉取时，需要检查公共信箱中是否有消息。

因此，公共信箱需要能抗住日常和峰值流量（拉取峰值为4.7Wqps）。为了防止流量击穿，流量打到底层的持久化公共信箱MYSQL存储，我们设计了基于内存的公共信箱缓存机制。同时公共信箱内容变化时，也要实时（或者在能容忍的范围内做到准实时）变更内存缓存信箱中的消息，我们采用Bthread定期轮询持久化公共信箱，更新内存公共信箱，轮询间隔可配置（比如设置1秒）。

6.3.2）分级发布机制：

同时，在逻辑层实现白名单机制，支持全量消息在“预发布”状态下，仅对白名单用户可见，从而达到分级验证的效果。

白名单的用户列表通过逻辑处理成的配置加载，也支持通过CURL请求动态修改白名单的配置。

7、基于公有信箱技术方案的技术挑战

公有信箱的技术方案，需要解决如下问题：

8、基于公有信箱技术方案的优缺点总结

8.1 优点

以公共信箱的方式，实现全量用户消息分发，具有：“分发速度快”、“资源成本低”的特点。

8.2 缺点

但公共信箱的方式也存在一定的局限性。

8.2.1）不适用于个性化要求高的场景：

由于消息在公共信箱只存储一份，下发消息内容固定，无法很大程度下，下发个性化消息（当然也不是一定无法下发个性化的消息，可以通过在公共信箱存储消息模板，根据拉取消息的用户ID获取个性化信息，在消息拉取时，临时拼装消息，这样就增大了消息拉取时的代价）。

8.2.2）不适用于实时消息提醒场景：

1）从业务场景上看：全量消息优先级低，不需要在全量生效的瞬间让用户感知。

2）从实现上看：全量消息实时消息提醒成本高。因为实时消息提醒Notify，需要以类似单播的形式实时通知用户。和单播的区别是，Notify不用触达离线用户，也就是不用写用户信箱，只需实时触达在线用户。

3）从系统压力看：全量在线用户均收到实时新消息提醒，会带来信箱拉取请求的瞬时流量（手机百度IM SDK长连接峰值在线1550W，假定新消息提醒在瞬间下发，同时在线用户信箱拉取请求，会把db打挂的）。

9、基于公有信箱技术方案的落地实施效果

全量消息目前已经在百度APP得到应用，包括：重大通知的下发；百度APP功能更新介绍通知；消息的撤回，后续还将推广到其他的矩阵APP的全量通知推送场景。

举个具体的例子：22年Q4宣布疫情解封时，利用全量消息推送，低成本、高时效的完成3条“疫情解封专项”全量消息下发。

在这个例子中，三次全量消息下发，到达数据在2亿+（该值小于月活的6亿+），主要因为几个原因：

1）本次全量消息有效期仅3天左右，全量消息有效期内登录IM SDK的用户才有机会拉到全量消息；
2）本次下发使用了新的消息展示模板，所以限制了拉取全量消息的百度APP版本，只有高版本百度APP可以拉到；
3）本次全量消息，限制了仅有百度APP登录用户拉取。

10、未来展望

本文介绍了现有IM消息中台系统，并通过公有信箱技术方案的改造，达成了低成本、高分发速度完成全量用户消息下发的设计、实现与应用。

在全量用户消息应用方面，除了业务上的使用，后续也可以用于广播消息、批量单播消息的撤回。比如由于误操作发送了广播消息，用户已经把广播消息拉到了端，并持久化到端，这是可以“以全量消息的方式，下发删除指令”，删除已经缓存到端的垃圾消息。

我们希望，通过消息系统持续不断优化，为更多的业务提供低成本、高稳定性的即时通讯能力。

11、相关资料

[1] 现代IM系统中聊天消息的同步和存储方案探讨

[2] 百度APP移动端网络深度优化实践分享(一)：DNS优化篇

[3] 百度APP移动端网络深度优化实践分享(二)：网络连接优化篇

[4] 百度APP移动端网络深度优化实践分享(三)：移动端弱网优化篇

[5] 百度直播的海量用户实时消息系统架构演进实践

[6] 深入了解百度开源的分布式RPC框架brpc的方方面面

[7] 百度网盘千万节点的P2P架构设计(PPT)

[8] 零基础IM开发入门(一)：什么是IM系统？

[9] 一套海量在线用户的移动端IM架构设计实践分享(含详细图文)

[10] 一套原创分布式即时通讯(IM)系统理论架构方案

[11] 一套亿级用户的IM架构技术干货(上篇)：整体架构、服务拆分等

[12] 基于实践：一套百万消息量小规模IM系统技术要点总结

[13] 一套十万级TPS的IM综合消息系统的架构实践与思考

[14] 从新手到专家：如何设计一套亿级消息量的分布式IM系统

[15] 闲鱼亿级IM消息系统的架构演进之路

[16] 深度解密钉钉即时消息服务DTIM的技术设计

[17] 一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践

[18] 企业微信的IM架构设计揭秘：消息模型、万人群、已读回执、消息撤回等

（本文已同步发布于：http://www.52im.net/thread-4235-1-1.html）

技术揭秘！百度搜索中台低代码的探索与实践

一、关于低代码

低代码是软件系统的快速开发工具，开发者无需编码就可以实现常见的功能、少量代码即可完成功能扩展，从而实现便捷构建应用程序。随着企业数字化需求的快速增长，传统的软件开发方式的低下生产效率，成为制约企业数字化转型的主要矛盾，低代码得到快速发展。相比传统的软件开发模式和工具，低代码的开发门槛更低、研发效率更高；相比其他的快速开发工具，低代码的扩展性更高，可以胜任复杂场景下的核心开发诉求。研发效能也一直是各大互联网企业关注的焦点，随着近几年的探索和发展，市场上出现了众多的低代码平台，低代码也受到了越来越多的关注。

目前业界低代码框架主要解决的是一般领域的通用需求，可以低成本的拖拽组件来打造前后端一体的应用，主要用于 BRM（业务规则管理）、ERP、CRM等系统的快速研发。但是这种方式对专业领域的中后台开发者并不适用，他们面对的是复杂多样的场景，他们专注的问题是如何维护已经达到十万、甚至百万的代码，如何快速迭代、策略优化实现业务可持续增长，如何治理与保障服务的稳定性等等。如果低代码工具只能创建带界面的数据库应用，支持简单工作流场景，并不能给后者带来实际帮助。

搜索中台从业务场景和业务痛点出发，借鉴业界低代码理念，对复杂的后端系统开展了低代码探索和实践之路。工欲善其事，必先利其器，希望通过打造新的生产力工具，更高效地实现产品创新。

二、我们面对的场景

搜索中台为业务提供两种接入方式，一种是使用者以配置化的形式进行定制，之后使用提供的API接口访问中台的能力，另一种是允许使用者以代码开发、部署服务的形式在中台内部系统中进行定制，实现高度灵活的产品逻辑。前者更加接近“无代码”，但是扩展性和灵活性不够，应对的是一般性需求，后者我们在中台系统内提供了应用引擎（以下称Search-AE），业务可以直接入场开发，通过代码实现检索需求定制，满足更加灵活的业务场景。

随着深耕业务场景的规模爆发式增长，大量应用开始涌入 Search-AE，目前已经包含了200+ 独立业务系统。在需求高速迭代、规模快速增长的情况下，效能上面临的问题也越发凸显：

缺少有效沉淀

在 Search-AE 发展之初，各个业务更多的是纵向发展，通用功能很难沉淀，应用之间的能力共享主要通过 copy-paste 来完成，而这些代码在一段时间的迭代后，又会因为一些微不同导致其往各自的方向发展，最终业务之间完全演变成各自独立的系统，本可以复用的能力变的更加难以有效沉淀。
高速迭代下系统的复杂性加大

随着需求的快速迭代，业务系统的代码量和架构复杂度也在快速提升，部分业务代码量级已经发展到数十万级别的规模。同时业务需求又是第一位的，大家都在被需求推着走，开发过程中很难保证对文档做出有效沉淀。接手同学在维护迭代时只能通过大量源码去理解系统，难以保证高效开发。
研发全流程操作繁琐

搜索本身很复杂，尤其在经历过多年的发展后，搜索系统成为链路长、连接复杂的大型分布式系统。环境部署、调试预览等都会对业务研发产生一定的负担。另一方面，研发全流程需要接触不同的工具平台，这些平台没有从全流程的维度去规划设计，它们之间的跳转、使用也会产生学习成本。有一个实际场景的例子：开发一个业务需求，先花一周时间读懂代码评估代码的修改点，再花一周去配置整套环境，还要花一周时间熟悉研发流程中的工具链，而真正写代码可能只需要一天。

总体来看，我们要解决的问题是：如何更快开发——少写代码，更快上手——系统易理解，更快交付——全流程操作简单。

三、思路与目标

业内的一些低代码平台主要聚焦的是前端的场景需求，将页面元素封装成通用组件，使用者拖拽这些组件实现页面形态的定制。搜索中台面对的是中后台场景，但是要解决的问题和思路是非常类似的。从每个业务的实际情况看，虽然最终的检索场景各不相同，但执行的功能流程都有一定的相似性，如果我们把通用的功能抽出来，业务通过组合这些通用能力来满足需求，就可以显著提升效率。同时，这些通用能力是标准化的，业务可以按标准规范进行开发，开发生态易于分享和使用，针对通用算子满足不了的业务场景，大家就会补充更多的通用组件，在下一次类似需求来到时快速满足。

统一业务框架：图引擎 & 图编排

我们的解决思路是使用图引擎来驱动业务逻辑的执行，通用和定制的能力都以算子形式提供，业务则以 DAG 图的形式串联这些算子。图本身没有一套固定的流程，算子间的连接和使用完全由业务场景决定，所以即使是完全差异化的业务都可以使用图引擎来构建系统。并且，图和算子定义了一套标准规范，开发的产品功能都通过算子的形式对外暴露，而算子又是可以插拔的，业务之间都可以方便的拿来复用。

但是，仅仅有图引擎是不够的，我们需要让算子在业务的使用之下快速沉淀起来：业务愿意去共建通用算子，并且这些算子对业务能够充分共享，即大家可以便捷的查看和使用这些通用算子。而使用图编排工具，可以以平台化的形式对这些算子进行呈现，研发同学可以快速的查看所需功能算子，也可以通过可视化拖拽低成本的配置使用。

建设图编排工具还有一个很重要的出发点是：我们希望通过可视化的图帮助开发同学快速的了解业务系统。这个图既是系统的实际运行图，也是帮助快速理解系统的执行流程图。我们使用图编排进行可视化之后，图本身就具备自解释性，研发同学可以在图上补充备注信息，图就相当于和代码同步的天然文档。对有一定规模的业务来说，通过“图文档”理解系统要比读源码理解更快，更加自然易懂。

全流程一站式研发

除了代码开发上的改善之外，我们希望有一套统一的工具对研发全流程进行提效：在图编排的基础上打造 All-in-one 的开发平台，将研发流程各个单点能力横向集成与拉通。业务研发者在研发过程中不需要学习对接各种开发工具或平台，所有的研发工作都收拢在一套工具里解决。同时这套流程又是标准化的，过去研发过程中所有的飞线技术栈都能统一起来，使用更加高效便捷的标准化解决方案。业务有能够提升效率的方式、工具也可以往这套工具里进行沉淀，共同打造。

四、Nimbus 低代码平台的设计与实践

我们在 iCoding（公司代码开发 IDE）的基础上建设了 Nimbus 低代码平台，所以 Nimbus 天生就拥有了 IDE 包含的代码开发、编译调试等基础能力。对使用者来说，研发全流程的操作都可以在 IDE 内部完成，不需要对接外部工具系统，提供了很大的便利性。我们将研发全流程划分为五个阶段，分别是环境准备、开发、预览调试、测试和发布运维。每个阶段 Nimbus 都组建了适合的工具来降低开发者的研发成本。

一键生成线上同步的开发环境，开箱即用

在工程效能部同事的支持下，我们建设了可以开箱即用的云端开发环境。业务开发者在代码仓库可以一键申请开发镜像，后台会在云端拉起一个 Docker 容器，容器内运行着 iCoding 的服务端，可以使用浏览器的形式连接开发镜像，也可以使用 iCoding 客户端进行连接。

镜像内包含代码库、开发过程中的全部工具、服务编译运行所需要的全部依赖包、线上同步的服务配置词典等，业务开发者不需要额外的配置就可以直接开始开发。同时所有用户的开发环境也是完全一致的，不会因为系统、SDK、配置的不同导致的问题影响。当用户长时间未连接开发镜像时，镜像会自动挂起闲置，节省机器成本。镜像也可以分享给其他用户，便于问题排查。

在打包镜像的过程中我们发现应用的依赖非常多，如果将这些依赖都放入镜像中会导致镜像体积过大，不仅影响镜像的拉起时间，也对机器的磁盘空间造成很大压力。初期我们将这些依赖都放到 NFS 里，在镜像内通过 fuse 进行挂载，但是会导致业务无法修改这些依赖，在一些场景下使用体验不佳。我们又基于Overlayfs 虚拟了一层联合文件系统，用户看到的只是一个普通的文件系统目录，可以任意修改替换。实际文件系统则包含两层的合并内容，Lower 层指向了公共的 NFS 集群，里面有全部的依赖文件，和线上实时更新，Upper 层指向镜像的工作目录，用户可以修改 Lower 层的文件，修改后会自动移到 Upper 层，Lower 原始数据不受影响。使用 Overlayfs 后我们的镜像拉起速度非常快，绝大部分依赖都放到远程，开发镜像只需要5秒钟就可以拉起。

可视化拖拽算子，快速组建复杂场景

开发过程中，使用者可以在 Nimbus 中打开图编排工具来拖拽算子。每个算子都会有详细的描述信息，比如名称、类别、用途、属性等。这些信息通过注解的方式在代码中进行声明，图编排工具会扫描这些算子代码，读取相应的注解信息，并添加到算子仓库中。业务开发同学可以在图编排中对算子仓库中的算子进行浏览或检索，通过拖拽组建适合的业务场景执行图。拖拽后图的连接配置会直接保存到业务的代码库，下次打开可以重新加载。

在图编排工具中，我们也添加了一些交互来提示研发同学在图中添加算子、边的详细备注，帮助其他同学基于图快速了解系统。一些领域的问题可能具有相当的复杂度，用一张图表示并不直观，我们提供了子图的功能，可以将图与图之间关联在一起。开发者在图编排中可以双击跳转，也可以通过Peek 功能快速查看子图的结构。对于复杂的业务场景，研发同学就可以借助子图来层级递进的理解系统。

Nimbus 是在 IDE 基础上进行的设计，所以图编排可以和代码开发紧密关联在一起。在图中双击算子单元能够直接跳转到具体的代码实现，方便用户实际开发。图编排中也集成了调试分析的功能，用户可以在图中任意算子增加断点查看输入输出，也可以观察整个图的执行状况，各个阶段的耗时，通过图的执行过程快速掌握业务逻辑。

在实际的使用过程中，我们和业务同学将一些最优实践，高频出现的业务场景抽象成了通用的图模板，这些通用图模板可以直接在 Nimbus 中进行打开，业务可以在这些模板的基础上进行定制，为构建新场景时提供帮助参考。

免配置的端到端效果调试，使用更友好

预览调试过去一直是很繁琐的问题，系统的链路和模块太复杂了，尤其对新人来说是一个很大的挑战。Nimbus 提供了功能强大的预览工具，同时支持直连请求和端到端的效果调试。我们和 QA 同学一起搭建了沙盒环境，完全复刻了线上的在线模块，并和线上模块保持同步更新。在调试端到端的过程中，Nimbus 会将请求转发到沙盒环境，请求开发中的业务模块时，沙盒环境会拦截该请求，转发到实际开发调试的服务。新的效果预览方式中预览环境的大部分模块都使用公共服务，显著节省机器成本，同时省去了环境部署、同步更新的人力成本。

调试过程中，我们也可以通过 Nimbus 进行可观测性分析，如 logging、tracing 等等。Nimbus 中也打通了 IDE 的 live debug 功能，支持用户快速进行代码的断点调试。

现代化的测试工具集，集中在测试本身

过去测试流程主要依赖人来驱动，研发同学开发自测完之后，QA 同学需要将服务部署在测试环境，因为依赖较多，部署过程中需要 RD 和 QA 的反复沟通对接才能建立完整的测试环境。Nimbus 连接了一套公共测试集群，研发同学开发完之后可以一键部署仿真实例，仿真实例通过线下的 Paas 平台进行部署，环境和线上基本一致，可用于性能压测、效果验证等。同时 Nimbus 支持自动化回归测试功能，我们定期录制了线上流量，发起自动化回归时，Nimbus 会自动部署基线实例和测试实例，发送录制流量来生成 diff 以及性能报告，用于评估上线风险。

智能化的容量管理，快速适应服务变化

Search-AE 内混布了大量的业务模块，高峰期有百万级 QPS，服务的容量规划一直很难处理。搜索流量本身变化较快，加上业务频繁迭代，线下需要反复压测评估合适的部署方案。同时线上一直在变化，之前合适的部署方案可能因为上下游变更又产生资源不足或浪费。过去线上的容量问题一直需要研发和运维关注，我们希望在 Nimbus 中能够用全局视角统一的管理线上容量，让业务同学只需要关注在实际的代码开发上。

智能容量管理要解决的问题是在满足稳定性要求的前提下，确定各个服务的部署计划，让 Search-AE 整个集群的资源占用最少。智能容量管理的处理包含触发、分析和决策三个阶段。触发阶段包含三种情况：一种是业务迭代变更时会触发容量分析，第二种是线上持续的轮转服务触发分析，第三种是线上实际资源占用达到某个水位时触发快速分析。分析阶段主要的数据输入包含：

和线上一致的仿真实例，阶梯递增的QPS压测下的资源占用、速度 SLA曲线。
现在及历史的QPS、耗时数据。
现在及历史的资源占用 Load 指标。

通过这些数据分析系统会综合判断服务是否需要变更部署安排，最终通过底层的调度引擎触发服务调整。过去大部分容量变化都依赖人去做评估调整，有了这套工具后，线上服务的部署调整就可以实现自动化。

五、总结与展望

业务创新加速，在需求越来越多、迭代越来越块、创新能力要求越来越高的背景下，如何通过技术手段为业务开发降本增效提质做出突破，是搜索中台、也是众多产品研发平台需要思考和解决的问题。搜索中台从业务场景和业务痛点出发，借鉴业界低代码理念，对复杂的后端系统深入开展了低代码的探索和实践，据此形成一套从技术思路、到系统能力、再到业务运营可借鉴可复用的复杂后端系统低代码解决方案，整个解决方案包含3个关键组成：

基于图引擎&通用模板通用算子&业务微定制算子，打造低代码能力引擎，帮助业务少写代码
打造低代码一体化平台，通过能力集成和可视化开发实现研发流程的全生命周期管理，帮助业务高效交付
重视用户培育，营造共创氛围，促进创新生产力工具的应用、推广和共建，帮助低代码现代化生产力工具在实战中快速成长

低代码一体化平台Nimbus正式发布以来，在多个业务取得了显著收益，并收获了早期用户的高满意度和良好口碑，验证了通过低代码实现复杂业务场景降本增效提质的切实可行。它是一套工具，也是一套标准，我们期望打造开放共创的生态，前台和中台同学都可以基于这套标准来沉淀更多的通用算子、研发能力、应用案例和实践经验等等，而这些可以支撑我们进一步向更低代码、更高效能去迈进。在低代码的征途上，我们已经扬帆起航，将继续乘风破浪，勇往直前。期待搜索中台低代码一体化平台能够广泛应用、深入人心，促进多元业务高效率、高质量、低成本的敏捷迭代，为加速业务创新和发展做出更多贡献。

推荐阅读：

｜百度搜索中台海量数据管理的云原生和智能化实践

｜百度搜索中“鱼龙混杂”的加盟信息，如何靠AI 解决？

｜快速剪辑-助力度咔智能剪辑提效实践

---------- END ----------

百度 Geek 说

百度官方技术公众号上线啦！

技术干货 · 行业资讯 · 线上沙龙 · 行业大会

招聘信息 · 内推信息 · 技术书籍 · 百度周边

欢迎各位同学关注

以上是关于揭秘百度IM消息中台的全量用户消息推送技术改造实践的主要内容，如果未能解决你的问题，请参考以下文章

阿里IM技术分享：闲鱼亿级IM消息系统的离线推送到达率优化