mirror of
https://github.com/Rain-kl/OpenFlare.git
synced 2026-10-02 14:56:38 +08:00
[优化] 更新开发计划文档，明确第六版目标与实施步骤，增加节点数据采集与访问分析能力
This commit is contained in:
ryan
+195
-69
@@ -1,103 +1,229 @@
|
||||
# ATSFlare 开发计划
|
||||
|
||||
## 维护期说明
|
||||
|
||||
在当前 0.5.x 功能基线基础上，项目已进入整理维护期。
|
||||
本阶段新增一份专项计划文档 [docs/improve_plan.md](./improve_plan.md)，用于集中推进代码质量、性能优化与安全治理。
|
||||
若后续维护任务与本文件的阶段描述存在冲突，以 `docs/improve_plan.md` 中的优先级顺序为准。
|
||||
|
||||
## 1. 当前阶段
|
||||
## 1. 当前状态
|
||||
|
||||
当前结论：
|
||||
|
||||
* 第一版已完成并稳定运行
|
||||
* 第二版已完成并补齐 HTTPS、证书、域名、节点与预览能力
|
||||
* 第三版已完成，运维体验优化相关能力已经落地
|
||||
* 第四版已完成前端细节打磨与 UI 优化，但未单独维护专项计划文档
|
||||
* 当前正式进入第五版（0.5.x）开发，目标聚焦 OpenResty 反代与缓存性能优化，以及主配置文件接管
|
||||
* 第一版至第五版主线能力均已完成
|
||||
* 已完成阶段的过程性任务不再继续展开维护
|
||||
* 当前主线切换到第六版（0.6.x）
|
||||
|
||||
第六版主目标：
|
||||
|
||||
* 为节点增加请求数据采集、资源采集与 heartbeat 上报能力
|
||||
* 在 Server 侧完成访问分析、趋势计算与聚合查询
|
||||
* 改造管理端总览页与节点详情页，提升信息密度、数据层次和监控可读性
|
||||
* 建立可持续扩展的观测数据分层，避免在旧节点模型和旧首页接口上继续补丁式堆功能
|
||||
|
||||
---
|
||||
|
||||
## 2. 已完成范围归档
|
||||
## 2. 已完成范围压缩归档
|
||||
|
||||
### 2.1 已完成能力
|
||||
已完成能力统一归档为以下几类：
|
||||
|
||||
* 规则管理、配置发布、激活、回滚
|
||||
* Agent 注册、心跳、同步、应用、回滚
|
||||
* HTTPS/TLS 路由、证书托管、域名管理
|
||||
* 节点管理、专属 `agent_token`、全局 `discovery_token`
|
||||
* 配置预览、变更摘要、自定义请求头
|
||||
* 运维设置热更新
|
||||
* Server 下发 Agent 运行参数
|
||||
* Agent 自我更新与一键部署
|
||||
* Server 版本检查与自升级
|
||||
* 新版前端工程、主题切换与统一页面框架
|
||||
* 反代规则、配置版本、预览、发布、激活、回滚
|
||||
* Agent 注册、心跳、同步、应用、失败回滚
|
||||
* HTTPS/TLS、证书托管、域名管理
|
||||
* 节点管理、令牌体系、部署与更新链路
|
||||
* OpenResty 性能优化、缓存配置与主配置托管
|
||||
* 新版管理端前端、主题与统一交互框架
|
||||
|
||||
### 2.2 归档原则
|
||||
归档原则：
|
||||
|
||||
* 已完成阶段的实现细节以代码与 Git 历史为准
|
||||
* 不再为已完成工作维护过程性计划、迁移步骤或分阶段验收清单
|
||||
* 新的大功能阶段启动前，再补充新的计划文档
|
||||
* 第一版至第五版的实施细节以代码与 Git 历史为准
|
||||
* 本文件只维护当前有效主线，不再保留已完成阶段的过程性拆分
|
||||
* `docs/improve_plan.md` 继续作为并行整理清单存在，但不覆盖第六版主线优先级
|
||||
|
||||
---
|
||||
|
||||
## 3. 第五版目标
|
||||
## 3. 第六版范围
|
||||
|
||||
第五版主目标：
|
||||
### 3.1 第六版要做
|
||||
|
||||
* 提升 OpenResty 在当前反代链路下的连接、缓冲、超时、压缩与缓存性能
|
||||
* 由 Server 统一托管 OpenResty 主配置文件，Agent 不再依赖节点手工维护主配置
|
||||
* 所有新增优化项都进入 Server 统一配置面，由管理端维护、版本发布、Agent 拉取与应用
|
||||
1. 节点数据采集与上报
|
||||
* Agent 在每次 heartbeat 时上报最近周期内的请求数据
|
||||
* Agent 同步上报节点系统画像、CPU/内存/存储快照、磁盘 IO、OpenResty 入站/出站流量
|
||||
* 新增在线时长、操作系统、内核、架构、CPU 型号、逻辑核数、总内存、磁盘布局等节点维度信息
|
||||
* 采集节点健康事件，覆盖离线、OpenResty 不健康、配置未追平、资源逼近阈值和错误率异常
|
||||
|
||||
第五版不做：
|
||||
2. 服务端访问分析
|
||||
* 基于请求数据计算当前节点 QPS、访问次数、访问人数
|
||||
* 统计访问来源分布、访问趋势、状态码分布等核心指标
|
||||
* 支持总览维度与节点维度两套查询视图
|
||||
* 生成系统整体健康摘要，回答“是否健康、是否有风险、问题集中在哪些节点”
|
||||
|
||||
* 平台化缓存产品、Purge 系统、分层缓存、节点差异化缓存策略
|
||||
* 任意文本片段注入、任意 OpenResty 指令执行、节点侧自定义模板合并
|
||||
* 绕过占位符约束的主配置模板直写
|
||||
* 引入 Redis、Prometheus、消息队列等新基础设施作为第五版前置条件
|
||||
3. 总览页改造
|
||||
* 首屏新增世界地图看板，用于展示全部节点分布与在线状态
|
||||
* 调整总览信息结构，不再以单一“四卡摘要”作为主布局
|
||||
* 增加趋势、分布、Top 榜单、容量风险和异常信号展示
|
||||
* 引入类似 WAF/安全运营面板的信息组织方式，但聚焦 ATSFlare 当前系统健康与流量状态
|
||||
|
||||
## 4. 第五版实施顺序
|
||||
4. 节点详情页改造
|
||||
* 第一行重构为三块核心卡片：系统信息、实时资源占用、网络流量监控
|
||||
* 第二行展示最近 24 小时历史趋势，至少覆盖 CPU、网络、磁盘 IO
|
||||
* 第三行接续当前目标版本与应用记录等运维信息
|
||||
* 清理低价值、重复、信息密度低的展示模块
|
||||
|
||||
5. 架构可扩展性治理
|
||||
* 将节点观测拆分为静态画像、动态快照、窗口聚合、健康事件四类数据
|
||||
* 为总览页和节点详情页建立专用聚合接口，不继续依赖旧列表接口临时拼装
|
||||
* 控制原始数据保留窗口和聚合粒度，避免后期查询、存储和维护成本失控
|
||||
|
||||
### 3.2 第六版不做
|
||||
|
||||
* 不引入 Prometheus、ClickHouse、Kafka、ElasticSearch 等新基础设施
|
||||
* 不建设通用日志检索平台、APM 平台、调用链追踪平台
|
||||
* 不扩展为 GeoDNS、全球流量调度、节点智能选路系统
|
||||
* 不做任意自定义报表、任意维度 OLAP 查询或外部 BI 接入
|
||||
|
||||
---
|
||||
|
||||
## 4. 第六版实施顺序
|
||||
|
||||
建议按以下顺序推进：
|
||||
|
||||
1. 补齐 Server 侧 OpenResty 性能参数模型、默认值、校验规则与性能页入口，并补充主配置模板编辑能力
|
||||
2. 扩展配置渲染结果，使版本快照覆盖主配置文件与路由配置文件
|
||||
3. 调整 Agent 本地应用链路，支持主配置写入、校验、reload、失败回滚
|
||||
4. 补齐预览、diff、应用结果与日志，确保第五版能力可观测
|
||||
5. 以本机 OpenResty 与 Docker OpenResty 两种模式完成联调和回归
|
||||
1. 定义数据模型与 heartbeat 扩展协议
|
||||
* 明确系统画像结构、请求数据批次结构、资源快照结构、聚合结果结构与健康事件结构
|
||||
* 补齐保留策略、体积限制和失败回退规则
|
||||
|
||||
## 5. 第五版验收标准
|
||||
2. 完成 Agent 采集链路
|
||||
* 采集请求窗口聚合
|
||||
* 采集系统画像与运行时性能指标
|
||||
* 采集 OpenResty 入站/出站流量
|
||||
* 归并节点健康事件并挂入 heartbeat 上报
|
||||
|
||||
完成第五版时至少满足：
|
||||
3. 完成 Server 入库与分析链路
|
||||
* 接收并校验 heartbeat 扩展数据
|
||||
* 入库存储系统画像、原始批次、资源快照和健康事件
|
||||
* 生成总览页与节点详情页所需聚合统计与系统健康摘要
|
||||
|
||||
* 管理端可以查看并修改第一批 OpenResty 性能优化项
|
||||
* 管理端提供独立“性能”页面，支持结构化设置与主配置模板编辑/预览
|
||||
* 性能优化项保存后进入统一发布链路，而不是节点即时生效
|
||||
* Agent 可以接管主配置文件，并在 `openresty -t` 失败时完整回滚
|
||||
* 配置预览或 diff 能体现主配置与关键性能参数变化
|
||||
* 本机模式与 Docker 模式都能完成一次成功发布和一次失败回滚验证
|
||||
* 所有优化选项都由 Server 统一管理，不存在节点侧独立真相源
|
||||
4. 完成总览页改造
|
||||
* 世界地图看板
|
||||
* 系统健康摘要区
|
||||
* 核心访问指标区
|
||||
* 访问趋势与来源分布区
|
||||
* 节点状态、配置追平与异常摘要区
|
||||
|
||||
## 6. 当前执行原则
|
||||
5. 完成节点详情页改造
|
||||
* 系统信息卡片
|
||||
* 实时仪表盘与网络流量卡片
|
||||
* 24 小时趋势图
|
||||
* 下移并重组当前目标版本、健康事件与应用记录
|
||||
|
||||
第五版执行时遵循：
|
||||
|
||||
* 先遵守 `docs/design.md` 的系统边界
|
||||
* 再遵守 `docs/development-guidelines.md` 与 `docs/frontend-development-guidelines.md`
|
||||
* OpenResty 优化参数优先复用现有 `Option` 与设置页结构，避免引入新配置中心
|
||||
* 主配置文件接管必须和发布链路、回滚链路一起设计，不能只补局部写文件能力
|
||||
* 需求不改变边界时，直接按现有模型与结构增量实现
|
||||
* 需求改变边界时，先补设计，再补计划，再编码
|
||||
6. 补齐回归验证
|
||||
* Agent 心跳主链路
|
||||
* 聚合统计正确性
|
||||
* 健康事件触发/恢复正确性
|
||||
* 总览页与节点详情页的亮暗主题和空态/错误态
|
||||
|
||||
---
|
||||
|
||||
## 7. 新需求进入条件
|
||||
## 5. 第六版分阶段计划
|
||||
|
||||
满足以下任一情况时，才需要新增计划项：
|
||||
### 5.1 阶段一：采集协议与存储落地
|
||||
|
||||
* 引入新的核心业务对象或系统边界
|
||||
* 引入新的基础设施依赖
|
||||
* 调整部署模式或运行方式
|
||||
* 大规模重构前后端主干结构
|
||||
目标：
|
||||
|
||||
否则默认按常规开发任务处理，不再单独维护阶段计划。
|
||||
* 打通“节点采集 -> heartbeat 上报 -> Server 接收 -> 入库”主链路
|
||||
|
||||
任务：
|
||||
|
||||
* 扩展 Agent heartbeat payload
|
||||
* 新增系统画像、请求数据批次、资源快照和健康事件模型
|
||||
* 为请求明细、性能快照和聚合统计建立查询入口
|
||||
* 控制单次 heartbeat 体积，避免影响现有同步稳定性
|
||||
|
||||
验收标准：
|
||||
|
||||
* 节点可随 heartbeat 成功上报系统画像、请求数据与性能快照
|
||||
* heartbeat 扩展失败不影响配置同步主链路
|
||||
* Server 能按节点和时间窗口查询到原始上报数据与健康事件
|
||||
|
||||
### 5.2 阶段二：服务端分析与指标计算
|
||||
|
||||
目标：
|
||||
|
||||
* 形成总览页和节点详情页可直接消费的数据接口
|
||||
|
||||
任务：
|
||||
|
||||
* 计算当前节点 QPS、访问次数、访问人数
|
||||
* 计算访问来源分布、访问趋势、状态码分布
|
||||
* 生成最近 24 小时 CPU、网络、磁盘 IO 趋势数据
|
||||
* 统一总览级与节点级查询口径
|
||||
* 生成整体健康摘要与异常节点清单
|
||||
|
||||
验收标准：
|
||||
|
||||
* 同一时间窗口下总览与节点详情的数据口径一致
|
||||
* 核心统计字段可被测试覆盖，避免明显统计偏差
|
||||
* 24 小时趋势查询在现有基线上可接受，不出现明显不可用卡顿
|
||||
* 首页可直接定位离线、异常、配置落后和容量风险节点
|
||||
|
||||
### 5.3 阶段三：总览页改造
|
||||
|
||||
目标：
|
||||
|
||||
* 让总览页从“摘要入口页”升级为“运营与状态看板页”
|
||||
|
||||
任务：
|
||||
|
||||
* 实现世界地图节点看板
|
||||
* 重构首屏布局，减少对称摘要卡片堆叠
|
||||
* 增加系统健康摘要、趋势图、来源分布、状态码分布、节点异常摘要
|
||||
* 为地图、趋势和分布图补齐加载态、空态和错误态
|
||||
|
||||
验收标准：
|
||||
|
||||
* 总览首屏可直接看到全部节点分布
|
||||
* 总览页能展示比旧版更多的实时、趋势与健康信息
|
||||
* 页面在桌面和移动端都能稳定显示
|
||||
|
||||
### 5.4 阶段四：节点详情页改造
|
||||
|
||||
目标：
|
||||
|
||||
* 让节点详情页回到运维排障视角，提升信息密度和首屏价值
|
||||
|
||||
任务：
|
||||
|
||||
* 第一行实现系统信息、实时资源占用、网络流量三块核心卡片
|
||||
* 系统信息新增操作系统、内核、架构、CPU 型号、在线时长
|
||||
* 网络流量卡片展示 OpenResty 入站/出站流量，自适应单位
|
||||
* 第二行实现最近 24 小时 CPU、网络、磁盘 IO 趋势图
|
||||
* 第三行承接当前目标版本、OpenResty 健康、健康事件与应用记录等现有高价值模块
|
||||
* 移除低价值重复信息
|
||||
|
||||
验收标准：
|
||||
|
||||
* 节点详情首屏信息密度明显高于旧版
|
||||
* 第一屏即可完成系统识别、资源判断和流量判断
|
||||
* 趋势图可用于观察节点最近 24 小时性能变化
|
||||
|
||||
---
|
||||
|
||||
## 6. 第六版执行原则
|
||||
|
||||
第六版执行时遵循：
|
||||
|
||||
* 先遵守 `docs/design.md` 的系统边界
|
||||
* 再遵守 `docs/development-guidelines.md` 与 `docs/frontend-development-guidelines.md`
|
||||
* 数据采集优先走 heartbeat 批量上报，不新增独立常驻推流通道
|
||||
* 前端优先消费服务端聚合结果，不在浏览器做重型统计
|
||||
* 优先建设新的观测聚合链路，不继续在旧 `nodes` 列表接口与旧首页卡片上补丁式叠加字段
|
||||
* 总览页与节点详情页都必须同时覆盖加载态、空态、错误态和亮暗主题
|
||||
* 若第六版实现过程中需要新增基础设施或改变保留策略，必须先更新设计文档
|
||||
|
||||
---
|
||||
|
||||
## 7. 第六版总体验收标准
|
||||
|
||||
完成第六版时至少满足：
|
||||
|
||||
* Agent 能在 heartbeat 中稳定上报请求数据、系统信息和性能快照
|
||||
* Server 能基于上报数据计算 QPS、访问次数、访问人数、访问来源分布、访问趋势、状态码统计
|
||||
* Server 能稳定生成系统健康摘要、异常节点清单和配置追平状态
|
||||
* 总览页包含世界地图看板，并替换旧版以摘要卡片为主的单调结构
|
||||
* 节点详情页包含系统信息卡、实时资源占用卡、网络流量卡、健康事件区与最近 24 小时趋势图
|
||||
* 节点详情页保留当前目标版本等关键运维信息，但整体层级比旧版更清晰
|
||||
* 第六版不破坏现有 Agent 心跳、同步、发布、回滚主链路
|
||||
|
||||
Reference in New Issue
Block a user