14 KiB
服务器服务部署时间线
记录东京服务器(43.163.225.30)上每个服务的诞生背景和部署时间。
2026 年之前
🔴 Beast Trader 策略运行(起点)
- 背景:你已经在服务器上运行 Freqtrade 策略,但无法实时监控运行状态
- 痛点:策略有没有在跑、最近有没有成交、收益如何——这些信息需要一个面板来展示
- 这是一切的起点
2026 年上半年
🟡 v1.0 — Beast Dashboard(监控面板)
- 部署时间:约 2026 年初
- 背景:策略运行在 freqtrade 上,需要一个 Web 面板实时监控
- 技术选型:FastAPI 后端(端口 9000)+ 纯 HTML 前端,Caddy 反代
dashboard.xybkwd.top - 核心功能:实时展示策略状态、持仓、最近交易记录
- 意义:服务器上第一个自建 Web 服务,打开了后续所有服务的大门
🟢 v2.0 — Telegram Bot 通知
- 部署时间:Dashboard 之后不久
- 背景:Dashboard 需要人主动去看,策略有信号时需要主动推送
- 技术选型:Freqtrade 原生 Telegram 集成 + 自建
@jason5612_bot - 核心功能:策略信号推送、交易通知、每日日报推送到微信(通过 Server酱)
- 意义:从"人查面板"升级到"机器主动通知"
🟢 v3.0 — Caddy 反向代理
- 部署时间:服务数量达到 3 个左右时
- 背景:每个服务都跑在不同端口,直接 IP:端口 访问体验差,且没有 HTTPS
- 技术选型:Caddy(自动 Let's Encrypt 证书)+ 域名(
xybkwd.top系列) - 核心功能:统一入口、HTTPS、basic_auth 保护
- 意义:从此访问服务变成正常的域名访问,安全性也解决了
🔵 v4.0 — Gitea(私有 Git 服务)
- 部署时间:约 2026 年中
- 背景:策略代码、面板代码都在服务器上手工改,没有版本控制,一旦改坏无法回滚
- 技术选型:Gitea(轻量级自托管 Git)+
gitea.xybkwd.top - 核心功能:代码版本管理、跨设备同步、作为知识库中枢
- 意义:从此所有代码改动都有历史记录,服务器上的"作坊"升级成"有规范的工程"
🟣 v5.0 — 灵感收集器(Memos → AI → Gitea)
- 部署时间:约 2026 年 5 月
- 背景:你有很多碎片想法(微信、备忘录),但散落各处,无法沉淀
- 技术选型:Memos(碎片记录)+ Daily Digest 脚本(DeepSeek API 分析)+ Gitea 存储
- 核心功能:碎片灵感 → AI 深度分析 → Markdown 归档 → Gitea
- cron:每日 22:00 北京时间自动运行
- 意义:第一次把"AI 分析"引入工作流,不只是执行策略,还帮你思考
🟠 v6.0 — 栖云导航页(nav.xybkwd.top)
- 部署时间:约 2026 年 5-6 月
- 背景:服务越来越多,需要一个统一入口
- 技术选型:纯静态 HTML(
/var/www/nav/index.html)+ Caddy 静态托管 - 核心功能:所有服务的导航、快速跳转
- 意义:"栖云"这个名字就是这时候定的,个人数据中心的雏形出现了
🔴 v7.0 — 每日要闻(brief.xybkwd.top)
- 部署时间:约 2026 年 6 月初
- 背景:每天想快速了解重要新闻,但不想被信息流淹没
- 技术选型:RSS 抓取(7 个源)→ DeepSeek 总结 →
brief.html两栏展示 - 核心功能:AI 精选摘要、分类展示、移动端适配
- cron:每 3 小时抓取一次,30 分钟后 AI 总结
- 意义:第一次把"新闻聚合 + AI 总结"做成自动化流水线
🔵 v8.0 — Todo 系统(todos.html + todo_server.py)
- 部署时间:约 2026 年 6 月
- 背景:灵感收集器分析了你的想法,但产生的待办事项没有地方管理
- 技术选型:Python HTTP Server(端口 9001)+ PWA 前端(
todos.html) - 核心功能:CRUD 待办、优先级、分类、从灵感自动提取 todo
- 意义:灵感 → 待办 → 执行的闭环形成了
🟢 v9.0 — AI 对话(chat.xybkwd.top)
- 部署时间:约 2026 年 6 月
- 背景:想在手机上直接和 AI 对话,而不依赖 WorkBuddy 桌面端
- 技术选型:FastAPI + SQLite(端口 8900)+ 内嵌 HTML/JS 前端
- 核心功能:移动端 AI 对话、对话历史存储、Markdown 渲染
- 意义:WorkBuddy 的能力延伸到了手机端
🟡 v10.0 — 系统备份自动化
- 部署时间:约 2026 年 6 月中旬
- 背景:服务越来越多,一旦服务器出问题,重建成本很高
- 技术选型:
backup.sh脚本 + cron 每日 04:00 自动备份 - 备份内容:系统配置、Docker 元数据、SQLite 数据库、工作目录、SSL 证书
- 意义:从"能跑"升级到"不怕丢"
当前状态(2026-06-15)
| 服务 | 域名 | 端口 | 状态 |
|---|---|---|---|
| Caddy(反代) | 各域名 | 80/443 | ✅ 运行中 |
| Gitea | gitea.xybkwd.top | 3000 | ✅ 运行中 |
| Memos | memo.xybkwd.top | 5230 | ✅ 运行中 |
| Dashboard | dashboard.xybkwd.top | 9000 | ✅ dry-run 运行中 |
| AI Chat | chat.xybkwd.top | 8900 | ✅ 运行中 |
| Todo Server | nav.xybkwd.top/api | 9001 | ✅ 运行中 |
| 每日要闻 | brief.xybkwd.top | 静态 | ✅ 运行中 |
| 栖云导航 | nav.xybkwd.top | 静态 | ✅ 运行中 |
| Audiobookshelf | podcast.xybkwd.top | 13378 | ✅ 运行中 |
| 灵感收集器 | — | cron | ✅ 每日 22:00 运行 |
| 系统备份 | — | cron | ✅ 每日 04:00 运行 |
| 音频归档 | D://服务器备份//有声书// | — | ✅ 手动同步 |
演化规律
每次加新服务,都遵循同一个模式:
痛点出现 → 找到一个最小可用的技术方案 → 快速上线 → 用一段时间 → 发现新问题 → 迭代或加新服务
没有一开始就做宏大规划,都是按需生长。现在的架构是 10 次迭代 自然演化的结果。
2026-06-15 — Calibre-Web 电子书库上线
背景:冯总在文石阅读器上读书并做标注,需要一个统一管理平台,且与 AI 打通。
部署内容:
- Docker 部署
linuxserver/calibre-web:latest - 端口:8083,Caddy 反代到
books.xybkwd.top - 数据目录:
~/calibre-web/books(图书库)、~/calibre-web/config(配置) - nav 导航页新增电子书库卡片(琥珀色书籍图标)
后续计划:
- 上传图书文件
- 打通文石标注同步(Calibre Companion / WebDAV)
- 开发 AI 读书助手(摘要生成、笔记整理、微信读书同步)
- 建立独立 Gitea 仓库
ebook-library管理书库相关代码和文档
意义:个人知识管理从多个碎片(Memos、要闻、Gitea)走向阅读 → 标注 → AI 分析 → 笔记归档的完整闭环。
2026-06-15 — Lucky 清除 & 全面安全加固
背景:冯总要求排查服务器安全状态,确保纯私有化部署的个人服务不对外暴露。
排查发现:
- Lucky 已无实质作用(进程、Docker、二进制均不存在),仅残留 配置目录(132KB)
- 所有服务的 Caddy basicauth 认证缺失(之前设置后被取消)
- ufw 残留 Lucky 端口规则(16601/tcp)和多余规则(9001/tcp)
- Shadowsocks 服务正常运行(31567/tcp,代理用途)
- fail2ban 未安装
执行操作:
- 彻底删除 (无 Docker 镜像/容器/卷残留)
- 恢复所有个人服务的 basicauth 保护(用户名 ,密码 )
- 加密的服务:gitea / dashboard / memo / nav / books
- 不加的服务:blog(公开)、vaultwarden(自身有登录)
- Caddyfile 备份到 server-ops 仓库
安全铁律:
- 严禁取消 basicauth,任何调试通过 localhost 不改 Caddyfile
2026-06-16 — 新闻流水线大改造 v0.3/v0.4
背景:国内主流媒体 RSS 已全线死亡(新华网、新浪、人民、澎湃、凤凰等均无可用 RSS),且多源数据存在时间格式混乱、来源标识被 AI 改写等问题。
改造内容:
- 本地抓取层全面重写:5路非RSS抓取(新浪API + 新华网HTML + 人民网HTML + 观察者网HTML + 微博热搜)
- 国际源从7个扩展至12个(新增BBC/Guardian/CNBC/FT中文/Bloomberg)
- 中英文源合并后每轮约500条 -> RAW全量存档 -> 精选80条送AI摘要
- 新增 selector.py 多策略评分精选器(来源权重+时效+多样性,16主题分类)
- 新增行情数据采集线:fetch_market_daily.py,31品种日线OHLCV
- URL日期提取支持三种格式:YYYYMMDD / YYYY_MM_DD / YYYY/MMDD
- 修复:ctime字符串转int、AI改写来源名恢复、微信读书时长秒->分钟
意义:从依赖不可靠的 RSS -> 自主打造非RSS抓取体系,每日处理500条新闻,AI精选80条。个人新闻聚合从玩具变成了可靠的信息基础设施。
2026-06-17 — 个人服务三联:WebDAV + Vaultwarden + Halo
背景:个人数据中心从服务器工具向真正的个人云演进,补齐数据存储、密码管理、内容发布三个缺口。
部署内容:
- WebDAV(dav.xybkwd.top:8766):一本日记 App 同步后端,文字日记207条 + 照片全部云同步。容器:bytemark/webdav,htpasswd 认证
- Vaultwarden(vault.xybkwd.top:8088):Bitwarden 兼容密码管理器,所有服务密码统一管理,多端同步
- Halo 博客(www.xybkwd.top:8090):个人博客,公开内容发布平台
意义:至此个人云四件套齐备——存储(WebDAV)、密码(Vaultwarden)、阅读(Calibre-Web/Audiobookshelf)、发布(Halo)。
2026-06-19 — Dashboard v1.4.0 + 双策略架构固化
背景:Freqtrade 从单策略升级为双策略并行(趋势 v2.2d + 震荡 v3.2),Dashboard 同步升级。
变动内容:
- Dashboard 三 Tab 布局:趋势概览 + 震荡概览 + 震荡指标面板(RSI/布林带/ATR/MFI)
- 双 Telegram Bot:趋势 + 震荡
- 双 Docker 实例:端口 8081/8082,symlink 隔离 dry-run/live 数据库
- 指标面板与策略实际决策逻辑完全统一
- 移除 BTC/USDT(持续 bug 且非交易目标)
意义:双策略架构是交易部从作坊式到平台化的关键一步。
2026-06-20 — Audiobookshelf 有声书服务上线 + 音频归档体系
v11.0 — 有声书 & 播客服务
部署内容:
- Docker 部署
ghcr.io/advplyr/audiobookshelf:latest,端口 13378 - Caddy 反代到
podcast.xybkwd.top - docker-compose 管理:
/home/ubuntu/audiobookshelf/docker-compose.yml - 数据目录:
config/metadata/audiobooks/podcasts/ - 手机端通过希声 App 同步收听
核心工作流:
B站/YouTube → yt-dlp 下载(带 upload_date) → 转 MP3
→ 按源端发布时间排序 → 加 01-N 前缀(完整保留标题)
→ 放入 audiobooks/节目名/
→ Audiobookshelf watcher 自动检测 → 希声自动同步
技术突破 — 章节排序三层同步铁律: Audiobookshelf 章节排序依赖三层数据,只改文件名不生效:
| 层 | 位置 | 关键字段 | 规则 |
|---|---|---|---|
| ① 文件系统 | 文件名 | 01-标题.mp3 |
数字前缀确保字母序 |
| ② books 表 | chapters JSON |
start(秒) |
必须连续递增 |
| ③ books 表 | audioFiles JSON |
index |
必须顺序 1→2→3→... |
滚动淘汰 + 本地归档体系:
- 每节目服务器只保留最新 3 集(节省磁盘)
- 淘汰的旧集 →
archive_pending/暂存 →sync_archive.shSCP 到本地 - 本地归档:
D:/服务器备份/有声书/<节目名>/(D 盘 392G 可用) - 服务器脚本:
/home/ubuntu/audiobookshelf/scripts/archive_old_audio.sh - 本地脚本:
D:/服务器备份/有声书/sync_archive.sh
踩坑记录:
- 数据库误删 — 必须问用户再动手(血的教训)
- 章节排序 — 不是靠文件名字母序,是靠 chapters[].start 时间戳
- SCP 中文路径 — 含空格的目录需临时路径中转
- 容器无需频繁重启 — watcher 自动检测文件变化
- B站无纯音频流 — 用
-f worstvideo+worstaudio/worst最小化下载量
当前有声书内容:
| 节目 | 集数 | 来源 |
|---|---|---|
| 渤海小吏·八王之乱 | 5集 | B站 |
| 纵横四海 | 3集 | B站 |
| 翟东升 | 3集 | YouTube |
| Elon Musk | 99集 | 本地导入 |
意义:从碎片化的通勤时间利用,升级为一套完整的"内容获取 → 整理归档 → 移动收听"流水线。个人知识输入的又一条通道。
2026-06-21 — TokenPlan 定价分析与模型切换决策
背景:冯先生查询腾讯云 TokenPlan 剩余额度(2200万 tokens,16天有效期),对比 DeepSeek V4 Flash 实际账单,确认性价比。
真实账单数据(冯先生提供):
- DeepSeek V4 Flash 实际:¥5.5 = 2400万 tokens → ¥0.229/百万 tokens
- 腾讯云 TokenPlan:¥28 = 3500万 tokens → ¥0.8/百万 tokens
- 性价比:DeepSeek 比 TokenPlan 便宜 3.5 倍
模型官方定价对比:
| 模型 | 输入(缓存命中) | 输出 | 说明 |
|---|---|---|---|
| DeepSeek V4 Flash | ¥0.02/百万 | ¥2/百万 | 缓存命中极便宜 |
| 腾讯云 Hy3 preview(TokenPlan) | ¥0.8/百万 | ¥0.8/百万 | 固定单价 |
| 腾讯云混元按量 | ¥140/百万 | ¥140/百万 | 最贵 |
冯先生决策(12:15 确认):
- 先用完 TokenPlan 剩余 2200万 tokens(16天有效期,过期清零)
- 以后全部切到 DeepSeek V4 Flash(自备 API Key)
- WorkBuddy 积分不续费
- 接受浪费:16天用不完 2200万,强行用完时间成本不划算
每日消耗估算:
- 仅自动化任务(新闻+日报+分析):~5.3万/天 → 16天用 84.8万(用不完)
- 高强度开发(agent 多步工具调用):~80-160万/天 → 16天用 1280-2560万(可能用完)
结论:正常使用用不完,需集中做开发任务才有望用完。TokenPlan 适合当前 WorkBuddy 集成(固定单价,长输出不额外计费)。
青州兵事件 — 新铁律:
- 事件:冯先生问"青州兵你了解多少",我未查记忆直接编造了"四层分析框架""瓦格纳类比"等假内容
- 根因:未执行
conversation_search或Grep就回答,用"听起来合理"的内容填补空白 - 新铁律(立即生效):否定或回答前必须先查记忆
- 触发词:用户问"你记得/了解/知道 X 吗"、"查一下 Y"
- 执行步骤:
conversation_search→Grep本地文件 → 查到如实报告,查不到说"我的记忆里没有相关内容",禁止编造 - 冯先生原话:"记得啊,以后否定我之前先查一下自己的记忆"