# 架构精简候选

> **用途**：本文是**待决策清单**，不是现状描述。现状看 [`../架构总览.md`](../架构总览.md)。
> 每条都是「已确认可以动、但需要你拍板」的项，附收益 / 代价 / 风险 / 怎么做。
>
> 更新时间：2026-10-06

---

## 一、复杂度的真实来源：不是「件数多」，是「跨了 6 个环境」

| 环境 | 谁在维护 | 上面跑什么 | 是否必需 |
|---|---|---|---|
| **腾讯云 CNB** | 托管 | 代码主仓 + 构建 + 发布（7 个 stage） | ★ 必需（发布的骨架） |
| **Cloudflare** | 托管 | 评论后端 + RSS + 证书只读面 + D1/KV + 200181.xyz 的 DNS | ★ 必需（零运维） |
| **国内机 `119.29.215.187`** | **自己** | 9 个容器（见下）+ 一堆手工 vhost | 部分必需 |
| **境外 VPS `23.254.236.47`** | **自己** | Gitea（代码辅仓） | ⚠️ **2026 年 11 月到期** |
| **家庭 F50 / OpenList** | **自己** | 离线加密备份 | ★ 必需（唯一的离线层） |
| **本机 Windows** | **自己** | 备份计划任务、本地写作前端 | 半必需 |

> **四台自维护设备 = 复杂度的真正来源**，而不是「用了几个云服务」。
> 托管服务再多也不累人（出问题找平台），自己维护的机器每一台都要有人记得它。

国内机 9 个容器里，**属于本项目的只有 3 个**：

| 容器 | 归属 | 状态 |
|---|---|---|
| `editor-api` | 本项目 | ✅ 写作后台的线上发布入口 |
| `cn-certkeeper` | 本项目 | ✅ 证书签发 + 部署 |
| `cn-dns-helper` | 本项目 | ⚠️ **疑似遗留**（见候选 2） |
| `1Panel-certimate-OKCO` | 历史遗留 | ⚠️ **可清**（见候选 1） |
| `1Panel-openresty` / `-mysql` | 用户的 | 面板与站点 |
| `1Panel-alist` / `vaultwarden` / `1Panel-frps` | 用户的 | 与本项目无关 |

→ **能动的只有两个**，而且都很干净。

---

## 二、精简候选

### 候选 1 ★ certimate 容器 —— 停掉 `1Panel-certimate-OKCO`

| | |
|---|---|
| **现状** | 容器还在跑（`certimate/certimate:v0.4.32`）。但 **7 个工作流里「会签发并部署」的 2 条已停用**（`enabled=0`），只剩 3 条纯监控告警 |
| **为什么可以停** | 本项目已**完全接管**签发与部署。certimate 现在唯一的作用是「万一要回滚」，而它的凭据早就导出到 `secrets-backup/`，库文件也有 `.bak-*` |
| **收益** | 少一个常驻容器（内存是这台机器的短板：总 1967 MB / 已用 791 MB）；少一个「静默竞争」风险源 |
| **风险** | 低。但**告警能力会消失** —— 三条监控工作流会随之失效。而本项目的证书监控已由 `cn-certkeeper` 的 `/status` + Worker 后台接管，**功能不重叠** |
| **怎么做** | `docker stop 1Panel-certimate-OKCO` → 观察 1～2 周（覆盖一次 04:10 自动续期 + 一次证书到期检查）→ 确认无碍再考虑删容器与数据卷。**别急着删**，先 stop |

> ⚠️ 若将来要停用，先确认「证书到期提醒」这一层有人接手（现在是 Worker 后台 + 探针）。

---

### 候选 2 ★ `cn-dns-helper` 容器 —— 大概率已是遗留

