折腾“凪光”的起因和抉择
兄弟们，这回的《凪光_最新_更新日志》，不是我主动想更新的，纯粹是被环境逼着又动了手。我那个用了快两年的数据聚合和可视化小工具“凪光”，之前一直跑在本地的NAS上，核心数据采集模块是用一个老旧的Python库写的。
本来觉得跑得还凑合，但自从那个上游数据源搞了一次大版本更新后，我的采集脚本就彻底歇菜了。每天早上起来一看日志，全都是Connection Reset Error，数据链直接断了。我当时就骂了一句，这帮人就不能提前发个通知吗？
最要命的是，我最近接了个远程协作项目，所有的效率数据和进度追踪都依赖“凪光”来做汇总展示。它一趴窝，我这边的工作效率直接掉了三成，每天光是手动去导出和整合数据，就耗费了我近两个小时。这完全是本末倒置。
我当时的选择有两个：要么花两天时间去研究那个新接口，修补旧的Python代码；要么就是彻底重构，把这个定时炸弹给我拔掉。我果断选择了后者，因为修补这种东西，就是给自己挖下一个更大的坑。
核心服务的彻底替换与实现
我给自己定了个规矩：这回重构，必须追求极致的稳定性，而且要方便部署，最好能打成一个文件扔上去就能跑。我翻出来之前研究过的几个方案，最终敲定了用Go语言来替换掉核心的Python脚本和*后台。
为什么选Go？图的就是它编译出来的二进制文件体积小，不依赖 runtime 环境，内存占用极低。我的NAS配置不高，用Go能最大限度地节省资源，而且我之前用它写过一些内部API，算是熟练。
- 第一步：定义数据流。 我没有直接去看怎么采集数据，而是先花了半天时间，重新设计了“凪光”的内部数据结构。我抛弃了所有不规范的字段，统一了时间戳格式，确保数据进入核心服务后，是干净、可用的。
- 第二步：重写采集引擎。 我动手了，用Go的协程机制来实现并行采集。面对上游那个刁钻的新API，我研究了半天它的请求头和鉴权流程，发现它开始频繁封IP。为了解决这个问题，我特地集成了一个简单的代理轮换机制，虽然只是用了几个免费的节点，但起码保证了数据能稳定地流进来。
- 第三步：构建API接口。 我没用什么复杂的框架，就是简单地写了几个标准的RESTful接口，让前端能通过JSON格式来拉取数据。重点是加入了缓存层，防止前端频繁刷新时直接击穿采集服务。
自动化部署的痛点与解决
新的核心服务跑得飞快，但很快又遇到了新麻烦：部署。每次我修改了代码，都需要手动SSH登录到NAS，然后拉代码、编译、停服务、重启服务。太麻烦了，我可不想在周末花时间来干这种重复劳动。
为了彻底解放双手，我决定引入自动化流程。我安装并配置了Gitea（私有Git服务），然后又在NAS上架设了一个Drone CI。这东西一开始把我折腾得够呛，各种权限和Docker容器的网络配置，让我一头雾水。
但我硬着头皮啃下来了。我写好了YAML配置文件，定义了完整的流水线：只要我提交代码到特定分支，Drone CI就会自动触发，在Docker环境里拉取代码，执行Go的交叉编译（编译成ARM64架构的二进制文件），编译成功后，通过SSH Key直接推送到NAS的指定目录，执行一条脚本来优雅地重启服务。
我敲下一个`git push`命令，不到两分钟，新的“凪光”核心服务就上线了。那种成就感，真是谁用谁知道。
“凪光”更新后的效果和体会
这回的更新日志，主要成果就是把“凪光”的心脏彻底换了。现在系统启动速度快了五倍，CPU占用率低到几乎可以忽略不计。最关键的是，数据稳定性得到了保障，我设置了五分钟一次的采集，已经稳定运行了一周，日志里再也没看到红色的错误信息了。
我发现，自己动手实践这种小项目，永远都在解决问题的路上。一开始只是为了修一个bug，结果逼着我把整个部署流程都自动化了。这种从零到一，把所有流程都掌控在自己手里的感觉，比单纯地用一个现成的轮子要踏实得多。今天就先分享到这里，我得去看看我的新版可视化界面，有没有又跳出来什么需要优化的小细节。