zhenxiauto/AutomaticallyDeploySEOStaticSites/Architecture

Public

WeChat Login

Code Issues Pull requests Events Packages Insights

main

docs: 阐明 N 模板数量定义

.codebuddy
.ide
.vscode
deployment
docs
sites_data
.cnb.yml
.gitignore
IMPLEMENTATION.md
QUICKSTART.md
README.md
architecture.excalidraw
docker-compose.yml
package.json

🚀 千万级流量矩阵：Nuxt 4 静态站点自动化 SEO 部署架构演进笔记

背景与规模：管理 $1200 \times N$ （多模板）个地区子站，实现全矩阵每日 3.6 万+ 篇 SEO 文章的自动化生成、构建与部署。出于 IP 分散和风险隔离的考虑，同一模板的站点会被打散部署在多台物理服务器上。

一、核心痛点与极端约束条件

在海量站点矩阵的场景下，常规的 Web 部署方案会引发严重的资源灾难。我们面临着以下极限挑战：

极端的网络带宽限制：数千个站点每次全量构建会产生数十 GB 产物，如果每次全量传输，服务器带宽瞬间爆表。
苛刻的服务器存储与 Inode 限制：每天新增 3.6 万个 HTML/JSON 小文件，如果不做优化，服务器磁盘（尤其是 Inode 索引节点）将迅速耗尽。
零容器化依赖：目标物理服务器带宽有限且不安装 Docker，要求极致轻量级的运行环境。
严格的 SEO 拟人化要求：搜索引擎对“同一秒爆发式更新几万篇文章”极度敏感，必须实现平滑的定时发布机制。

二、部署架构的演进史（为什么放弃传统方案？）

在确立最终方案前，我们排除了以下在常规业务中完全可行、但在海量矩阵中会导致“成本与存储灾难”的方案：

❌ 传统 CI/CD 全量构建推送：数千个站点的构建产物庞大，如果每次更新都通过云端流水线全量传输到服务器，带宽瞬间爆表，且极易因网络波动导致部署中断。
❌ CI/CD 产物云端快照 (LFS / 压缩包 / COS 等)：原本计划在 CI 流水线开始和结束时，将构建产物打包存入 Git LFS 或腾讯云 COS / 阿里云 OSS 中作为缓存或备份。
- 放弃原因：存储成本呈指数级爆炸。 对于 $1200 \times N$ 个站点的高频更新（每天 3.6 万篇文章），全量保存构建快照会消耗海量、极其昂贵的云存储空间。由于压缩包的二进制特性阻断了增量复用的可能，哪怕只更新了一篇文章，云端也必须重新存储一份几十 MB 的完整快照，毫无性价比可言，如果作为CI/CD中的缓存存储一个是越来越贵，另一个原因是越来越慢。
❌ 单站点单仓库 + 服务器 Git Pull 拉取：最初的设想是为每一个站点建立一个独立的 Git 仓库，由 CI 构建后推送到对应仓库，服务器再通过定时 git pull 拉取最新内容。
- 放弃原因：存储空间增长失控。 对于纯静态站点而言，随着高频提交，每个仓库下的 .git 历史记录文件夹会迅速膨胀。成千上万个独立仓库的 .git 历史占用空间远超静态网页本身，纯属浪费服务器昂贵的磁盘资源。
❌ Serverless / EdgeOne Pages 等云托管：受限于云服务商的套餐额度（如每月仅几百次构建），连几千个站点的初始部署都无法满足，强行使用会导致账单不可控。

💡 破局核心思路：抛弃昂贵的“云端全量存储”与“独立代码库管理”，回归最纯粹的 Unix 哲学 —— 本地高频增量构建 + Rsync 差异化推流 + 物理硬链接去重。

三、终极架构设计：四位一体的工作流

系统被划分为四个核心模块，各司其职，将算力与存储成本降到最低：

1. 🧠 矩阵大脑：可视化中控台 (Nuxt 3 + FastAPI)

作为整个系统的指挥中心，部署在内网，不参与具体的业务承载，只负责策略调度。