| | |
|---|---|
| **它是什么** | 「DNS-01 助手」：接受 `POST /dns/txt`，代调用有 DNS 权限的 Cloudflare API 写 TXT 记录 |
| **当初为什么有** | Phase 1 时代**签发跑在 CF Worker 里**，而 Worker 那份 CF token 是 Workers/KV/D1 专用的（没有 Zone/DNS 权限）→ 只好让国内机代写 |
| **为什么现在不需要** | ★ 签发已搬到 `cn-certkeeper`（国内机），它**自带 dnsprovider**，直接调腾讯云 DNSPod / Cloudflare API。实测 `/preflight` **7/7 全过**，其中 `cloudflare → 200181.xyz` 报「**可读**」= 这份凭据有 Zone 权限 → **不需要中转** |
| **代码侧证据** | `deploy/cn-certkeeper/lib/dnsprovider.js` 里 `remote` 型是**兜底分支**（注释写明「用于 CF token 无 DNS 权限的场景」）；Worker 侧 `dnsremoted.ts` **已无任何引用** |
| **收益** | 少一个常驻容器 + 少一个对外 HTTP 端点（虽然只绑回环） |
| **风险** | 低，但**要实测确认**：万一某条域名的 DNS-01 仍走 `remote`，停掉会让那次续期失败 |
| **怎么验证** | ① 查 `cn-certkeeper` 的凭据里有没有 `remote` 型（`/preflight` 的 dns 项只列了 `tencent-usj` / `tencent-tt` / `cloudflare`，**没有 remote**）② 停容器 → 手动跑一次单域续期（`renew-one.mjs`）→ 成功即可判死 |
| **结论** | **建议停掉**，跑一次续期验证 |

---

### 候选 3 Gitea —— 迁到新机，还是干脆不留

**这是本轮最大的一刀**，完整分析见 [`Gitea迁移指南.md`](Gitea迁移指南.md) 第九节。摘要：

| 选项 | 收益 | 代价 |
|---|---|---|
| **A. 迁到新机** | 保留「在线可 clone、可按提交追溯、不受平台规则约束」的副本 | 继续养一台机器 + 一个要运维的实例（**且 Gitea 不参与构建、不参与发布**） |
| **B. 不迁，去掉辅仓** | 少一台机器、少一个部件，架构回到 **CNB 主仓 + F50 离线加密 bundle** 两层 | 少一层在线冗余（但离线层是**完整历史**，且已带失败告警） |
| C. 换托管平台私有仓 | 不用自己运维 | CNB 已是托管平台，再挂一家同性质的收益有限 |

**判断依据**：Gitea 现在挡的是「CNB 跟 GitHub 一样出问题」——
但**离线 bundle 已经覆盖了这个场景**。Gitea 多出来的独有价值只有
「**在线可浏览**」与「**可增量拉取**（不用等一天一次的备份）」。
这两点用不上，**B 就是合理的简化**。

> 若选 B：`deploy/gitea/` 留在仓库里即可（部署包与迁移清单留着，随时能重建），
> 然后按 `Gitea迁移指南.md` 第三节把那 9 处 `gitea` 引用清掉 ——
> **别忘了线上那两处**（`/srv/editor-api/.env`、`/srv/blog` 的 remote）。

---

### 候选 4 写作前端两套并存（`write-server/` vs `write/`）

| | |
|---|---|
| **现状** | `write-server/`（Next.js，线上 `post.usj.cc`）+ `write/`（本地 Windows 前端），**架构总览已注明「功能重叠」** |
| **另外** | `editor-api/`（国内机）才是**真正的那条发布入口** —— 后台发的文章走它 |
| **收益** | 少维护一套前端；文档里的「写作系统」不再需要解释三个东西的关系 |
| **风险** | 取决于你实际用哪个。若两套都在用，就不是「精简」而是「迁移」 |
| **建议** | 先确认实际使用频率，再决定砍哪个。**本轮不动** |

---

### 候选 5 手工 vhost 的证书（不是精简，是收尾）—— ✅ **已完成**（2026-10-06）

`writeapi.usj.cc` 的证书**没被本项目纳管**，实测当时是 **RSA / 到期 2026-12-07** → **12 月会断**。

