TL;DR

本方案是 个人服务器安全加固方案 的多机扩展版。在零公网暴露的基础上，解决三个核心问题：

• 🧠 多机分工：ARM 做性能，AMD 做稳定性
• 🔄 容灾高可用：Tunnel 多入口，单点故障不宕机
• 🛡️ 防回收（可选）：保活策略降低 Oracle 免费实例被 reclaim 的风险

前置条件：每台机器已完成 Oracle 服务器开机 SOP 和 个人服务器安全加固方案 相关文档：

• Tailscale 原理参见 Tailscale 零公网暴露方案
• Tunnel 配置详解参见 Cloudflare Tunnel 完整方案

整体架构

          🌍 用户请求
               ↓
   ☁ Cloudflare（CDN + WAF）
               ↓
   🚇 Tunnel（多入口容灾）
       ↓            ↓
   AMD-1         AMD-2
    ↓              ↓
         👉 ARM 主服务器
            （核心业务）

管理员 → Tailscale 私网（100.x）→ 任意一台服务器 SSH

三台机器分工

核心思想

最优解不是"平均分配"，而是：

• 🧠 ARM（4C24G）= 主力生产机（干所有重活）
• 🪶 AMD ×2（1C1G）= 边缘节点（保活 + 入口 + 备用）

原则：重的全丢 ARM，轻的用 AMD 做"永不掉线层"

ARM（4C24G）——主力生产机

所有核心业务全放这里。

Docker 主集群：

• Next.js（前端）
• API（Node / Python）
• AI 服务（embedding / 推理）
• 图床服务、后台管理

数据层：

• Redis（缓存）
• PostgreSQL / MySQL

系统服务：

• Cloudflare Tunnel（主通道）

资源规划

总体控制在 70% 使用率以内（防止波动导致 OOM）

AMD #1 ——入口节点（高可用）

使命：保证你永远能访问系统（哪怕 ARM 挂了）

部署内容：

• Cloudflare Tunnel：作为第二入口，指向 ARM 服务（通过 Tailscale IP）
• Nginx fallback：ARM 不可达时返回静态维护页面
• 健康检查脚本：定期检测 ARM，不通则自动切换策略

👉 ARM 挂了时：用户仍能访问，不会 502 / 断连

AMD #2 ——保活节点（防回收，可选）

Oracle 免费实例存在被回收的风险。但需要注意：Oracle 官方未公开具体的回收条件，社区流传的标准均为经验推测。

部署内容：

• 保活 cron 任务：定时产生 CPU/网络活动
• 轻量状态 API：返回健康状态，供监控使用
• 备用 Tunnel：第三入口，终极容灾

Tunnel 多入口容灾策略

Tunnel 基础配置（安装、config.yml、systemd）参见 Cloudflare Tunnel 完整方案 这里仅说明多入口差异化配置。

部署方式

在三台机器上使用同一个 Tunnel ID 运行：

cloudflared tunnel run homelab

Cloudflare 会自动将多个 connector 纳入同一 Tunnel，实现负载均衡和故障转移。

各节点 ingress 配置差异

ARM（主节点）： 直接指向本地服务

ingress:
  - hostname: api.yourdomain.com
    service: http://localhost:3000
  - service: http_status:404

AMD-1 / AMD-2（边缘节点）： 通过 Tailscale IP 转发到 ARM

ingress:
  - hostname: api.yourdomain.com
    service: http://100.x.x.x:3000  # ARM 的 Tailscale IP
  - service: http_status:404

容灾效果

保活策略（可选，防 Oracle 回收）

⚠️ 关于回收条件：Oracle 官方文档中没有明确说明免费实例的具体回收标准。社区中广泛流传的“7天CPU<10% + 网络流量极少”是用户根据经验总结的推测，并非官方规则。

以下保活策略是一种预防性措施，你可以根据自己的风险偏好决定是否配置。

AMD 保活 cron 配置

# 每 5 分钟 curl ARM 的健康检查接口（产生网络活动）
*/5 * * * * curl -s http://100.x.x.x:3000/health > /dev/null 2>&1

# 每小时轻量计算（产生 CPU 活动）
0 * * * * dd if=/dev/urandom bs=1M count=10 | md5sum > /dev/null 2>&1

ARM 保活

ARM 通常负载足够（跑着所有业务），一般不需要额外保活。但建议：

• 确保至少有 1 个服务持续运行（哪怕是空跑的 health API）
• AMD 的定时 curl 本身也会给 ARM 产生流量

Docker 部署实践

服务目录结构（ARM）

/app
 ├── docker-compose.yml
 ├── nginx/
 ├── api/
 ├── frontend/
 ├── redis/
 ├── postgres/
 └── ai-service/

关键：限制每个容器的资源上限

services:
  api:
    image: your-api:latest
    deploy:
      resources:
        limits:
          cpus: '1'
          memory: 1G

必须设置资源限制，防止单个服务吃满整台机器导致连锁 OOM。

ARM 镜像选择

选择支持 linux/arm64 的镜像：

node:18-alpine
python:3.11-slim
postgres:16-alpine
redis:7-alpine

多架构镜像构建参见 Docker 本地构建多架构镜像并部署全流程总结

最关键的 3 条原则

1. ARM 只做一件事：跑业务 — 不在 ARM 上做保活、探测、杂任务
2. AMD 建议"制造流量"（可选） — 降低被 Oracle 回收的风险
3. Tunnel 一定多点部署 — 这是免费实现高可用的核心

一句话总结

用 ARM 做性能，用 AMD 做稳定性，用 Cloudflare 做大脑。