REA 这个代号，最近在我内部项目中落地成了一款实时资产分析小工具（Real-time Asset Analyzer）。你别急着跟其他同名开源项目对号入座，这个“rea”其实就是我给一个服务监控看板起的内部代号。起因很简单：那段时间团队每天都在人肉盯服务状态、翻日志文件、手工汇总表格，出了异常经常是业务同学先发现，我们再反过来追数据，效率实在太低。所以我就用两周多时间搭了一个能实时看到核心指标、历史趋势和异常告警的页面，顺手把整个链路里踩过的坑、做过的取舍也记录下来。这篇文章适合正在做内部工具、监控看板、实时数据可视化相关开发的朋友，无论你是前端、后端还是全栈，应该都能找到点能直接抄走的思路。
- 整体设计与思路拆解
1.1 为什么是实时的资产分析，而不是定时统计报表
最早拿到这个需求时，我第一反应是“这不就是搞个定时任务，半小时拉一次数据出报表吗”。但真去梳理业务场景后，发现完全不是这么回事。团队关心的不是“昨天均值是多少”，而是“当前这分钟线上指标是否正常”，以及“过去30分钟是否有异常波动”。定时报表只能告诉你“已经发生了什么”，很难支撑“正在发生什么”的快速判断。
所以“rea”选定了实时推送方案。服务端收集各类指标后，通过长连接主动推给前端，前端再更新图表和卡片。这个模式下，从数据产生到页面变化，延迟能控制在1秒以内，盯着大屏的同事基本能做到异常刚出现就反应。另一方面，实时数据仍然会做本地缓存和日志回放，查询历史时不需要重新拉全量数据，直接用缓存计算结果就行。
这个设计说白了就是“实时看当前 + 缓存看历史”的双轨思路。历史部分不追求秒级精确，但至少要保证分钟级可追溯；当前部分则优先保证低延迟和高频刷新。把两者分开设计，既避免把所有逻辑绑在一套管道里，又能各取所长。
1.2 技术选型：为什么是 WebSocket 而不是轮询
有个老生常谈的问题：实时更新到底用轮询还是长连接？我用脚趾头想都知道很多人会选每2秒发一次 Ajax 请求，实现简单，后端也省事。但如果页面里同时挂了十来个指标卡，每个都setInterval去拉数据，后端接口QPS会瞬间涨到很难看，而且数据很难对齐到统一的时间轴。
最终我选了 WebSocket 作为主要推送通道。理由很直接：服务端可以主动广播数据，所有在线页面共享同一条数据流；前端不用反复建立连接，也能大大降低网络开销。具体到这项目里，服务端只维护一个全局的指标缓存，每秒钟更新一次，然后把变化的数据推送给所有连接上的浏览器。前端只需要处理“连接、断线、重连、解析消息”这四件事。
那什么时候不该用 WebSocket 呢？如果只是低频查询，比如每天看一两次报表，完全没必要上长连接。实时推送会显著增加服务器状态管理的复杂度，而且调试起来也比纯 HTTP 请求麻烦。为了实时而实时，最后只会给自己挖坑。
1.3 技术栈里的几块拼图：Vite、React、Zustand、ECharts
rea 的界面层没有用什么重型框架，就是最常见的 Vite + React + TypeScript 组合。Vite 负责本地开发和打包，React 负责组件渲染，TypeScript 给数据加上类型约束。这套组合现在基本是前端工具的默认答案，没有太多需要纠结的地方。
比较值得说的是状态管理。我没用 Redux，而是选了 Zustand。原因很简单：rea 对全局状态的需求是“轻量、高频、多模块共享”，Redux 那套样板代码写起来费劲，读起来也更绕。Zustand 几乎零配置，能在组件外部直接操作 store，配合useShallow做选择性订阅，可以精准控制哪些组件需要重新渲染，这对高频更新的监控页面特别重要。
图表部分用了 ECharts。虽然它体积不小，但开箱即用的折线图、面积图、仪表盘，以及相对稳定的性能表现，在内部工具里省了我大量造轮子的时间。后面我会拆到主题时细讲 ECharts 在大数据量下的更新策略，这里先记住一点：图表实例不能无脑setOption，必须把高频更新的“流式数据”和低频更新的“配置项”分开处理。
1.4 架构边界：前端、后端服务、数据来源怎么切分
rea 的物理部署很朴素：前端是静态资源，部署在 Nginx 上；后端是 Node.js 写的一个轻量 WebSocket 服务，部署在同一台服务器上；数据来源则是各个被监控服务主动上报的指标。
我特意把“上报-汇聚-推送-展示”切成四段：
- 上报：被监控服务每隔10秒，往 rea 后端提交一份指标数据，格式是 JSON。
- 汇聚：后端把收到的数据按服务名和指标名聚合，维护在内存中。
- 推送：后端定时把聚合后的快照（每秒一次）广播给所有前端页面。
- 展示：前端解析消息，更新状态，渲染图表。
这样切分最大的好处是可替换性强。某天如果不想用 Node.js 做汇聚层，直接换成一个 Java 或 Go 服务，只要消息协议不变，前端完全不用动。反过来，如果前端要从 ECharts 换成别的图表库，后端也不感知。
- 核心模块拆解与实现细节
2.1 实时数据管道设计：从上报到渲染的完整链路
我先画一条完整的数据流（这里不画图，直接文字描述）：被监控服务发起 HTTP POST，把{ service, metrics: { cpu, memory, qps } }和timestamp发送到 rea 后端的/ingest接口；后端校验完字段后，把它写入一个环形缓冲队列；然后由后台任务每秒消费队列，合并出当前快照，并广播给所有 WebSocket 客户端；前端收到消息后，把数据追加到对应图表的数据缓冲区，同时触发卡片数值更新。
这个管道看起来简单，真正决定体验的是两个细节：一是队列消费的速度必须跟上生产速度，否则内存会越积越多；二是前端缓冲区的长度必须有限，我直接限制了每张图表最多保存最近300个点，超过就丢弃旧数据。否则页面开一整天，几万点全塞进内存，再好的浏览器也会变卡。
2.2 状态管理：Zustand 为什么够用，怎么防止全局更新引发无用渲染
监控页面的特点就是“状态变化频繁且分散”。如果所有页面都订阅同一个全局对象，任何一个指标刷新都可能触发全部组件重绘，这种渲染风暴会直接把浏览器拖死。
我用 Zustand 做了三层划分：
useMetricsStore：保存最新的实时指标快照，后续的所有指标卡都从这里读取。useChartDataStore：按图表维度保存各自的时间序列数组，图表组件只订阅自己需要的那段数据。useUiStore：负责主题、筛选条件、折叠面板等纯 UI 状态，跟业务数据完全解耦。
关键技巧在于，组件里不能直接调用useStore()获取整个 store，而是要用选择器做定向获取。比如某个卡片只需要metrics['web-server']['cpu']，那它就只订阅这个值。Zustand 内部对选择器做了比较，只有选出来的值发生变化，组件才会重渲染。我实测下来，四十多个图表同时在刷，CPU 占用也能一直压在低水平，这个优化功不可没。
2.3 可视化组件的取舍：指标卡、趋势图、热力图怎么搭配
rea 页面主要由三部分组成：顶部一排关键指标卡片，中间是几组时间序列折线图，底部是一张按服务维度展示的在线状态热力表。
指标卡只展示“当前值 + 偏差百分比”，不需要动画，也不需要迷你趋势图。因为卡片刷新的频率高，任何一点动画都会造成视觉噪点，反而干扰判断。趋势图用来观察近30分钟内的变化，ECharts 的areaStyle做渐变面积图效果就很直观。热力表按每分钟一个格子、每个服务一行，颜色根据异常程度变化，用来快速定位“哪个服务在哪个时间段出了问题”。
不要把所有数据都堆在同一个页面上。内部工具最容易犯的错就是大而全，用户打开后反而不知道先看哪里。rea 的首页只放最重要的30秒概览，详细数据的下钻页面单独做，避免视觉过载。
2.4 告警模块：轻量规则引擎怎么实现
告警是监控工具的核心价值，我只做了最朴素的版本：每个服务可以配置若干条规则，比如“CPU连续3分钟超过85%”或“QPS为0超过2分钟”。后端每消费完一次快照，就通过一份规则配置生成触发结果，命中后把告警事件推到前端置顶展示，同时写一份本地日志。
规则引擎的难点不在判断逻辑，而在怎么避免重复告警和误报。朴素实现很容易让人收到烦不胜烦的消息。rea 的应对方式是引入“冷却期”：同一个规则触发后，至少10分钟内不再重复推送。同时，规则里我把“持续N个周期”的校验前置，连续多次确认异常才真正上报，这样能滤掉瞬时抖动带来的假告警。
- 实操过程与关键配置
3.1 项目初始化与目录结构
rea 的源码结构我按功能分包，而不是按页面分包，方便后面扩展新数据源：
rea/ ├── client/ # 前端工程 │ ├── src/ │ │ ├── components/ # 卡片、图表、表格等组件 │ │ ├── hooks/ # useWebSocket、useInterval 等 │ │ ├── stores/ # zustand store 定义 │ │ ├── types/ # 前后端共享的 TS 类型定义 │ │ └── pages/ # 页面级入口 │ └── package.json └── server/ # Node.js WebSocket 服务 ├── src/ │ ├── ingest/ # 接收上报数据 │ ├── stream/ # 快照广播 │ ├── rules/ # 告警规则 │ └── index.ts # 入口 └── package.json前后端并不完全独立，我专门写了一组types/index.ts，同时被 client 和 server 引用。这样前后端定义数据结构时只要一处改动，另一处立刻在编译期报错，省掉了很多联调时才发现的字段命名不一致问题。
初始化命令没什么特别的，前端是npm create vite@latest client -- --template react-ts，后端则直接手动建了一个 Node.js 工程。这里我特意没有用 monorepo 工具，因为项目的复杂度还远没到需要那些编排工具的阶段，简单两个package.json足够清爽。
3.2 WebSocket 服务端与前端连接
服务端我用 Node.js 原生环境搭配ws库，没有上更重的 Socket.IO。原因是 rea 只需要最基本的广播能力，Socket.IO 的自动重连、事件重放确实好用，但保持依赖链更短对后续维护更友好，权衡之后选了ws。
服务端核心逻辑是维护一个客户端集合，然后每秒广播快照：
// server/src/stream/index.ts import { WebSocketServer } from 'ws'; const wss = new WebSocketServer({ port: 8081 }); const clients = new Set<WebSocket>(); wss.on('connection', (ws) => { clients.add(ws); ws.on('close', () => clients.delete(ws)); }); export function broadcast(snapshot: unknown) { const message = JSON.stringify(snapshot); clients.forEach((ws) => { if (ws.readyState === ws.OPEN) { ws.send(message); } }); }前端我封装了一个useWebSockethook，职责是创建连接、监听消息、更新 store，并在断开后指数退避重连：
// client/src/hooks/useWebSocket.ts import { useEffect } from 'react'; import { useMetricsStore } from '../stores/metricsStore'; export function useWebSocket(url: string) { useEffect(() => { let ws: WebSocket; let reconnectAttempt = 0; let timer: number; const connect = () => { ws = new WebSocket(url); ws.onmessage = (event) => { const snapshot = JSON.parse(event.data); useMetricsStore.getState().applySnapshot(snapshot); }; ws.onclose = () => { const delay = Math.min(1000 * 2 ** reconnectAttempt, 30000); reconnectAttempt += 1; timer = window.setTimeout(connect, delay); }; ws.onopen = () => { reconnectAttempt = 0; }; }; connect(); return () => { clearTimeout(timer); ws?.close(); }; }, [url]); }这里值得多说一句：重连延迟用指数退避，是为了避免服务端重启瞬间大量客户端同时重连造成抖动。首次失败等2秒，第二次4秒，第三次8秒，最多封顶30秒，实测下来比固定间隔稳定太多。
3.3 图表组件与高频数据更新的正确姿势
直接用 ECharts 的 React 封装组件，最忌讳的是每次数据更新都重新创建实例。正确做法是用一个容器 div 在useEffect里初始化一次实例，然后通过setOption增量更新数据。
度量的关键点在setOption的配置。rea 里的趋势图，我使用下面的方式来更新：
// client/src/components/TrendChart.tsx import * as echarts from 'echarts'; import { useEffect, useRef } from 'react'; export function TrendChart({ data }: { data: Array<[number, number]> }) { const containerRef = useRef<HTMLDivElement>(null); const chartRef = useRef<echarts.ECharts | null>(null); useEffect(() => { if (!containerRef.current) return; const chart = echarts.init(containerRef.current); chartRef.current = chart; return () => { chart.dispose(); }; }, []); useEffect(() => { chartRef.current?.setOption({ series: [{ data }], }); }, [data]); return <div ref={containerRef} className="h-64 w-full" />; }很多教程喜欢用setOption(option, true)，意思是“整体替换配置”。但在高频更新场景下，第二个参数最好不用。设为 true 会销毁旧图形重新渲染，开销很大；不传这个参数，ECharts 会做增量合并，性能和流畅度都能保住。
3.4 打包部署与内存释放排查
rea 的部署流程比较常规：前端执行npm run build，产物丢到 Nginx 的静态目录；后端用进程管理器启动，然后把 8081 端口通过 Nginx 反代到 80 端口，这样前端页面可以走同一个域名，免去跨域配置。
具体 Nginx 配置片段：
server { listen 80; server_name rea.example.internal; location / { root /var/www/rea; index index.html; } location /ws { proxy_pass http://127.0.0.1:8081; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "Upgrade"; } }这个配置里有几个容易被忽略的点：proxy_read_timeout默认60秒，WebSocket 长连接需要显式设置成更长，比如proxy_read_timeout 3600s。另外静态资源的缓存策略要区分文件类型，HTML 文件不缓存，带 hash 的 JS/CSS 可以长期缓存，避免页面升级后用户还拿着旧脚本。
后端内存释放这块，我操作中踩过一次坑：环形缓冲队列只设计了长度上限，但没有处理快照对象里的对象引用，导致某些指标卡不断累积引用。后来专门写了一个deepCleanSnapshot函数，每次广播前只保留当前快照需要的基本类型字段，彻底断掉历史引用链。
- 常见问题与排查技巧实录
4.1 WebSocket 反复断连，重连风暴怎么定位
排第一的问题肯定是连接不稳定。现象是页面上所有卡片偶尔集体静止，稍后又恢复，团队反馈“页面总是一卡一卡的”。
排查顺序我是这么走的：
- 先打开浏览器开发者工具，切到 Network 面板，看 WebSocket 帧的发送间隔是否正常。
- 如果帧间隔期间有明显空白，直接看 Nginx 错误日志，确认是否有 “upstream timed out”。
- 检查
proxy_read_timeout配置，我之前没设置，默认60秒导致空闲连接被剪断。
这个问题最终确认就是 Nginx 超时把连接掐了。因为平时每秒钟都有数据推送，不太会触发空闲超时，但一旦某一两秒没有新数据，服务端没有发送心跳包，连接就断了。
解决方案很简单，除了调大 timeout，我还让后端每30秒主动发一个空 ping 帧，维持链路的活性。前端收到 ping 后不做任何数据更新，只是重置一下断线计时器。
4.2 图表越跑越卡，内存增长逼近浏览器上限
页面开一整天，初始还挺流畅，半天后开始严重掉帧，最后浏览器无响应。这种问题十有八九是数据点无限堆积。ECharts 内部会保留所有传给 series 的 data，如果你一直往数组尾部 push，它就一直往内存里塞。
我处理的办法是前端统一维护一个MAX_POINTS = 300的常量，每次收到新数据先检查数组长度，超过就把头部最旧的10个一并裁剪。配合 ECharts 的增量 merge，渲染的数据量是恒定的，页面跑一星期也不会因为数据点增长而变卡。
另外要注意 ECharts 实例的销毁。页面里如果存在路由切换或动态渲染，务必在组件卸载时调用chart.dispose()，不然图表实例会残留在浏览器内存里，造成内存泄漏。
4.3 多个指标同时刷新，页面渲染跟不上
Zustand 选择器已经帮了大忙，但某些场景下仍然会有并发更新导致的撕裂感。比如切换筛选条件时，store 里三十多个指标同时被更新，图表全部重绘，掉帧问题就回来了。
解决方法是把“筛选条件变化”和“实时数据变化”分开处理。筛选条件变化时，我可以先暂停图表更新，渲染一次空数据占位，再立即用新条件过滤后的缓存数据整体重绘。实时数据变化则走增量通道，每次只触发一小部分组件。
实操落的代码体现为一个简单的计数开关：
// client/src/stores/metricsStore.ts let paused = false; export function pauseUpdates() { paused = true; } export function resumeUpdates() { paused = false; } useWebSocketMessage((snapshot) => { if (!paused) { useMetricsStore.getState().applySnapshot(snapshot); } });批量筛选的场景毕竟低频，这样暂停一两秒对实时性几乎没影响，但切换效果顺滑了很多。
4.4 告警时效性差：规则触发延迟怎么收缩
默认我写的是每消费完一轮快照立即跑规则，本来以为足够及时。但后来发现数据上报间隔是10秒，快照广播间隔是1秒，也就是说一条规则最坏情况下要等10秒才开始计数，还要连续满足多个周期才算告警，整体延迟可能快到一分钟。
对于需要快速感知异常的场景，这个延迟有点高。我调整了数据上报路径，把告警判断拆成两级：第一级是“快速告警”，在后端收到上报时就做一次轻量判断，命中则立刻广播；第二级是“持续确认”，仍然按快照周期做连续检测，用来剔除瞬时尖峰。这样两条路径配合，既保留了准确率，又把最长延迟压缩到了上报周期 + 一次确认周期左右。
- 项目做完后的几点体会
5.1 这类项目最适合扩展成什么
rea 做完基础版之后，我很快发现它其实可以不止是内部监控。由于数据管道是通用的，我把“被监控服务上报”替换成任何类型的业务事件，前端从展示指标变成展示事件流，它就能变成一个轻量级的活动分析工具。比如团队里有同事想统计不同渠道的操作转化路径，把我这套 WebSocket 推送和缓存机制改一改，再加几个漏斗组件，马上就能用。
另外，告警规则引擎目前是 JSON 配置，但规则之间没有依赖关系。如果再迭代，我会把规则改成“脚本化”的，允许用户在某个规则命中后触发另一个规则，这样就能模拟出更贴近真实运维场景的告警联动。
5.2 如果再让我做一遍，我会改什么
如果要重来，我第一件事是把毫秒级时间戳统一到 UTC 存储，而不是用各服务本地时间。现在 rea 的数据上报时间由各服务自行生成，服务如果存在时钟偏移，趋势图上的时间轴就会出现锯齿。统一在汇聚层校准时间后，历史数据回放会干净得多。
其次，我会在项目初期就引入简单的组件测试。rea 的前端大部分代码是数据转换逻辑，本来非常容易做单元测试，但我为赶进度跳过了，后面重构时只能靠肉眼对比数据，效率很低。哪怕只是给工具函数补几个测试，后期的维护成本也会明显下降。
最后，ECharts 包体积还是偏大，如果之后对首屏加载速度有更高要求，我会考虑按需引入，只打包折线图、面积图和热力图相关模块，减小至少一半的图体积。对内部工具虽然没那么敏感，但能省一点是一点。
这项目最让我满意的不是用了多新的技术，而是它真的有在改变团队的日常工作流。以前每天下午要花半小时去做数据巡检，现在打开 rea 看一眼就行，有异常也会直接冒出来。我做这类小工具的经验是：先把链路走通，再追求细节的极致，实时类项目尤其如此——先要保证“不丢数据、不卡页面、不误报”，再慢慢去调粒度、换方案、做联动。把这三点稳住，工具就已经成功了一大半。
