rea这个代号是我在某个内部监控项目里随手敲下的缩写。它没有特殊含义资料里找不到正式定义但就是这么个不起眼的代号在项目里承担了从服务器状态页到告警信息大屏的实时数据展示工作。这不算什么高难度业务难点在于它是被“顺手要求”加进一个几乎已经上线的系统里的原系统有数据上报、有存储、有告警规则唯独缺一块能让运营和值班同事直接看到实时状态的界面。接手的时候第一版需求只有一句话“做一个能自动刷新、别让页面白屏的监控面板。”真正动手以后我才发现这句话背后的坑比想象中多得多。1. rea是什么从一个被低估的监控需求说起1.1 一个差点被砍掉的内部小需求当时团队维护的监控系统已经跑了大半年后端定时的告警、统计报表都有但展示端一直很弱。值班同事要看状态只能打开一个静态页面然后手动按F5要是忘了刷新就可能盯着一个红色告警看半天其实十分钟之前就恢复了。这个问题的本质不是人懒而是“系统里根本没有一条主动推送的链路”。数据在服务端、在数据库里可它不会自己跑到浏览器上。我最初的想法是把这个需求砍掉因为排期紧而且“刷新页面”这种问题听起来太小儿科。后来有位同事跟我说他可以每天早晚上各打开一次页面但不可能一直盯着F5。这句话点醒了我我们需要的不是改一个页面而是建一条从后端到前端的实时数据通道。于是这个模块以最小化形式立项代号就随手定了rea全称后来勉强解释为“Real-time Edge Analytics”让它听起来正式一点。1.2 为什么一个“临时方案”值得写成复盘很多人觉得实时刷新这种功能无非就是轮询一下、几行代码的事。如果真这么简单rea上线后就不会有那么多幺蛾子。我在这个模块里踩过的坑大致分三类通信层的坑比如连接不稳定、消息乱序、断线重连后丢数据渲染层的坑比如大批量更新时页面掉帧数据层的坑比如多个数据源的时间戳对不齐导致前端画出来的曲线忽上忽下。每一类单看都不难但叠加在一起就成了一个标准问题看起来简单做起来琐碎。所以这篇文章不打算讲什么高大上的架构而是把这几个层面的真实记录摊开。如果你也在做类似的功能不管是大屏、监控面板还是一个小小的消息推送模块大概率会遇到其中某一类问题。我尽量把选型逻辑、故障现场和排查思路都写清楚当作一份可参照的记录。2. 实时数据方案选型比想象中纠结2.1 秒级刷新和毫秒级推送是两种需求动手前我先把需求拆了一下。有的页面只是展示CPU、内存这种变化不剧烈的指标三五秒刷一次完全够有的告警信息要求尽量实时几秒延迟都影响值班判断还有一些网络请求数这类边缘数据每秒可能变化几十条。这个分层直接决定了选型方向如果一开始就全量用重型方案开发成本和维护复杂度都会翻倍如果统一用短轮询又会对后端和数据库造成无谓压力。很多人第一反应是把轮询间隔缩短到一秒不就行了我差点也这么做。但仔细算了一笔账才发现如果改成1秒轮询在线用户只有几个人还好用户稍多一点一个普通查询接口的请求量就会成倍上升。更重要的是轮询间隔越短每次查询都要落到一个能被快速索引的路径上否则数据库压力还没到网络层先扛不住。所以轮询适合低频兜底不适合高频实时。我最后定的是两档普通指标走5秒一轮的查询关键告警走即时推送。这个策略本身很朴素真正麻烦的是“两套通道怎么共用一套数据格式”。哪怕推送是实时的、轮询是定时的最终展示层收到的都应该是同样的协议结构。这个问题不在设计阶段想清楚后面就是无穷无尽的格式转换代码。2.2 三种主流方案的对比账在动手之前我把团队里可选的三种主流路线拉出来算了一笔账短轮询、WebSocket、SSE。短轮询实现成本最低几行代码就能跑但实时性上限不高而且每次请求都有HTTP头开销在线用户一多网关和数据库压力就上来了。WebSocket是全双工通道实时性最好但状态维护、心跳、自动重连这些都要自己处理复杂度明显更高。SSE走普通HTTP服务端向客户端单向推送实现比WebSocket简单但对连接数和浏览器兼容性有一些限制。我把几个关键维度整理成表格。数据不是实验室基准是基于我们当时内部系统的实际观察只代表这个体量下的参考值。维度短轮询WebSocketSSE实现复杂度最低高中实时性秒级受间隔限制毫秒级秒级到毫秒级双向通信不支持靠反复请求支持不支持服务端单向连接开销每次请求都有HTTP头建立后长期保持建立后长期保持服务端资源占用请求量大时压力高需维护连接表每连接一个响应流断线恢复自然恢复需要自己处理有重连机制较友好WebSocket虽然实时性最强但对我们的场景来说有点“杀鸡用牛刀”尤其想到还要在中间加网关、处理消息确认和乱序维护成本就偏高。短轮询刚好相反便宜但不是实时最多算“定时刷新”。真正让我犹豫的反而是SSE它既有长连接的低延迟又没有WebSocket那么复杂的握手和心跳协议。2.3 rea最终选定的混合通道最终我选了“混合通道”而不是押注单一方案普通状态指标继续走5秒短轮询关键告警走SSE单向推送。核心理由有三条。第一告警数据的流向本来就是后端产生、前端展示几乎没有双向通信需求SSE正好匹配。第二SSE基于普通HTTP不需要额外打开端口或处理子协议在现有网关环境下改动最小。第三短轮询和SSE共用同一套传输层封装前端代码可以把两者都包成统一的“订阅式接口”调用方不关心数据来自通道A还是通道B。提示如果你们的场景需要前端向后端发送大量高频消息不要硬套SSE。SSE的单向模型适合看板、监控、通知流不适合聊天或协同编辑这类交互。说到混合通道还要解释一下为什么没有直接用消息队列之类的中间件。团队当时已经有可用的消息基础设施但rea只是一个内部监控模块引入消息中间件意味着多一套服务要维护还要处理消息积压、消费位点这些问题对这么小的需求来说性价比不高。直接在后端服务里维护一条线程安全的推送流配合并发队列就够了。这也算是“能用简单方案解决问题就不引入复杂依赖”的一个实例。这个选型过程看起来不复杂但它是整个rea里最关键的一步。后来很多问题比如连接抖动、数据重复、心跳超时都被我追溯到这个决策上。选型不是选最先进的而是选一个后续所有故障都能被合理解释的方案。rea选择的是“简单但不完美”的路径这让我在后期排障时思路非常清晰。3. rea的通信骨架与渲染链路三个关键设计决策3.1 数据包设计原子序号和时间戳必须分开rea要处理的告警数据本质上是一串结构化事件每条都包含事件类型、级别、时间、文本描述和关联指标。第一版设计时我犯过一个错误用时间戳做排序和去重。结果有一次某条指标在100毫秒内连续触发两次两次上报的时间戳完全相同前端当成重复数据丢掉了一条告警被漏了。排查了大半天最终发现不是后端漏发而是前端“自作聪明”去重了。修复很简单每条消息加一个服务端生成的原子序号配合时间戳一起使用。前端在渲染前按序号递增排序相同序号只取第一个时间戳只用于展示不参与去重。这个改动很小但对准确性影响很大。如果你也在做类似事件流提前把“消息ID”和“时间戳”当两件事设计能少踩很多坑。数据包的结构我大概这样设计的{ seq: 1024, ts: 1690000000000, type: alert, level: warning, content: disk usage above 90%, metric: { name: disk_usage, value: 91.2 } }seq就是原子序号全局递增ts是事件发生时间。接收端只依赖seq做连续性检测和去重ts只影响展示层的时间轴排序。这两者一旦混用早晚会出事。3.2 渲染层批处理与虚拟滚动的取舍然后是前端怎么处理高频变化。如果每秒钟推送几十条告警更新直接操作DOM很快会卡顿。我一开始用列表拼接方式但真正的瓶颈不是DOM操作本身而是频繁的布局重绘。批处理是有效的一招把同一时间窗口内的多条更新合并成一次渲染也就是“攒一批、画一次”。配合requestAnimationFrame实现基本能满足当前体量的页面。另外还做了一个很小的优化虚拟滚动。面板只渲染可视区域内的行超出部分用占位符补足。对短列表不一定有优势但rea里有一类表格随着运行会增长到几千行没有虚拟滚动的话内存占用会明显上涨。这类听起来像营销词的技术在真实场景里确实能解决问题。实现批处理的核心代码很简单核心思路是维护一个待渲染队列并在动画帧回调里统一清空const queue []; let scheduled false; function enqueue(card) { queue.push(card); if (!scheduled) { scheduled true; requestAnimationFrame(flush); } } function flush() { const batch queue.splice(0, queue.length); // 根据 seq 排序后更新列表 batch.sort((a, b) a.seq - b.seq); renderRows(batch); scheduled false; }核心不是这段代码本身而是“队列动画帧”这个模式它把高频输入转换成了可预测的渲染节奏也顺便解决了乱序问题。服务端推送其实比很多人想得简单。在标准Web应用里我们可以打开一个响应流把后续内容以特定格式写出去// Servlet示例简化处理 resp.setContentType(text/event-stream); resp.setCharacterEncoding(UTF-8); PrintWriter out resp.getWriter(); while (running) { DataPacket pkt queue.poll(5, TimeUnit.SECONDS); if (pkt ! null) { out.write(data: jsonOf(pkt) \n\n); out.flush(); } else { out.write(: heartbeat\n\n); out.flush(); } }这段伪代码展示了SSE最朴素的实现方式一个阻塞队列、一个响应流、一条心跳注释行。生产环境当然需要更多考虑但核心骨架就是这样。3.3 连接可靠性心跳检测与本地缓存兜底SSE的坑在于浏览器断网后不会立刻通知你连接可能处于“假死”状态。rea上线前我特意测过拔掉网线再插回来页面在很长一段时间里没有任何反应。这里不能指望浏览器自动重连必须自己做心跳检测前端每隔一段时间发一次存活探测如果连续几次没有收到后端响应就主动重建连接。心跳代码也可以简化成下面这种结构关键在于状态机的转换let missCount 0; const MAX_MISS 3; setInterval(() { fetch(/rea/heartbeat) .then(res { if (res.ok) { missCount 0; } else { missCount 1; } }) .catch(() { missCount 1; }); if (missCount MAX_MISS) { reconnect(); } }, 10000);为了减少重连带来的闪烁我又加了一层本地缓存断线期间收到的历史数据先落地到内存连接恢复后再补齐展示。严格来说这不算标准做法但对于内部工具来说体验提升明显至少值班同事不用手动刷新了。4. 上线第一周踩到的实时链路故障完整排查复盘4.1 从日志时间线还原故障现场rea上线第一周某天下午突然收到反馈某一台业务机的告警列表不更新了。从外部看像是连接断了但诡异的是其他页面都正常只有那一张表无响应。我最初怀疑是SSE连接超时重新打开页面后确实恢复了但没过多久又复现。我没有直接改代码而是先把前后端日志按时间线对齐逐步还原链路。当时的日志分散在前端浏览器控制台、后端服务日志和负载均衡访问日志三个地方我花了大概二十分钟才把三段日志拉齐到同一时间轴。结果发现问题不是连接断了而是后端在推送一条消息的时候抛了一个格式异常导致该连接后续的响应流中断。简单说整条通道被一条脏数据“噎住”了。拉齐日志之后看到的现场大概是这样的简化为示意前端12:00:03 收到 seq152页面正常渲染 前端12:00:04 连接状态变为 CONNECTING 后端12:00:04 消息 seq153 序列化异常跳过推送 后端12:00:04 日志显示当前连接已关闭 负载均衡12:00:05 检测到客户端重连 前端12:00:06 重连成功开始接收 seq154这里seq153成了永久缺口。前端没有意识到自己丢了数据因为页面继续渲染了seq154看起来一切正常。这个日志示例很典型建议你也画一遍自己的时间线再下结论。4.2 脏数据卡死连接与重连丢数据的双重问题我把这次故障拆成两个独立问题。第一个是脏数据卡死连接。后端推送逻辑没有做单条消息的异常隔离一条解析失败的消息会顺着连接影响整批推送。这个问题在很多长连接系统里都存在本质是“通道级可靠性”和“消息级可靠性”没有分开。第二个是重连丢数据。重连动作本身没有错但重连后服务端是从当前游标继续推送而不是从客户端缺失的位置补发。客户端如果没有记录“最后成功收到的序号”就不知道自己丢了哪些数据。我一开始以为这个问题很小但实测发现一旦发生重连数据缺口几乎必然出现只是多少的问题。修复分两步。后端方面单条消息改为独立序列化并增加完整性校验如果某条消息解析失败只记录错误并跳过不再中断连接。前端方面为每条连接增加一个对接游标重连时带着上一次成功消息的序号去请求补发窗口服务端把缺失部分补回来。4.3 修复方案、验证结果与排查经验改完之后我做了连续三天的稳定性验证包括人为断网、杀掉中间负载均衡进程、让后端服务重启等场景。验证结果显示告警列表的漏报率从体感上的时不时丢数据降到很少再出现断线重连的平均恢复时间也明显缩短。这个结果不算惊艳但对于内部监控工具来说已经足够稳定。更重要的是我们搞懂了问题根因而不是靠重启解决问题。这次排查给我留下的经验有三条。第一遇到反常问题不要直接动代码先梳理日志时间线最容易出问题的往往是消息格式和连接生命周期而不是业务逻辑。第二检查数据流完整性不能只看页面有没有新数据还要看序号是否连续缺口往往藏在“看起来正常”的背后。第三重连代码一定要配合游标使用否则连接恢复了数据还是断层的。如果你也在维护类似的长连接系统建议把这三条当默认动作日志时间线对齐、消息序号连续性检测、重连游标对接。这三个习惯能帮你少走很多弯路。5. rea运行稳定后我才补的维护功课5.1 可观测性日志分级与关键埋点rea稳定运行后我开始给它做维护性改造。第一件事就是日志分级和埋点。以前的日志要么全打出来要么全不打故障时根本没法定位。后来我按级别划分链路层日志记录连接建立、心跳、重连、断线消息层日志记录每条推送的序号、时间和是否补发业务层日志才记录告警内容本身。这样排查故障时基本能在一屏日志里看清连接状态和数据流状态而不是在海量文本里翻。埋点也补上了几个关键指标连接存活率、重连次数、单条消息推送耗时、前端首帧渲染时间。这些指标不要求多但每个都对应一类常见故障。比如连接存活率如果连续下降基本可以判断是网络或负载均衡问题单条消息推送耗时突然升高则要怀疑后端序列化逻辑。5.2 交接文档从代码注释到故障笔记做完rea大概两周后我被安排去处理另一个模块团队里另一个同事接手了rea。交接时最头疼的是文档。代码里写了很多细节但没有一份从故障到恢复的记录。后来我花了两天补了一份运维笔记内容包括三类常见故障的表现、对应的排查根因、修复操作步骤并把笔记挂在rea专属的交接文档里在代码注释中加了对应说明。这件事给我的启发是内部工具的价值不仅在于功能实现更在于后来者能不能快速接手。一个无人能维护的工具再漂亮也没有意义。5.3 后续扩展多端同步与离线缓冲rea目前满足的是单页面实时展示但实际使用中已经暴露了扩展需求。比如值班同事希望在手机端也能看到关键告警这就涉及多端同步再比如弱网环境下前端希望把数据缓冲到本地等网络恢复后再统一补齐展示。这些方向目前都还在规划中。设想的多端同步其实可以是“SSE长连接短轮询兜底”的组合手机端优先通过一个实时通道接收关键告警但每隔几分钟做一次全量状态对账对账时以服务端游标为准修正各端数据。对账的过程本质上就是一次全量快照比较虽然听上去不够“实时”但对内部工具的可用性来说往往更稳。离线缓冲则需要在前端引入简单的本地存储方案并和后端补发窗口对接好。这些扩展都不算难但每一步都需要回到rea最初的数据包设计上重新审视。当初随手加的原子序号到这些场景就成了最重要的基石。所以设计阶段多花一点时间把基础字段定义清楚后面能省下的维护成本是很大的。最后再说一个我在rea里体会最深的小技巧时间戳和序号一定要分开设计。很多实时系统初期把时间戳当唯一标识用看起来没什么问题一旦出现毫秒级密集事件或者多数据源并发乱序、重复、丢数据就全都来了。我在rea里吃过这个亏后来项目里再遇到实时场景第一句话都是问“数据包的顺序保证在哪个层面”。这个问题想清楚了后面的一半麻烦都不会出现。