用户四问:「把项目文件全部理一遍 还有readme文件」「gitea 后面可能还要迁移 帮我写一个迁移文档」
「证书管家做完了吗」「感觉现在架构还是复杂了」
一、文档梳理:根目录 15 个 md → 2 个
根目录只留 README.md(入口)+ 架构总览.md(现状唯一事实源),其余全部归位:
docs/
├── README.md ← 新增:文档地图(入口 / 当前有效 / 历史归档 三层)
├── 证书管家.md ← 原「函数版证书管家-方案.md」改名
│ (它早已是「现状+沿革」文档,标题名不副实 —— 签发早已不在 CF Worker)
├── Gitea迁移指南.md ← 新增
├── 架构精简候选.md ← 新增
├── CNB构建落地方案.md / GITEA_SECRETS.md
└── archive/{平台与选型,功能与修复,主题与内容}/ ← 32 份
- 32 个归档文档统一加 `> 📦 本文档已归档` banner,并指向架构总览
—— 这个仓库历史文档里全是「权威口径」,混看很容易拿废弃结论当现状
- gitea-backup/ → deploy/gitea/(原名「backup」不准,它是部署包;与其它 deploy 单元并列)
- 新增 md 链接校验(python 脚本,中文路径用 sed 不安全)→ 首轮 18 处断链
(多一层目录要让 banner 里的相对路径补一个 ../)→ 修正后 0 断链
二、新增 docs/Gitea迁移指南.md(★ 有死线:境外 VPS 11 月到期)
★ 核心价值是「指出迁移面已大幅缩小」:仓库原有的 deploy/gitea/迁移前检查清单.md
(2026-10-04)是为「Gitea + act_runner + 又拍云同步 *整套* 搬迁」写的,**那个前提已经不存在**——
构建归 CNB,runner / upyun-sync / 中转机 / COS 都不需要了。迁移实际只剩「搬数据卷 + 改地址」。
★★ 全文最重要:本仓有 9 处写死了旧地址,按易漏程度排序(1-3 本机,4-5 线上)
1 本机 .git/config 的 gitea remote
2 scripts/setup-cnb-remotes.sh 的 GITEA_URL 默认值
3 deploy/editor-api/bootstrap.sh 的 GITEA_URL 默认值
4 ★ /srv/editor-api/.env 的 GITEA_URL ← 漏了会「持续报错但只警告不阻断」,没人发现
5 ★ /srv/blog 的 gitea remote ← 同上
6 docs/GITEA_SECRETS.md
7-9 架构总览.md / README.md / editor-api/README.md
(不用改:docker-compose.editor.yml、server.mjs、pushall 别名 —— 只引用 remote 名字)
另含:建议新实例改用域名而非 IP(以后搬机器只改 DNS;⚠️ Gitea 28 起只读 ROOT_URL 不读
[server] DOMAIN);rsync 而非 dump(属主必须 uid/gid 1000);切换顺序「先建新的→验证→再拆旧的」;
验证清单强调 `git push gitea --dry-run`;第九节给出「干脆不留这个辅仓」的选项与判断依据。
顺带修掉两个硬伤:
- deploy/gitea/docker-compose.yml 的镜像 tag `1.28.0-rootless` 根本不存在
(Gitea 28 起去掉 1. 前缀)→ 改 28.0.0-rootless(pin 死,不用 latest)
- deploy/gitea/.gitignore 漏了 backups/(跑一次备份就会把含 secrets 的 dump 写进历史)
三、证书管家核实(结论:已上线运行,2 个遗留)
线上实测:容器 Up (healthy);/preflight 7/7 全过;3 组域名;下次自动续期 04:10。
遗留 ① writeapi.usj.cc 证书没纳管(真问题):nginx 配置在 /www/conf.d/writeapi.usj.cc.conf,
不在 /www/sites/ 管理树里 → 1Panel 的 ssl/upload+sslID 物化碰不到它。
实测仍是 RSA / CN=usj.cc / 到期 2026-12-07,本项目续期不会更新 → 12 月会断。
遗留 ② dnsapi.usj.cc 没上 HTTPS。
(澄清假问题:200181.xyz 公网看到的 LE 证书是 CF 自家边缘证书,与本项目无关)
四、新增 docs/架构精简候选.md(回应「架构还是复杂了」)
结论:复杂度不在件数,在「跨 6 个环境,其中 4 个要自己维护」。国内机 9 个容器里属于本项目的
只有 3 个,能动的只有 2 个。5 个候选 + 建议执行顺序:
1 停 certimate 容器(工作流已全停用)——先 stop 观察,别急着删
2 cn-dns-helper 大概率已是遗留(「Worker 侧签发」时代产物;现在签发在国内机且自带 dnsprovider,
/preflight 显示 CF 凭据可读;Worker 侧 dnsremoted.ts 已无任何引用)
3 Gitea:迁 or 不留
4 两套写作前端收敛(本轮不动,先看使用频率)
5 writeapi.usj.cc 证书纳管(12 月死线)
并明确列出 6 项「必要复杂度,不建议动」。
五、架构总览补齐证书管家子系统(★ 之前完全缺席)
一个完整子系统在「事实源文档」里一个字都没有 —— 这本身就是文档债。补:
- §0 一句话(四→五个子系统)、§1.1 子系统表、§1.2 地址地图两行
- **新增 §5.7 证书管家**:职责划分 / 为什么非要这么分(Worker 免费版 CPU 10ms)/
三条不能破的红线(Worker 不得签发 · 证书路由只认 Bearer 会话 · 角色必须正着枚举放行)/
纳管域名表 / 与 certimate 的关系 / 已知遗留
- .cnb.yml 行数 284 → 337(数字漂了);头部更新时间 → 2026-10-06;附录表改指 docs/
- §6 待办:#13(证书遗留)、#14(复杂度盘点)新增;#7 改写为「Gitea 11 月到期,★ 有死线」
六、记忆
.workbuddy/memory/MEMORY.md 新增「文档结构」「Gitea 迁移死线」两节;证书管家节补实测与遗留。
8.8 KiB
📦 本文档已归档(2026-10-06)。它记录的是当时的评估与方案,其中的结论可能已被后续决策推翻。 请勿据此判断当前架构 —— 现行架构唯一事实源是
架构总览.md。
阿里云 ESA 评估(对比 EdgeOne)
2026-10-04 · 问题:「阿里云也有个跟 EdgeOne 很像的服务,能不能考虑一下?」 现状:
usj.cc域名 境外解析在 EdgeOne、境内解析在多吉云(DNS 分线路)
一、结论先说
能考虑,但对你这个站有一条硬伤,直接卡住:ESA Pages 每个项目最多 2000 个文件,你的产物是 3267 个。
而 EdgeOne Pages 是 20000 个——你只用了 16%。
所以结论是:换阿里云 ESA 不是"简化",是"降级到刚好装不下"。
二、阿里云对标的到底是什么
| 腾讯云 | 阿里云 |
|---|---|
| EdgeOne(边缘安全加速平台) | ESA(Edge Security Acceleration) —— 就是原来的 DCDN 改名 |
| EdgeOne Pages(Git 导入 + 自动构建 + 静态托管) | ESA Pages(也叫「函数和 Pages」) |
| Edge Functions / Cloud Functions | ESA 边缘函数(V8 Isolate,只支持 JS) |
| 节点 | 阿里云 3200+ 边缘节点 |
能力确实是同级的——都免费、都支持 ICP 备案、都能绑备案域名走大陆节点、都是「Git 导入 + 自动构建 + 全球分发」一套。你问得没错,这是对标产品。
但两者的尺寸门槛差了 10 倍,这是分水岭。
三、★ 决定性的一张表:文件数门槛
我逐个查了官方配额页(不是二手说法):
| 项目 | ESA Pages | EdgeOne Pages | Cloudflare Pages |
|---|---|---|---|
| 单项目文件数 | 2000 ❌ | 20000 ✅ | 20000 ✅ |
| 单文件大小 | 25 MB | 25 MB | 25 MiB |
| 源码包大小 | 1024 MB | — | — |
| 总存储容量 | — | 5 GB | — |
| 构建次数 | — | 500 / 月 | 500 / 月 |
| 构建超时 | — | 20 分钟 | 20 分钟 |
| 构建算力 | — | 4 核 6 GB | — |
| 自定义域名 | — | 200 个 | — |
| 你的站 | 3267 → 超限 63% | 3267 → 占 16% | 占 16% |
来源:阿里云官方文档《函数和 Pages 使用限制》——"Pages 文件数 2000 个:每个 Pages 项目最多可上传 2000 个静态文件";EdgeOne 官方《限制与配额》——"单项目文件数 20000"。
这一条把 ESA 从候选名单里筛掉了,其他指标都不用比了。
附带发现:EdgeOne Pages 的构建环境是 4 核 6 GB —— 比你那台广州中转机(2 核 1.9 G)强得多。如果走它的 Git 集成自动构建,hugo 构建完全不需要你自己的机器。
四、你的 3267 个文件是怎么构成的
1337 html ← 文章页 + 分类/标签/归档页
1211 png ┐
295 webp │
254 jpg ├─ 图片/视频类合计 1778 个(占 54%)
7 mp4 │
6 jpeg │
3 svg ┘
66 xml ← sitemap / rss
59 js
3 woff2 / 3 woff / 3 mp3 / 3 css / 6 json / 2 txt
────────────────
3267 总计
纯文本类(html/xml/css/js/json)只有 1473 个 —— 这个数字很关键,它意味着「如果非要用 ESA」还有一条窄路(见第六章)。
五、ESA vs EdgeOne:真实差异(去掉重复项之后)
免费套餐大部分能力是重复的,真正有差别的是这几条:
| 维度 | ESA | EdgeOne | 谁赢 |
|---|---|---|---|
| 文件数 | 2000 | 20000 | EdgeOne(决定性) |
| 大陆节点 | 有(需备案) | 有(需备案) | 平 |
| 流量 / 请求 | 不限 | 不限 | 平 |
| 开通大陆加速的门槛 | ⚠️ 默认不含大陆,要发帖解锁 | 直接可用 | EdgeOne |
| 免费套餐数量 | 每账号限 1 个 | 站点 1 主域 + 200 子域 | EdgeOne |
| 构建算力 | 未披露 | 4 核 6 GB | EdgeOne(已知值) |
| 单文件限速 | 官方未披露;社区称"不限速",另有称峰值 5 Mbps —— 存疑 | 单文件单线程 4 Mbps(≈500 KB/s) | ESA 可能赢 |
| WebSocket | 免费版不支持(第三方实测) | — | EdgeOne |
| 速度(第三方实测) | 大陆节点覆盖更多、网络速度更高 | 加速效果更佳、全球覆盖更广(Anycast) | 各有说法 |
| 迁移成本 | 要重接一次 | 你已经在用 | EdgeOne |
值得注意的两点
- ESA 免费版默认不含中国大陆加速 —— 官方原文:"By default, this plan does not include Chinese mainland acceleration." 要解锁得在任意社交/博客平台发一篇 30 字以上的推荐帖(带
#AlibabaCloudESA #ESAPages标签 + 官方图),再进群提交链接。你写博客顺手能完成,但这是个额外操作,跟"简化"反向。 - ESA 免费版的「不限速」有矛盾说法 —— 一方说无限速适合大流量,一方说峰值带宽约 5 Mbps。如果你的痛点是那个 12.8 MB 的 mp4(EdgeOne 下首载约 25 秒),这一条值得实测,但它是 ESA 唯一可能赢的地方。
六、如果非要用 ESA:唯一的一条路
把 1778 个图片/视频剥离到对象存储(OSS / 又拍云 / 多吉云存储),Pages 只托管 1473 个文本文件 → 落回 2000 以内。
但代价是:多一个存储服务、多一套域名与缓存配置、构建产物要改写图片链接。这是"增加复杂度"换"换一家厂商",跟你的目标正好相反。
不建议。
七、ESA 唯一值得拿的东西(互补用法)
如果只是想用阿里云,不要用 ESA Pages,用 ESA 的 CDN 加速能力。
ESA 免费版(Entrance plan)本质是一个不限流量的 CDN,可以回源到任意源站。它能做的是:
- 回源到你的又拍云 / OSS 存储 → 只加速,不托管,没有 2000 文件限制
- 用 ESA 的边缘函数收编现在的
blog-admin(CF Workers)
这确实有个价值:阿里云一家能同时给你 CDN + Pages + 边缘函数 + 对象存储,比「EdgeOne + CF Workers + 又拍云 + 多吉云」更统一。
但这又引入了第四家厂商,而你现在的问题恰恰是厂商太多。
八、而且你现在的双线路,其实已经是"简化过"的形态
你说的「境外 EdgeOne、境内多吉云」,本身就是分线路 DNS 调度的结果:
usj.cc
├─ 境外线路 → EdgeOne(Pages 项目,--area overseas)
└─ 境内线路 → 多吉云 CDN(融合 CDN,70+ 节点,20 GB/月免费)
这已经做到了"境内外分流" —— 跟 EdgeOne 双区域方案想达成的效果是一样的。所以真正的问题不是「CDN 选阿里云还是腾讯云」,而是:
要不要把这两条线合并成一家?
- 合并到 EdgeOne:改一个参数(
-a global)或建国内站项目 → 砍掉多吉云 ✅ - 合并到 ESA:从零接一次,还撞上 2000 文件上限 ❌
- 维持现状:多一条线,但不增加架构复杂度——CDN 数量不等于复杂度
注意最后一条:你架构的复杂度大头在构建与搬运(Gitea、act_runner、中转机、COS、artifact 链),不在 CDN 数量。多留一个多吉云,不会让架构变复杂;砍掉那条搬运链才会。
九、建议
- 别换 ESA Pages —— 2000 文件上限是硬伤,你的站 3267,装不下。
- 想收敛到一家,就走 EdgeOne —— 你已经在用,同一个控制台、同一个项目(
-a global实验),或者建个国内站项目。迁移成本近零。 - 多吉云可以留着 —— 它免费 20 GB/月、融合 CDN(依托大厂节点)、速度好,而且它是独立的国内线路,跟 EdgeOne 互为备份。不构成复杂度问题。
- 如果哪天站点瘦身到 2000 文件以内(比如把 1778 个图片全挪到对象存储),ESA 会重新变成候选 —— 但那时 EdgeOne 也一样能用,还是没必要换。
十、待核实项(不装作确定)
| # | 事项 | 状态 | 怎么验 |
|---|---|---|---|
| 1 | 多吉云当前的回源源站是谁(又拍云存储 / EdgeOne / 其他) | 待确认 | 多吉云控制台看回源配置 |
| 2 | ESA 免费版是否真的"不限速"(vs 峰值 5 Mbps) | 说法矛盾 | 需实测,但没必要为它迁移 |
| 3 | ESA Pages 是否支持 Gitee 作为代码源 | 官方只列 GitHub,第三方提到 Gitee | 若成立,对简化链路有价值 |
| 4 | EdgeOne Pages 的 Git 集成是否支持 Gitee | 上次标的第 5 条,仍未确认 | 若支持可砍掉自建 Gitea + act_runner |
十一、一句话总结
阿里云 ESA 确实是对标 EdgeOne 的产品,能力同级——但 ESA Pages 限 2000 文件,你的站 3267 文件,直接在门口就被拦下。 换厂商解决不了你的问题;你的问题在构建与搬运链,不在 CDN 选谁。