先交代一下背景。全栈自造Status Deck二这篇核心就是技术栈选型与项目实施。上一篇文章里我讲了为什么要做Status Deck以及它要解决什么问题后台收到的私信里问得最多的就是一个状态面板而已真有必要把Vue、Golang、Uniapp、AI全都串起来这篇文章我把选型过程和落地路径摊开讲包括为什么没选React和Node为什么第一版不上数据库从空仓库到MVP跑通经历了哪些环节。如果你也在做聚合面板、个人仪表盘或者正打算从纯前端往前端全栈迈一步这篇应该能帮你省掉不少调研时间。1. 项目定位与需求拆解Status Deck到底在做什么1.1 一个面板的价值信息聚合与异常告警的入口先打个比方。做独立开发或者团队里负责技术的人每天早上开工前往往要做同一件事打开好几个网页或者终端窗口看一眼服务器负载、CI构建过没过、线上错误数有没有飙升、有没有新用户反馈。这些信息散落在不同平台每切换一次页面都是在消耗注意力。Status Deck就是要把这一堆“状态”聚合到一个统一界面里让“到处找信息”变成“一直盯一个面板”。我给自己定义的项目目标非常具体汇总自建服务、第三方API的实时存活状态展示定时任务、数据采集任务的最近一次执行结果展示构建和发布流程的最新状态包括成功、失败、耗时支持异常状态主动推送到手机端不用时刻盯着屏幕同一套界面在Web、H5、小程序端都能以接近一致的方式访问。同时我明确列了第一版不做的事复杂权限系统、历史数据挖掘、花哨的大屏动效。为什么刻意砍掉这些因为MVP的核心是跑通一条完整的信息链路采集、存储、推送、展示。凡是跟这条链路无关的功能都属于“以后再说”的范畴。如果一开始就想着权限、多租户、自定义主题这个个人项目大概率活不过两个星期。1.2 需求拆解后的三组关键取舍动手之前我把需求压缩成了三个必须提前决策的点。第一主动拉取还是被动上报。Status Deck部署在我自己的服务器上可以主动去探测各个数据源接口这是最简单的模式。但移动端如果要上线小程序很多第三方接口有跨域或者鉴权限制就必须由后端做代理采集再统一输出给前端。我最后选的是“后端主动采集 前端被动订阅”的组合后端负责所有脏活累活。第二全量实时还是按需刷新。全部数据都走WebSocket全量推送资源开销大而且很多数据源本身变化频率很低。折中方案是前端按页面订阅后端定时聚合数据只在状态发生变化时才推送增量事件。第三单端优先还是多端同步。如果只做Web后面再接手机端接口层至少要预留鉴权和推送的扩展位。如果一开始就打算多端都上前端框架就必须考虑跨端复用。这两个方向没有对错但决定了后面技术选型的走向。这三组取舍基本锁定了技术方向。我最终选定的组合是Vue 3 TypeScript做Web端Golang做后端聚合与推送服务Uniapp做移动端壳采集层和数据说明层再接入AI能力。看起来是个“全家桶”但每一项都是被具体需求逼出来的不是拍脑袋堆技术。2. 技术栈选型这套组合背后的逻辑2.1 前端选择Vue 3核心是组合式API和数据流清晰Web端最终用了Vue 3 TypeScript Vite Pinia Vue RouterUI层没有引入重型组件库而是用Tailwind CSS自己搭卡片和仪表盘样式。为什么是Vue而不是React最关键的是组合式API很适合Status Deck这类“多数据源订阅”场景。面板页面上有服务状态、构建结果、告警列表每块卡片都要各自订阅不同的数据通道。如果用Vue 2选项式API订阅逻辑会分散在data、methods、mounted这些槽里组件一多就乱。用组合式API我可以把每个面板的订阅逻辑封装成独立的composable比如useServerStatus()、useBuildStatus()组件里只负责把响应式数据渲染出来。这种“逻辑聚合”的方式在个人项目里维护起来非常顺手。Pinia比Vuex轻很多全局只需要保存连接状态、面板配置、当前告警列表不需要复杂的状态派生。Vite的冷启动和热更新速度在开发体验上是真的快尤其适合一个人反复调UI的节奏。Tailwind CSS则把样式和组件放得更近改起来直接改class省去一堆CSS文件间的跳转。如果是React做也能做但在“个人开发、单页面板、组件逻辑复用”这三个维度上Vue的上手成本和中文生态对我更友好。技术选型不是比谁更高级而是比谁能让你用最少的维护成本到达目标。2.2 后端选择Golang理由集中在并发、部署和内存Status Deck后端要做的事不少定时拉取多个数据源、维持WebSocket长连接、对外提供REST接口、做数据聚合和告警判断。我选Golang而不是Node.js或Java三个原因特别明确。第一个是并发模型。Goroutine在处理“同时拉取十几个外部接口”这种场景下非常顺手用go func发请求、用channel收结果代码结构清晰比事件回调或者Promise链容易读得多。第二个是部署。Go编译出来就是一个二进制文件配一个配置文件就能跑。Status Deck最终要部署在一台低配服务器上我不想为了跑个人项目先去折腾JRE或者Node版本单个二进制的部署成本对个人开发者是巨大的时间红利。第三个是内存占用。实测下来包含定时任务、WebSocket服务、REST接口的后端空跑状态内存占用约24MB跑满50个数据源和30个并发连接也就80MB左右放在1核1G的云服务器上非常从容。框架层面我用了Gin路由和中间件生态成熟遇到问题搜得到资料。WebSocket用的gorilla/websocket属于Go社区的老牌方案文档和坑都清楚。数据存储第一版直接用内存Map加定时快照持久化没有上Redis和数据库。这个决策后面专门讲。下面是当时做的对比记录环节选型结果核心理由维护成本Web前端Vue 3 TS Vite组合式API复用逻辑方便、热更新快低后端服务Go Gin gorilla/websocket并发能力强、单文件部署、内存占用低低移动端Uniapp Vue 3一套代码发多端复用后端接口中第一版存储内存Map 快照文件零外部依赖重启可从快照恢复低AI能力OpenAI兼容协议API可配置切换本地模型独立部署中2.3 移动端引入Uniapp是效率和平台覆盖的平衡点早上出门坐地铁想看线上服务有没有异常总不能掏出电脑开终端。Web版做响应式也能凑合看但手机浏览器的通知能力太弱体验不完整。上原生App成本又太高Uniapp就成了很直接的中间方案。Uniapp的核心价值是用Vue语法写一套代码编译到iOS、Android、H5和各类小程序。它和Vue 3在跨端场景下已经比较成熟但要注意Uniapp并不是每个API都全端一致的。我的做法是把业务逻辑放在独立工具模块中平台差异用条件编译处理。比如消息订阅在小程序端调用uni.requestSubscribeMessage在App端调用uni.push在H5端则退化为站内横幅提示。这样能保证核心逻辑只写一遍平台差异控制在边界处。另外要记得Uniapp在小程序端的渲染性能受限面板页不要一次性渲染几百个组件最好用分块渲染或者虚拟列表。Status Deck的卡片数量我控制在三四十个以内实测在微信开发者工具和真机上都能流畅运行。如果要支持大规模监控就得对渲染做分层处理比如先渲染高频更新卡片低频卡片懒加载。2.4 AI不是装饰而是给状态面板加一层解释器现在的全栈项目不带点AI好像说不过去但我一直反对把AI硬塞进系统里。在Status Deck里我保留了两个真正有用的AI场景。第一个是异常摘要。当多个服务同时异常时原始错误信息通常是一堆时间戳和状态码人眼扫过去很难快速判断是哪条链路出了问题。后端把原始错误信息汇总后调用大模型API生成一段自然语言的异常归因摘要直接显示在面板顶部。第二个是运维问答。基于当前面板数据和最近一周的变更记录用户可以输入“为什么昨晚构建这么慢”AI结合时间线数据给出分析。这个功能有点像给面板加了一层对话入口但它依赖的数据仍然是后端已有的指标。技术实现上我坚决不让AI服务成为主链路的一部分。AI能力被拆成一个独立辅助服务通过内存消息队列与主后端解耦。这样AI接口挂了Status Deck的展示和告警功能依然正常。模型调用走的是OpenAI兼容协议提示词和模型参数都放在配置文件里方便以后替换成本地模型比如用Ollama跑一个量化版本这样在低配服务器上也能完成基础摘要任务。3. 项目实施从仓库初始化到MVP落地的完整流程3.1 Monorepo管理三端代码一次提交覆盖全链路这个项目一共三个代码端web、server、mobile外加配置文件、部署脚本和文档。如果用三个Git仓库管理光是跨仓库改动的同步就能把写代码的兴致耗光。我用了Monorepo方案根目录一个仓库下面几个子目录各自独立构建。最大的好处是一次提交可以直接跨越前后端和文档回滚版本时整个项目处于明确一致的状态。坏处是如果将来人多、模块多CI时间和权限粒度会成问题但对个人项目完全不是事。初始目录结构大概是这样的status-deck/ ├── server/ # Go后端 │ ├── cmd/api/main.go │ ├── internal/ │ │ ├── collector/ # 数据源采集 │ │ ├── hub/ # WebSocket连接管理 │ │ ├── engine/ # 告警判断引擎 │ │ └── config/ # 配置加载 │ └── go.mod ├── web/ # Vue 3前端 │ ├── src/ │ │ ├── composables/ # 面板订阅逻辑 │ │ ├── views/ │ │ └── api/ │ └── package.json ├── mobile/ # Uniapp项目 │ ├── src/ │ │ ├── pages/ │ │ └── utils/ │ └── manifest.json ├── docs/ └── deploy/这个结构在动手前就定了后面写代码基本没有推倒重来。3.2 接口契约先行前后端并行开发不打架联调是最容易出乱子的环节。我的做法是先定义一份接口契约文档前后端都照着它开发。后端用Swagger暴露接口定义前端用Mock数据先行开发页面两者互不等待。接口分三类REST接口负责Web端和移动端首次加载数据包括获取面板总览、指标详情、告警列表。WebSocket接口负责实时推送指标变化、告警事件、任务执行状态。管理接口负责动态增删数据源、调整轮询频率和告警阈值开发阶段先不做UI直接用curl和Postman测试。典型接口约定长这样{ code: 0, message: ok, data: { panels: [ { id: server-health, name: 自建服务器健康状态, status: ok, metric: { cpu: 32, mem: 45 } } ] } }所有接口响应统一为code、message、data结构分页参数统一用page和page_size错误码用业务码而不是裸HTTP状态码。这些看似琐碎的约定让前后端联调的时间压缩得非常短。3.3 MVP实现路径四步走跑通数据链路MVP阶段我给自己设定了四步走每一步都有明确的验收标准。第一步后端先写采集器和内存存储。配置三个真实数据源自己服务器的健康检查接口、CI平台API、第三方服务状态页面。定时拉取数据存入内存Map。第二步前端做最简面板通过REST接口拿到数据渲染卡片列表每10秒轮询一次。这一步刻意不用WebSocket先把端到端数据流动跑通过程中如果接口有bug日志能直接定位。第三步接入WebSocket。后端把变更事件推给前端前端按增量事件更新对应卡片不再整页刷新。第四步接入Uniapp移动端复用同一套后端接口重点验证消息订阅和通知推送。这里有一个关键经验不要跳过第二步直接上WebSocket。轮询实现简单方便定位接口问题而且它天然就是一个兜底方案。等轮询链路稳定再上WebSocket做增量推送前后端都有日志可以对照问题定位效率高很多。3.4 后端采集调度设计既要并发又要防堆叠采集调度是Status Deck最容易写土也最容易出问题的地方。我的调度逻辑是用一个全局Ticker定时触发每个数据源绑定独立采集器采集任务丢进Worker池并发执行结果汇总到内存缓存。伪代码就不贴了直接说几个关键点。每个采集器必须设置超时时间我的默认值是5000毫秒超时视为异常。连续失败超过3次把该数据源标记为告警并推送前端从失败恢复成功后再推送一次恢复事件。这里有一个容易踩的坑如果某个数据源响应特别慢而采集器是串行执行的后面的数据源会被拖累。所以必须给每个数据源配置独立的并发控制不能让一个慢接口拖住整个调度器。调度频率我也做了差异化健康检查接口30秒一次CI平台状态5分钟一次第三方外部服务1分钟一次。频次差异背后是成本和实时性的权衡。把不重要的数据源调高频率只会白白增加上游压力和日志噪音。3.5 WebSocket前后端实现快照加增量更新后端WebSocket连接管理我用了一个经典的Hub模型。Hub负责注册连接、注销连接、广播消息。每个前端连接进来后服务端先发送一次全量状态快照之后只发送增量事件。消息格式统一为JSON区分type{type: snapshot, data: { ... }} {type: update, data: {id: server-health, status: warn}}前端Vue侧我封装了一个usePanelSocket composable组件挂载时调用connect卸载时调用close。断线重连采用指数退避第一次重连延迟2秒第二次4秒第三次8秒最多到30秒封顶。每次重连前先清理旧连接避免重复订阅。有一个小坑必须提醒WebSocket的URL不能写死。开发环境连本地生产环境连服务器切换逻辑统一放进了Vite的环境变量文件。否则本地调试连不上服务器部署后又连不上本地。3.6 移动端与AI辅助模块的落地细节移动端复用了同一套后端接口页面结构比Web端简化很多。我只在小程序端展示三类核心卡片服务状态、构建状态、待办告警不做复杂图表。小程序包体积和渲染性能都有限堆大图表会让开发者工具和真机表现差距变大。实际遇到的坑是小程序切换页面返回时WebSocket连接会被自动断开。我的处理是在onHide里主动关闭连接在onShow里重新建立新连接。这样比等系统回收连接要稳定得多。AI辅助模块实现得比较独立是一个单独的服务监听消息队列里的“异常事件”和“用户提问”。第一版没有引入Kafka这类重型组件直接用Go的channel做内存队列。AI处理超时或者不可用时系统自动退化为原始错误信息展示。这个设计保证了AI只是增强能力而不是单点故障。4. 常见问题与排查技巧实录4.1 定时任务堆叠一个慢数据源拖垮整个调度器真实发生过的事故某个第三方数据源升级后响应时间从200ms暴涨到10秒而调度间隔是1分钟。由于采集器串行执行这个10秒的缓慢请求阻塞了后续所有采集最终多个数据源同时超时面板上一片红色告警。排查方式是在日志里发现了“前一轮采集尚未结束跳过本轮”的提示才意识到任务堆叠了。解决方案分两层第一层给每个数据源独立Goroutine隔离单个数据源再慢也只影响自己第二层加单飞语义如果上一轮还没执行完直接丢弃新一轮采集请求并记录skip日志。不要无脑堆积任务堆积带来的不是更实时的数据而是更混乱的现场。4.2 WebSocket断线重连风暴前端同时开着多个页面网络抖动后会产生大量断线重连请求一瞬间把后端连接数打满。根本原因是重连策略缺少退避和全局限流。我的解决方法是两板斧前端指数退避加随机抖动重连间隔在2秒基础上增加随机1到3秒避免多个客户端同时发起重连后端限制同一客户端标识的重复连接数超过阈值直接关闭旧连接或拒绝新连接。另一个关键点是心跳机制。给每条连接增加Ping/Pong客户端掉线但TCP没有感知时服务端可以通过心跳超时主动清理连接。不做这个连接数会随着手机锁屏、电脑休眠持续堆积直到服务器资源耗尽。4.3 跨平台样式不一致Uniapp编译到小程序、H5、App后弹窗、滚动条、v-model等表现差异很大。比如小程序里rpx单位和H5的px换算方式不同一开始大量用rpx结果同一套样式在不同平台的卡片宽度差出一截。后面我统一改用flex加百分比布局核心尺寸类用rpx容器类样式放弃固定宽度。还有一个容易踩的坑小程序里使用CSS变量在某些安卓真机上不识别所以关键颜色值我改用JS计算后内联注入确保低版本安卓基本一致。4.4 外部接口返回格式不可预期有的数据源接口异常时返回空数组而不是错误码有的字段名突然从snake_case改成camelCase。我的解法是两层防御后端解析前统一做字段类型和空值校验结构体里用mapstructure做兼容映射前端渲染前写一个normalize函数把数值类型强制转换缺失字段填默认值“-”。不要信任任何外部接口的返回格式这是这个领域最朴素的真理。4.5 AI辅助模块的时间幻觉在使用大模型API做异常摘要时我发现同一时间点在AI输出里偶尔出现前后不一致的表述非常影响面板的信任度。排查后发现问题不在模型而是我传给模型的上下文里混入了“采集时间”和“事件时间”两类不同时区的时间戳。统一把所有时间字段改成UTC存储展示时再按用户时区转换AI输出的时间描述就正常了。这个坑说明一个道理如果AI输出的东西一看就有逻辑缺口先检查输入数据而不是怀疑模型。整理成一张速查表现象根因解决方案多个数据源同时超时告警采集器串行执行慢源阻塞了其他源每源独立Goroutine加单飞语义连接数持续上涨客户端断线后无退避重连指数退避加随机抖动服务端心跳清理同一样式在不同平台不一致rpx与px混用、CSS变量兼容问题flex 百分比布局关键颜色内联注入接口字段解析失败外部接口返回格式不稳定后端mapstructure兼容映射前端normalize兜底AI摘要时间描述前后矛盾上下文混入不同时区时间戳统一UTC存储展示时转用户时区5. 写在最后几个项目之外的真实体会5.1 技术选型不是终点维护成本才是做完Status Deck之后我复盘过很多次最深的感受是技术选型本身一点都不难难的是每个选择后面跟着的维护成本。比如第一版我不上数据库是因为内存Map加快照文件就能覆盖MVP阶段的所有数据访问模式。等以后真的要查历史趋势、做长时间范围分析再引入时序数据库也不迟。判断一个技术要不要引入不是看它多流行而是看它能不能在接下来至少一个月里减少你的麻烦。5.2 后记下一步的方向这个项目目前还在持续迭代。我接下来打算做的两件事是一是给异常事件做聚类分析把重复告警合并成一条根因事件减少通知疲劳二是继续优化移动端体验让锁屏状态下的通知能直接展开一段摘要。如果你也想做一个自己的状态面板建议从一个你每天都会用到、不看就难受的信息源开始先把最小链路跑通让技术围绕需求转而不是反过来。下一篇我会讲采集器和告警引擎的具体编码实现包括一些可以直接复用的代码片段到时候再聊。