**实际采用的第三条路（比下面 A/B 都省）**：它和 `artalk.usj.cc` **本来就同用一张
`*.usj.cc` 证书**，所以直接让它**用相对软链接跟随 artalk** 即可 ——
零代码、零新增凭据、随续期自动跟随：

```bash
D=/1panel/1panel/www/sites/writeapi.usj.cc/ssl
ln -sfn ../../artalk.usj.cc/ssl/fullchain.pem "$D/fullchain.pem"
ln -sfn ../../artalk.usj.cc/ssl/privkey.pem   "$D/privkey.pem"
```

> ⚠️ **必须用相对路径**：宿主是 `/1panel/1panel/www/…`、容器内是 `/www/…`，
> 写绝对路径会在容器侧**断链**，而断链后 `nginx -s reload` 会**静默失败**
> （服务不中断、握手照旧）—— 直到某天 nginx 重启才发现 HTTPS 挂了。
> 验收必须看 **worker 进程是否真的重启**，不能只看握手。
> 完整机制与排错见 [`证书管家.md`](证书管家.md) §9.15。

结果：`CN=usj.cc`/RSA/2026-12-07 → **`CN=*.usj.cc`/ECC/2027-01-04**，容器内可读、
预检通过、worker 已重启、`/health` 200。

当时考虑过的另外两条路（保留备查）：
- **A. 让 cn-certkeeper 覆盖它**：把它纳入部署目标 —— ❌ **走不通**：它**不是 1Panel 站点**
  （面板 11 个网站里没有它），`findWebsite('writeapi.usj.cc')` 必然抛「找不到网站」
- **B. 在 1Panel 里把它建成正式站点**，自然被 `ssl/upload` + `sslID` 覆盖 ——
  技术上可行，但要动生产 conf（`client_max_body_size 30m`、`proxy/*.conf` 都得迁），
  风险与本收益不成比例，**未采用**

另一个手工 vhost `dnsapi.usj.cc` **不做**：它是 `cn-dns-helper` 的反代入口（`127.0.0.1:8018`，仅 HTTP），
去留应与候选 2（`cn-dns-helper`）一起决定。

详见 [`../架构总览.md`](../架构总览.md) §6 待办 #13。

---

## 三、明确**不建议**动的（必要复杂度）

| 项 | 为什么保留 |
|---|---|
| **又拍云 + 多吉云 + EdgeOne 三个分发目标** | 境内/境外双线路是业务需求（境内走又拍云→多吉云，境外走 EdgeOne），不是历史堆积 |
| **Cloudflare Workers 全家（评论 + RSS + 证书只读面）** | 零服务器零运维，是本项目**最省事**的一层 |
| **国内机的 `editor-api`** | 写作后台的发布入口，没有替代品（CF Worker 跑不了 git push） |
| **国内机的 `cn-certkeeper`** | CF Worker 免费版 CPU 硬顶 10ms，签发跑不动；用户已否决 CF Paid（比这台机器还贵） |
| **家庭 F50 上的离线备份** | 唯一不依赖任何平台账号的层 |
| **三层留存** | 三层**失效模式不同**，不是重复（见 `架构总览.md` §5.3） |

---

## 四、建议的执行顺序

```
✅ 已完成（2026-10-06）候选 5 —— writeapi.usj.cc 证书纳管（相对软链接跟随 artalk，见上）
1. 【本周】候选 1 —— stop certimate 容器（零风险，观察即可）
2. 【本周】候选 2 —— 停 cn-dns-helper + 跑一次续期验证（大概率能省一个容器；
   顺带决定 dnsapi.usj.cc 这个反代入口的去留）
3. 【11 月前】候选 3 —— Gitea：迁 or 不留（★ 必须决定，机器要到期了）
4. 【有空】候选 4 —— 写作前端收敛（先看使用频率）
```

> 前三项做完，国内机上属于**本项目**的容器从 3 个降到 1 个（只剩 `editor-api`），
> 自维护环境从 6 个降到 5 个（去掉境外 VPS）。
> **这才是「感觉复杂」的真正解药 —— 减的是「要记得它」的东西，不是「存在于架构图里」的东西。**