1. 项目背景与核心需求拆解1.1 PLFM_RADAR 到底是什么我最初做 PLFM_RADARPlatform Radar平台雷达动机很简单那段时间我在做内容平台的日常运营巡检每天要手动点开几十个页面去看有没有新增的公告、竞品动态、行业事件。靠人肉盯屏效率低不说还经常会漏掉凌晨或周末发布的更新。手动方案最大的痛点其实不是慢而是“不可持续”——今天状态好能盯住三个平台明天会议一多就全忘了。PLFM_RADAR 就是为解决这个场景做的一个轻量级信息监控系统核心思路跟雷达的工作原理一模一样雷达不停向周围发射电磁波碰到目标就反射回来系统根据回波识别目标的位置和类型。这个项目里每一路“波束”就是一个信息源采集任务它会按照设定的频率去扫描目标平台把新出现的信号公告、文章、话题、状态变更抓回来经过清洗、去重、评分之后推送到我指定的地方。说白了它就是在互联网侧帮我放了一个 7×24 小时值班的哨兵。这个项目最适合谁用如果你手里同时管着好几个平台账号或者需要持续关注竞品、行业政策、监管公告的更新又或者你想给自己运营的内容号做一个自动化选题监控PLFM_RADAR 都属于那种“花一个周末搭起来之后每天省两小时”的工具。它不需要你有很深的技术背景懂基本的 Python 和 Linux 操作就能跑起来。1.2 为什么叫“雷达”而不是“爬虫”或“监控”名字听起来像爬虫但我在设计定位时刻意跟传统爬虫划清了界限。传统爬虫的目标是“尽可能全量地把一个站点的内容搬下来”它关心的是数据量和覆盖率而 PLFM_RADAR 关心的是“增量、时效和信号强度”。雷达不需要把整个天空看清楚它只需要在扫描范围内发现“新目标”并判断“这个目标值不值得关注”。这个定位差异直接决定了整个系统的架构形态。很多爬虫框架一上来就是 Scrapy 代理池 分布式调度复杂度蹭蹭往上涨而雷达系统可以做得非常克制数据源少而精解析规则稳定重点放在“识别变化”和“衡量价值”这两件事上。与其说这是一个采集系统不如说它是一个信号处理系统。正因为想通了这一点我后续没有陷入“采集源不够多就疯狂加源”的怪圈而是先把单个源的质量和准确率打磨到位。1.3 核心需求拆解与落地清单我当时的核心需求拆下来一共五条定时巡检指定的信息源支持不同源设置不同频率比如公告类的每 30 分钟扫一次行业资讯类的每 2 小时扫一次对抓回来的信息做去重和归一化同一个事件在多个平台出现时只保留一条聚合记录避免重复告警对每条信息算一个“优先级分”根据来源、关键词命中情况、时效等维度打分分数高的内容优先展示、优先通知提供一个简单的可视化看板让我一眼看清过去 24 小时哪些信号源最活跃、哪些关键词正在升温告警推送到钉钉/企业微信这类群机器人手机端也能收到通知。基于这份清单我在设计时把项目划分成了四个模块采集层负责探测与抓取、处理层负责清洗、去重、评分、存储层负责数据和状态的持久化、展现层负责看板和告警。下面的内容我会逐个模块讲清楚实现思路和关键代码。2. 系统架构与核心技术选型2.1 整体分层设计说明PLFM_RADAR 的技术栈不算新但每个组件的选择我都是认真比较过替代方案的。后端用 Python 3.11 FastAPI数据库用 PostgreSQL缓存和队列用 Redis前端看板用 Vue 3 Element Plus部署用 Docker Compose 一把梭。之所以选这套组合一方面是因为我熟悉另一方面是这套东西在社区里的案例实在太多出了问题很容易找到解决方案。分层上采集层以 5 分钟为最小调度单位支持自定义 cron 表达式处理层从 Redis Stream 拉取原始消息做标准化后写入 PostgreSQL看板层直接查 PostgreSQL 的物化视图没有额外引入 Elasticsearch。这是很多朋友会问的地方——为什么不用 ES我的回答是量级没到那个程度。PLFM_RADAR 每天处理的信息量撑死也就几万条PostgreSQL 配上合理的索引完全扛得住引入 ES 只会增加运维负担。选型不是越重越好而是刚好够用最好。2.2 为什么用 PostgreSQL 而不用 MongoDB我在一开始确实考虑过 MongoDB因为原始采集数据大多是半结构化的 JSON用文档型数据库似乎更省事。但实际推演下来PLFM_RADAR 的查询模式主要是“按时间范围聚合统计”“按关键词过滤”“按去重指纹查重”这些都是典型的关系型查询而且 PostgreSQL 的 JSONB 类型同样能存文档结构还能给 JSON 里的字段建索引。比如payload-title这种表达式索引查询性能和灵活性都不输 MongoDB。另一个重要的考量是事务与约束。去重逻辑需要在“插入新记录”和“更新已有记录”之间做原子操作PostgreSQL 的INSERT ... ON CONFLICT语法能在一个语句里完成不需要在应用层加分布式锁。这一点对单体应用来说是非常友好的。2.3 Redis 在项目里扮演的角色Redis 在这个项目里存储三类数据一是采集任务的状态标记上次扫描的游标位置二是原始消息队列三是评分用的临时计数。其中队列部分我选择用 Redis Stream 而不是普通 List原因在于 Stream 天然支持消费者组万一处理端崩了重启后可以从上次消费的位置继续不会被重复消费或者丢消息。而且 Stream 的XREADGROUP命令支持阻塞读取消费者可以挂在那里等新消息省掉了自己写轮询的麻烦。另外Redis 的过期时间机制也被我用在了“热点词缓存”上。同一个关键词在 10 分钟内如果被反复命中我会先把计数放在 Redis 里累加而不是直接写数据库这样既减轻了数据库压力又能快速算出“这个关键词正在升温”这样的信号。后面评分模块会用到这个数据。3. 采集层实现多源接入与解析的实操细节3.1 数据源适配器的设计思路PLFM_RADAR 的每类数据源对应一个适配器我抽象了一个基础接口核心方法只有三个fetch()、parse()、normalize()。fetch()负责拉取原始内容parse()负责把不同格式的响应转成统一的中间结构normalize()负责把中间结构清洗成标准字段。为什么要把接口切得这么细因为不同信息源的数据格式差异实在太大了。RSS 给的是 XML开放 API 给的是 JSON还有一类的页面没有现成的接口只能自己解析 HTML。如果这三个步骤不分层后面每接入一个新源就可能要把前面的代码全部重写一遍。现在分了层接新源时大多数情况下只需新写一个parse()方法其余逻辑全部复用。以 RSS 源为例fetch()用 httpx 发一个 GET 请求parse()用标准库的xml.etree.ElementTree提取item节点normalize()把标题、链接、发布时间统一成 ISO 8601 格式。整个适配器只有不到八十行代码但已经能稳健地处理绝大多数 RSS 源。HTML 类型的源会麻烦一些需要在parse()里用 BeautifulSoup 的 CSS 选择器精准定位列表节点这里要特别注意选择器不要写得太松否则会把导航栏、页脚里的链接也抓进来导致大量垃圾数据。3.2 采集调度的频率控制与游标管理调度模块我一开始用的是 APScheduler直接写在进程里后来把它换成了独立的调度器基于 cron 表达式驱动。原因是 APScheduler 在长时间运行时偶尔会出现任务堆积而独立调度器配合 Redis 的分布式锁可以在多实例部署时保证同一个任务不会同时在两个节点上执行。频率控制上我遵循一个原则对目标平台的请求频率不高于 1 次/分钟。即使技术上能做到更快的轮询也要克制。原因很简单绝大多数开放平台都有访问频率限制你按照它的规则来它最多给你限流你把它惹毛了可能直接封掉出口 IP。我实际把采集间隔默认配置成 5 到 30 分钟不等公告源短一些资讯源长一些。游标管理这个细节很容易被忽略。很多源是分页接口你不能每次从头开始翻第一页那样既浪费请求数又容易抓到老内容。我在 Redis 里给每个源维护一个last_cursor字段轮询时从该值对应的位置开始增量拉取。对于基于时间的源比如按时间倒序的资讯站游标就是最后一条已处理记录的时间戳对于基于页码的源游标就是“已连续翻到多少页没有新内容”。这套逻辑跑了一段时间之后重复抓取率明显下降。3.3 HTML 解析场景用 BeautifulSoup 还是 XPath如果你需要解析的 HTML 页面结构比较稳定用 XPath 写起来非常简洁比如//div[contains(class, list-item)]//a/href一行就能把所有目标链接提取出来。但 XPath 的弱点在于页面改版时表达式可能整段失效排查成本高。BeautifulSoup 的 find 系列方法虽然代码长一些但容错性好对属性顺序变化不敏感。PLFM_RADAR 里的 HTML 适配器两个方案都用了我的经验是如果只是提取链接和文本首选 BeautifulSoup如果要做复杂的数据清洗比如根据兄弟节点、父节点关系做条件过滤XPath 更适合写入配置文件因为可以交给运营同事调整不用改代码。无论用哪种方案解析后都要做一次“内容纯净度校验”把纯导航文本、空链接、重复链接直接过滤掉再进入指纹计算环节。4. 处理层实现清洗、去重与优先级评分4.1 数据归一化的字段标准进入处理层的原始数据需要统一成一套标准结构。我定义的最小字段集是这样的source_id数据源标识比如rss_36kr、api_weibo_hottitle标题或摘要文本url原始链接作为最终页面的唯一指向published_at发布时间统一转成 UTC 时间的 ISO 8601 字符串raw_payload原始响应体的 JSON 快照用于追溯排查。其他字段都是可选扩展。比如招聘类源会多一个company_name活动类源会多一个start_time。这种“最小公共字段 纵向扩展字段”的做法是为了防止后续接新源时被某个源的专属字段绑架。归一化过程还有一个容易被忽视的点编码。HTML 页面经常出现amp;、nbsp;这类实体解析出来的文本要统一做反转义。中文内容还要处理全角半角空格、零宽字符等问题。零宽字符坑过我好几次它在页面上完全不可见却是不同的 Unicode 码点如果不做归一化会导致两个看起来一模一样的字符串在指纹计算时被判定为不同内容产生大量重复告警。4.2 指纹生成与去重最关键的 10 行代码去重是整个系统准确率的根基。如果去重没做好看板上全是重复信息告警群也会被刷屏整套系统的可信度瞬间归零。我用的是“内容签名”方案把归一化后的标题做分词、排序、拼接再配合链接的域名部分和发布时间精确到小时做一个 SHA-256 哈希作为这条消息的唯一指纹存入数据库的唯一索引。// 伪代码示例 fingerprint sha256( |.join([ normalize(title_tokens), // 分词后排好序的标题词 urlparse(url).netloc, // 获取域名排除具体路径影响 published_at[:13] // 精确到小时的时间桶 ]) )这里有一个很微妙的取舍为什么指纹里要包含域名和小时时间桶而不是直接用标题做哈希因为同一个事件经常被多个平台报道标题措辞会略有差异如果只对标题做严格哈希根本起不到跨源聚合的作用。而加入域名和时间桶之后可以做到“同一句话在不同平台出现时只要标题分词基本一致就会命中同一个指纹”达到合并同类的效果。去重写入时使用 PostgreSQL 的INSERT ... ON CONFLICT (fingerprint) DO UPDATE语法每次收到新消息要么插入新记录要么更新已有记录的last_seen_at字段和出现次数。这样一条聚合记录天然自带“热度”属性——被多少个源报道过、最近一次出现是什么时候全都能直接查出来。4.3 优先级评分关键词加权与衰减模型有了唯一的聚合记录下一步就是决定哪些内容值得立刻通知、哪些内容只需要“看板可见即可”。我设计了一个简单的评分模型一共三个维度来源权重默认 1.0权威源和核心平台的源配置 1.5 或 2.0关键词权重命中“重大/紧急/最新/监管/合规/上线”这类词加 10 分命中“公告/更新/修复”加 5 分普通词不加分时效系数发布至今不超过 30 分钟的内容系数为 1.0之后每小时衰减 0.15最低降到 0.2。最终分数 来源权重 × 30 关键词命中分× 时效系数。举个例子一条来自核心平台公告源的“关于发布新版隐私政策的公告”发布 20 分钟来源权重 2.0命中“公告”和“发布”两个词加 10 分算出来就是2.0 × 30 10× 1.0 70 分同一时间一条来源权重 1.0、没有关键词命中的普通资讯分数大概只有 20 多分。我设置的告警阈值是 50 分这样高分内容才会推送到手机端普通内容只留在看板上日常噪音大幅减少。这个模型的参数我建议一开始别追求完美先用默认值跑两周看误报和漏报的情况再调整。调参数的时候不要只调分数阈值更关键的是梳理关键词表把那些你根本不想看的高频词比如“抽奖”“签到”加进负向词表命中负向词直接扣 20 分甚至一票否决。4.4 规则引擎把配置开放给运营评分逻辑如果写死在代码里每次调整都要发版体验非常差。我把规则外置成了一个 YAML 配置文件采集服务启动时加载同时监听文件变化修改后热更新不需要重启进程。rules: source_weight: rss_36kr: 1.5 api_weibo_hot: 2.0 keyword_boost: - text: 监管 score: 10 - text: 下架 score: 8 negative_words: - 抽奖 - 签到 - 优惠券这样运营同学可以自己在配置文件里加词条、调权重技术侧只需要保证配置加载和校验的可靠性。这个项目做到后面大部分迭代其实是调整这个 YAML而不是改代码。把一个偏技术的工具慢慢变成一个偏运营的配置系统是我觉得 PLFM_RADAR 这个项目最成功的地方。5. 存储与可视化看板页面和告警推送5.1 数据库表结构与索引设计后面我可能逐步开源这个项目数据库建表我贴一下核心部分。聚合记录表的核心字段包含fingerprint、title、source_id、url、published_at、first_seen_at、last_seen_at、occurrences、score。因为查询模式固定索引只需要三个fingerprint唯一索引用于去重published_at普通索引用于时间范围查询score普通索引用于排行榜查询。以前我习惯把能建索引的字段全建上结果写入性能明显下降后来才意识到索引是拿写入换查询建之前必须确认查询模式。PLFM_RADAR 的查询模式非常固定三个索引刚好覆盖全部常用查询。5.2 看板页面三个核心视图看板页面我做了三个视图总览、信号流、趋势分析。总览页展示过去 24 小时的信号总量、高分信号数、各源活跃度排行信号流页就是一个带筛选条件的信息列表支持按分数、来源、关键词过滤趋势分析页则按小时聚合展示信号频次曲线能直观看到什么时间段是信息发布高峰期。这三个视图里最花心思的是信号流页。列表默认按分数降序排列但分数高的内容不一定是最新的所以界面上同时展示了“first_seen_at”和“published_at”两个时间字段。一开始只展示一个时间运营同学反馈“为什么排序不是按时间”我解释之后发现其实是信息展示不全导致的误解加了时间字段后就没再有类似问题了。这类体验问题不需要很高深的技术但很影响系统的实际可用性。5.3 告警推送企业微信机器人的接入推送告警是企业微信群机器人一个 Webhook 地址搞定。我封装了一个notify.py核心逻辑就三步构造消息体、POST 到 Webhook、处理限频响应。企业微信机器人的限制是每秒钟最多发 20 条消息对于这种信号通知场景完全够用。消息格式我用了 markdown 类型标题加粗正文带上分数、来源、原文链接。实测下来手机端收到的卡片长文完整、链接可点体验比纯文本好很多。需要注意的是 Webhook 地址本身包含密钥信息千万不要写死在代码里提交到公开仓库放环境变量或者本地配置。5.4 告警聚合避免同一事件连环轰炸有一个很实际的问题同一事件在半小时内被多个平台报道雷达会生成多个聚合记录吗会但通过指纹里的时间桶和标题分词它们大概率会归并到同一条记录上。不过有时候标题差异很大比如一个平台的标题是 A另一个平台的标题是 B指纹对不上就会产生两条高分记录导致告警群在短时间内连环轰炸。我解决这个问题的办法是在通知层加了一个“告警聚合窗口”同一个来源的告警在 10 分钟内只发送一条发送时把多条待通知消息合并成一封摘要消息。比如“过去 10 分钟共 3 条高分信号A、B、C”。这样即使指纹归并不完美用户体验也不会被破坏。实现上只需在 Redis 里维护一个alert_window:{source_id}的字符串键设 10 分钟过期过期之前新消息不触发发送只追加到待发送列表里。6. 常见问题与排查技巧实录6.1 采集到的内容突然变少了排查思路先从“数据源是否正常响应”开始。常见原因是目标平台改了接口参数或 HTML 结构适配器的解析规则失效。我处理过三次类似问题两次是 HTML 类源增加了类名后缀导致 BeautifulSoup 选择器匹配不到一次是 API 增加了分页参数限制不传新参数时最多返回 1 页旧数据。建议在采集任务里加一个“最小基线”监控每个源过去 7 天的平均单次采集量如果某次低于基线的 20%自动打一条 WARN 日志并在看板总览页标红。这个机制能帮你在用户发现之前先知道自己哪里坏了。6.2 重复率居高不下重复率高通常有三种原因第一指纹生成逻辑太严格标题稍有不同就算新内容第二zero-width 字符或全角半角问题没做归一化第三游标没往前走每次都在扫同一批老数据。排查时先看指纹生成前的中间结果用一段测试脚本把同一文章的不同标题变体都跑一遍确认差异点到底在哪一步。6.3 Docker 部署的几个坑PLFM_RADAR 我用 Docker Compose 部署在了一台 2 核 4G 的 VPS 上跑了一年多很稳定。但中间踩过几个坑容器内时区默认是 UTC而看板时间要展示东八区必须在 compose 里设置TZAsia/Shanghai否则时间全部偏差 8 小时PostgreSQL 容器第一次启动时初始化数据较慢如果采集服务比数据库先启动会因为连不上库而崩溃退出需要在 healthcheck 里检查pg_isready等数据库就绪后再启动其他服务Redis 的maxmemory默认值是 0不限制如果不设置长时间运行缓存会占满内存。建议设置maxmemory 512mb和allkeys-lru淘汰策略。6.4 告警发不出去怎么办先确认 Webhook 是不是新创建的。企业微信群机器人创建时勾选了“加签”的话签名校验方式是 SHA1 加密需要在发送时带上时间戳和签名字段不勾选加签则是纯 URL 地址就能用。其次是确认发送频率同一机器人连续发送太快会触发流控错误码里会告诉你errcode45009这时候在发送前加一个 2 秒的 sleep 就能规避大多数流控问题。7. 一些实际操作之外的体会PLFM_RADAR 从最早的一个查公告的脚本慢慢长成了一个带看板、带告警、带评分模型的信息雷达系统整个过程里我最大的体会是技术选型坚持“够用就好”。没有上微服务、没有上消息中间件、没有引入大数据组件全部数据量在一张 PostgreSQL 表里就能搞定架构非常清爽。如果现在让我重新设计一遍我可能还会保留这套核心结构但在采集源的类型上会多支持两种一种是 JSON Schema 类型的半结构化 API因为现在很多平台的开放接口都是这种格式另一种是状态变化型的源比如某个系统页面上某个开关按钮的状态变化这两种源在项目后期需求量很大。具体代码结构上采集适配器和数据源配置之间的解耦对比最初版本已经有了很多改进。最后分享一个小技巧整个系统上线运行稳定后我给自己留了一个定时清理任务每周末把occurrences1且score 20且发布超过 30 天的记录物理删除免得历史噪声数据不断积压。数据该删就删保留所有原始数据在真实运营场景里大多是心理安慰反而拖慢查询和备份时间。这套做法让我这台 2C4G 的小机器一直跑得很轻松。