From 2db69eb04f4941da0ba3bbc16d8a509873da9670 Mon Sep 17 00:00:00 2001 From: lxh2875931338 Date: Mon, 3 Aug 2026 22:55:26 +0800 Subject: [PATCH] =?UTF-8?q?=E4=BC=98=E5=8C=96=E9=83=A8=E5=88=86readme?= =?UTF-8?q?=E6=8E=AA=E8=BE=9E?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- readme.md | 40 +++++++++++----------------------------- 1 file changed, 11 insertions(+), 29 deletions(-) diff --git a/readme.md b/readme.md index a010273..b83a83d 100644 --- a/readme.md +++ b/readme.md @@ -181,7 +181,7 @@ Podux 是个好项目，理念上和我们是一致的：用 Web 界面管理 fr | 部署方式 | 单二进制 / Docker | 单二进制 / Docker | | 多平台支持 | ✅ 原生交叉编译 | ✅ 原生交叉编译 | -> Podux 与其说是一个 frp 控制面板，不如说是一个“一站式 frp 管理器 + 可视化数据流面板 + 通道保活监测工具”。这种一站式本身没毛病，甚至功能实现非常到位。
但 podux的框架选型有点重，而且很明显细节稍显仓促。PocketBase 自带 WebUI 的情况下，Podux 还要再包一层 WebUI——相当于给数据库的 UI 又套了个 UI。更费解的是，这层 WebUI 只支持导入，不支持导出。这设计确实让人有点摸不着头脑啦……
所以干脆换了一套轻量化工具自己上咯~ +> Podux 与其说是一个 frp 控制面板，不如说是一个“一站式 frp 管理器 + 可视化数据流面板 + 通道保活监测工具”。这种一站式本身没毛病，甚至功能实现非常到位。
但 podux 的框架选型有点重，细节也稍显仓促，最终结果就是内存占用相当夸张——1GB 都未必够它霍霍的，而且你根本不知道这些内存都花在了哪里。PocketBase 自带 WebUI 的情况下，Podux 还要再包一层 WebUI——相当于给数据库的 UI 又套了个 UI。更费解的是，这层 WebUI 只支持导入，不支持导出。这设计确实让人有点摸不着头脑啦……
所以干脆换了一套轻量化工具自己上咯~ > 不过现在的 frpc-console，更倾向于拿存储换内存呢……
毕竟内存卡也好，硬盘也罢，即使是嵌入式平台，价格都不算很离谱，也就是一张大点的64G或者128G内存卡的事情
但是内存可就不一样了哦，这玩意在嵌入式平台是真的寸土寸金呢……
咱就举个例子吧，RK3506，128和256M版本共存；全志H3，256 和 512M 内存并存
虽然这俩都不算太极端，尤其是全志 H3，挤一挤甚至 docker 版也能装得上，但是也能说明，在一些廉价的低功耗开发板上，内存容量其实真的很稀缺……
所以牺牲一点存储空间（镜像大了几十 MB），换来 50MB 的内存占用，这笔账怎么算都不亏，对吧？ @@ -196,50 +196,32 @@ frpc-console 的目标是： - **导入导出无缝迁移** - **热加载无需重启** -### Q: 如果 frpc-console 进程挂了，frpc 本身会受影响吗？ +#### Q: 如果 frpc-console 进程挂了，frpc 本身会受影响吗？ **不会。** -这是 frp-console 系列工具与同类项目最核心的区别之一。我们称之为 **“阴阳模式”**。
-接下来，我们将结合中式哲学思想，阐述这个名称的由来： +这是 frp-console 系列工具与同类项目最核心的区别之一。我们称之为 **“阴阳模式”**。 -#### 什么是“阴阳模式”？ +**什么是“阴阳模式”？** -以人的观察为出发点： - -- **阴**：看不见的业务流（frpc 进程、toml 配置文件、隧道连接） +- **阴**：看不见的业务流（frpc 进程、toml 配置文件） - **阳**：看得见的管理面板（Web 界面、API 服务） -大多数管理工具走的是 **“阳阴模式”**：面板是“大脑”，业务是“肢体”。大脑一旦停止工作，肢体也就瘫痪了。
-在这种模式下，管理面板与业务进程深度绑定，面板退出时业务进程也会随之终止。 +大多数管理工具走的是 **“阳阴模式”**：面板是大脑，业务是肢体。大脑一旦停止工作，肢体也就瘫痪了。 **frpc-console 走的是“阴阳模式”：业务是根基，面板是工具。** -- **阴主导阳**：业务不依赖面板存活，面板只是用来观察和调整业务状态的手段 -- **阳依附于阴**：面板的存在是为了服务业务，而不是反过来 - - -#### 不同部署方式下的行为 - **二进制部署：** - -frpc-console 启动时，会以子进程的方式拉起 frpc，并为它创建一个独立的进程会话（`Setsid`）。这意味着 frpc 完全脱离父进程的生命周期控制。即使 SSH 断开导致 frpc-console 进程退出，frpc 也会被系统的 init 进程（PID 1）接管，继续在后台稳定运行。配置文件（`frpc.toml`）是持久化文件，不依赖 console 进程存活。面板可以随时挂、随时重启、随时升级，但隧道业务不受任何干扰。 +frpc-console 启动时，通过 `Setsid` 为 frpc 创建独立会话，使其完全脱离父进程的生命周期控制。即使 SSH 断开导致 console 退出，frps 也会被 init 进程（PID 1）接管，继续稳定运行。 **Docker 部署：** +容器使用 `--restart=always`，console 退出时 Docker 自动重启并重新拉起 frpc。数据目录通过卷挂载持久化，配置不丢失。 -容器使用 `--restart=always` 策略，frpc-console 进程意外退出时，Docker 守护进程会自动重启整个容器。重启后，console 重新读取持久化的 `frpc.toml`，重新拉起 frpc 子进程。数据目录（`/opt/frpc-console/data`）通过卷挂载持久化，容器重启不会丢失任何配置。Docker 模式的本质依然是“阳辅助阴”——`restart:always` 的目的是确保阴（业务）持续运行，而不是为了保住阳（面板）本身。 +两种部署方式的本质一致：**面板是“阳”，服务于“阴”；“阴”不依赖“阳”而存在。** +**为什么同类项目很少这样做？** -#### 为什么同类项目里很少见到这种设计？ - -因为大多数管理工具把“面板”和“业务”耦合在一起，认为面板是前提条件，业务是附属品。当然了，这确实是正向的、符合直觉的设计方向。但是有一个被很多人忽略的事实：**真正需要长期稳定运行的是隧道本身，而不是管理界面的进程。** - -界面是用来观察和调整的，不是用来维持业务存活的。这是运维集群常用的“管理面与控制面分离”——只不过通常只在几千台服务器的集群管理里才会出现，很少有人会把它用在一个人用的 frp 管理工具上。 - - -#### 核心原则 - -console 只做“配置的保管者”和“进程的启动者”，而不是“配置的持有者”或“进程的绑定者”。即使 console 完全离线，已经生成的 `frpc.toml` 依然存在，frpc 进程依然可以独立运行。这是 frp 本身的容灾能力在管理工具层面的自然延伸——**可视化框架只是工具，业务本身才是核心。** +因为大多数管理工具默认“面板是前提条件”，而忽略了：**真正需要长期稳定运行的是隧道本身，而不是管理界面的进程。** > **管理面板可以丢，业务功能打死不能停。**