缘起
我手头有几台零散的机器：日常用的 Windows 主力机、WSL 环境，外加一台国内的轻量云服务器。平时想把它们串起来统一看状态、跑一点像 FRP 隧道之类的轻量服务，但为了这点需求直接糊一整套 Kubernetes 显然太重了。
因此 ServiceFleet 打算从一个更轻的切口开始：节点怎么准入、心跳什么时候算过期、期望把服务放在哪、实际上又跑在了哪。先把这几件事的账算清楚，上面的管理界面才立得住。
控制链
管理平台最怕做成「点一下按钮就假装部署好了」。ServiceFleet 在架构上围绕一条持续运转的控制链展开：先写下期望状态（desired），结合实时观测（observed）生成放置计划（plan），再去执行动作（act），最后靠新一轮观测回读结果。哪一环断掉，系统就会退回「只管发请求、不管死活」的状态。
节点池在设计上也明确分成两类：一类是自有、可完全接管的 managed 节点池，另一类是权限受限的 relay 志愿节点池。前者可以执行完整维护，后者只接受受限的转发或轻量任务；这种边界直接写进底层契约，不能光靠前端按钮置灰来防呆。
已具备
- 01
节点准入与心跳时效
节点注册、租约过期与健康证据分开判断，避免把「几分钟前有过心跳」直接当成「现在还能调遣」。
- 02
排空与撤销的状态判断
明确区分「正在排空」「已排空」与「被撤销」，给每次维护动作留出清晰的起点和退路。
- 03
放置预览 API
基于当前 CPU 与内存快照生成新服务副本的放置预览，先看清会落到哪台机器，再决定是否执行。
- 04
双形态分发
底层共享同一个 Go 节点核心，桌面端用 Wails 打包（无需依赖 Docker），服务端则提供 Docker + Web 部署形态。
边界
目前它还停留在 M0 原型阶段，不能当成现成的平台来用：
- 当前仓库里的 Go 只读原型与架构文档由 AI 初始化生成；我正顺着 desired / observed / plan 的控制链契约、节点心跳租约与模块生命周期一点点啃透代码并推进后续改造。
- 尚未接入真实多节点通信、鉴权与完整调度器；放置预览目前仅看静态快照，还没处理资源抢占与状态漂移。
- Wails 桌面端与 Docker + Web 的双形态目前还处在架构落地初期，尚未完成完整的双端打包交付。
- 现阶段它更像一份围绕控制链展开的设计练习，重心在于把「声明、观测、计划、动作」的契约理顺。