前端 (Nuxt 3)：提供可视化的配置和监控面板。
后端 (FastAPI)：利用 Python 处理核心调度与并发任务。
核心功能：
- 资产中心：管理 域名 <-> 服务器 IP <-> 所属模板 ID 的映射关系。
- AI 内容策略引擎：对接大模型生成 Markdown，并为文章 Front-matter 随机注入未来的精准时间戳（如 2024-05-20 14:35:00）以实现定时发布。
- 任务队列监控：实时查看本地构建脚本的并发进度、失败重试状态。
- SEO 追踪器：定时拉取各大搜索引擎的 site: 收录数据并生成趋势大屏。

2. 🫀 动力心脏：本地并发构建引擎 (Node.js)

利用本地机器（或高性能内网服务器）廉价的 CPU 和庞大的存储空间，充当“物理 CI 机”。

高频定时构建（破解未来时间悖论）：每隔 1~2 小时轮询触发一次增量构建。Nuxt SSG 结合 $lte: now 逻辑，只打包时间戳早于当前时间的文章。完美实现无数据库状态下的“SEO 定时平滑发布”。
动态 CPU 并发：告别 for 循环串行。通过 os.cpus() 读取宿主机核心数，结合 p-limit 动态分配并发任务，榨干本地算力。


// 本地并发构建脚本示例
import pLimit from 'p-limit';
import os from 'os';
import { exec } from 'child_process';

const coreCount = Math.max(1, os.cpus().length - 2); // 留出 2 个核保证系统稳定
const limit = pLimit(coreCount); 

const tasks = sites.map(site => limit(async () => {
  await execAsync(`NUXT_SITE_ID=${site.id} npx nuxi generate`);
  // 执行 Rsync 同步...
}));
await Promise.all(tasks);

3. 🩸 输血管道：极致增量传输 (Rsync 调优)

抛弃全量覆盖，通过底层协议优化实现“秒传”。

文件差异比对：rsync -az --delete 仅传输变动的数百 KB 文本文件，未变动的 JS/CSS 传输量为 0。
断点续传护航：加入 --partial --append-verify，无惧网络波动，断网重连后精确从断开的字节继续传输大文件（如图片）。
SSH 多路复用 (Multiplexing)：通过注入 ControlMaster 参数，上千次同步共享后台复用的 SSH 通道，省去海量握手时间，传输速度提升 40% 以上。


# Rsync 终极推流命令示例
rsync -az --delete --partial --append-verify \
  -e "ssh -o ControlMaster=auto -o ControlPath=~/.ssh/sockets/%r@%h-%p -o ControlPersist=600" \
  .output/public/ user@${serverIP}:/www/sites/${domain}/

4. 🦴 承载骨架：极简静态服务器 (Nginx + 物理优化)

目标服务器无需安装任何运行环境（Node/Docker），仅需 Nginx 吐出静态文件。

跨站点的远程硬链接 (--link-dest)：由于同模板站点被打散在多台服务器，推送具体站点前，先向该服务器推送一份“基础模板库”。推送站点时附加参数：--link-dest=/www/templates/tpl_A_base/。Rsync 若发现相同文件，直接在服务器硬盘创建物理硬链接。同一服务器上 500 个同模板站点，JS/CSS 物理占用永远只有 1 份！
Inode 耗尽防御：静态站点小文件极多。新购服务器挂载数据盘时，必须抛弃默认格式化参数，强制使用 XFS 或 mkfs.ext4 -i 4096 /dev/vdb 提升 Inode 密度，防止“磁盘未满但无法创建新文件”。
Nginx 动态泛路由 (零运维)：抛弃为每个站点写独立 .conf 的做法。使用正则动态捕获域名并映射目录，新增站点时 Nginx 配置 0 修改，0 Reload。


# Nginx 终极动态配置
server {
    listen 80;
    # 动态捕获用户访问的域名 (如访问 www.beijing.com, 捕获 beijing.com)
    server_name ~^(?:www\.)?(?<domain>.+)$;

    # 动态映射目录：请求全部分发到对应的域名文件夹
    root /www/sites/$domain;
    index index.html;

    location / {
        try_files $uri $uri/ /index.html;
    }

    # 静态资源强缓存 (配合硬链接威力巨大)
    location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg)$ {
        expires 1y;
        add_header Cache-Control "public, max-age=31536000, immutable";
        access_log off;
    }
}