主 题：【Komari 接手第二天】agent 架构重构完成，服务端采用features方式组织
发 布 者：steve1996
标签分类： 日常
时 间：2026-09-20 21:51:29
内容预览：用来探测服务器性能指标的 agent（探针）部分架构已经整理完成。目前还是处于对原项目的重构阶段，重构完成之后，增加更多探测指标。服务端目录结构根目录按 Go 社区的标准约定分成三大块：cmd —— 命令行解析入口internal —— 核心业务逻辑pkg —— 可被外部复用的公共工具包internal 内部：按 features 组织internal 下面不是按技术分层（controller/service/model 那一套），而是按 features（功能模块）组织的：每一个 feature 就是一个相对独立的业务单元，自己的业务逻辑、数据结构、接口定义都收在自己目录里。模块之间尽量解耦，彼此不直接依赖对方的内部实现，需要协作时通过接口通信。除了各个 feature，还有一个 platform 模块，放的是多个 feature 模块共用的工具函数、数据结构、接口定义——避免每个模块都各写一套差不多的东西。新logo自己设计了一个logo，符合Komari Probe转向纯探针的方向有个问题现在就算用 AI 做 vibe coding，难道不会关注架构问题吗？项目小的时候怎么写都可以，但规模上去之后，如果一直不管架构，会不会担心以后加功能、做维护、排查 bug 的时候，就算让AI写也会很困难？
直达链接： https://www.nodeseek.com/post-939216-1
发 布 者：steve1996
标签分类： 日常
时 间：2026-09-20 21:51:29
内容预览：用来探测服务器性能指标的 agent（探针）部分架构已经整理完成。目前还是处于对原项目的重构阶段，重构完成之后，增加更多探测指标。服务端目录结构根目录按 Go 社区的标准约定分成三大块：cmd —— 命令行解析入口internal —— 核心业务逻辑pkg —— 可被外部复用的公共工具包internal 内部：按 features 组织internal 下面不是按技术分层（controller/service/model 那一套），而是按 features（功能模块）组织的：每一个 feature 就是一个相对独立的业务单元，自己的业务逻辑、数据结构、接口定义都收在自己目录里。模块之间尽量解耦，彼此不直接依赖对方的内部实现，需要协作时通过接口通信。除了各个 feature，还有一个 platform 模块，放的是多个 feature 模块共用的工具函数、数据结构、接口定义——避免每个模块都各写一套差不多的东西。新logo自己设计了一个logo，符合Komari Probe转向纯探针的方向有个问题现在就算用 AI 做 vibe coding，难道不会关注架构问题吗？项目小的时候怎么写都可以，但规模上去之后，如果一直不管架构，会不会担心以后加功能、做维护、排查 bug 的时候，就算让AI写也会很困难？
直达链接： https://www.nodeseek.com/post-939216-1
