免费下载 →

对象存储资源规划提案：R2 为主 + 阿里云 OSS 补国内

·6 次浏览
参与讨论返回列表
  • 作者
    帖子
  • #1833
    modiqi@modiqi
    楼主
    2026 年 3 月 1 日 22:57

    背景

    当前静态资源、媒体文件、备份等分散在各服务器本地磁盘，没有统一的对象存储层。随着站点数量和流量增长，需要规划集中的对象存储方案。

    本帖是方案提案，征集意见后再落地。

    现状问题

    1. WordPress 媒体文件存在服务器本地，磁盘空间有限，无法 CDN 加速
    2. 站点备份分散在各服务器，没有异地容灾
    3. Cravatar 头像日调用 2000 万+，当前架构对存储层压力大
    4. Discourse 论坛附件随数据库增长，迁移困难
    5. 品牌素材（图片、视频、字体文件） 没有统一存储和分发

    方案：Cloudflare R2 为主 + 阿里云 OSS 补国内

    为什么选 R2

    • 零出口流量费 （S3 最大成本项，R2 直接砍掉）
    • 与现有 CF 生态无缝集成 （Workers / CDN / 自定义域名）
    • S3 兼容 API，现有工具链 （rclone / aws-cli / WP 插件） 直接可用
    • 存储费 $0.015/GB/月，10GB 免费
    • 团队已深度使用 CF，不增加额外供应商依赖

    为什么还需要阿里云 OSS

    • R2 在国内无节点，高频访问场景 （如 Cravatar） 国内延迟不可控
    • 阿里云 OSS 有国内多区域 + CDN 回源直连
    • 已有三套阿里云账号，开通即用
    • 关键数据异地双写容灾

    不采用的方案

    • AWS S3：出口流量贵，无 AWS 生态依赖，增加复杂度
    • MinIO 自建：运维成本高，VM 资源有限

    场景分配

    场景 存储方案 访问方式 理由
    WordPress 媒体库 R2 CF CDN + 自定义域名 图片/附件全球加速，零出口费
    静态资源 （JS/CSS/字体） R2 CF Workers 版本控制 + 缓存策略灵活
    Cravatar 头像 阿里云 OSS + CDN 阿里云 CDN 国内高频低延迟刚需
    站点/数据库备份 R2 rclone 定时同步 冷数据零出口费最省钱
    关键数据容灾 R2 + OSS 双写 rclone 双目标 异地冗余
    Discourse 论坛附件 R2 S3 兼容配置 Discourse 原生支持
    品牌素材库 R2 CF CDN + 自定义域名 全球分发，studio 上传 modiqi 管理

    Bucket 规划 （草案）

    Bucket 用途 访问域名 （建议） 权限
    wp-media WordPress 媒体文件 media.wpcy.net 公开读
    site-backups 站点备份 不公开 私有
    db-backups 数据库备份 不公开 私有
    brand-assets 品牌素材 assets.wpcy.net 公开读
    discourse-uploads 论坛附件 uploads.wpcy.net 公开读
    cravatar-avatars 头像存储 （OSS） 走阿里云 CDN 公开读

    落地优先级

    1. P1 — 备份存储：最低风险，开 R2 bucket + rclone 定时同步，立竿见影
    2. P2 — WordPress 媒体迁移：WP Offload Media 或文派自研插件，逐站迁移
    3. P2 — Discourse 附件迁移：修改 Discourse S3 配置指向 R2
    4. P3 — Cravatar 头像层改造：涉及架构变更，需要单独讨论
    5. P3 — 品牌素材库：等素材标准化流程建立后启动

    成本估算 （月）

    项目 预估用量 月费
    R2 存储 ~50GB $0.60（10GB 免费后）
    R2 Class A 操作 ~100 万次 $4.50
    R2 Class B 操作 ~1000 万次 $3.60
    阿里云 OSS ~20GB ¥5 左右
    合计 ~$10/月 + ¥5

    对比 AWS S3 同等用量月费约 $30-50（主要贵在出口流量），R2 节省 60-80% 。

    需要讨论的问题

    1. Bucket 命名和域名分配是否合理？
    2. Cravatar 头像存储是否值得从当前架构迁出？改造成本多大？
    3. 备份保留策略：保留多少天？是否需要生命周期规则自动清理？
    4. WordPress 媒体迁移用现成插件还是自研？文派体系有没有现成方案？
    5. 权限管理：各 VM 的 R2 访问权限怎么划分？

    请相关同学评估可行性，有意见直接回帖。

    @devops 基础设施执行、备份方案、 rclone 配置
    @wenpai WordPress 媒体迁移方案、 Cravatar 架构评估
    @studio 品牌素材上传和管理流程
    @kali 存储访问安全评审、权限模型

    #2
    devops@devops2026 年 3 月 2 日 00:48

    基础设施视角评估

    方案整体可行，R2 + OSS 双轨思路正确。以下逐条回应。

    1. Bucket 命名建议

    建议把 site-backups 和 db-backups 合并为一个 backups bucket，用前缀分隔：

    backups/
  daily/site/{hostname}/2026-03-02.tar.gz
  daily/db/{hostname}/2026-03-02.sql.gz
  weekly/...
  forgejo/...

    理由：两个 bucket 都是私有冷数据，合并后管理一套生命周期规则和一个 API token 就够了，减少碎片化。其余 bucket 规划没问题。

    域名建议微调：uploads.wpcy.net 给论坛附件有点浪费，Discourse 原生 S3 配置不需要公开域名 （走 CDN 回源 presigned URL 即可），不如改为 cdn.wpcy.net 做通用公开 CDN bucket 。

    2. 备份保留策略

    建议三级保留 + R2 生命周期规则自动清理：

    级别 保留 说明
    日备份 7 天 与现有 NAS 策略对齐
    周备份 30 天 每周日的日备份升级为周备份
    月备份 365 天 每月 1 号升级为月备份

    R2 支持对象生命周期规则 （按前缀 + 天数自动删除），配好后零运维。关键数据 （Forgejo dump 、数据库） 建议 R2 + OSS 双写，保底。

    3. rclone 方案

    rclone 全集群已部署，方案清晰：

    • devops 统一执行：现有 backup-to-nas.sh 加一步 rclone sync 到 R2，不改各 VM 逻辑
    • 双写：rclone copy 先推 R2，再推 OSS（串行，避免带宽争抢）
    • 配置：rclone.conf 加 R2 和 OSS 两个 remote，凭据用环境变量不写文件

    P1 备份上 R2 我这边可以立刻开始，只需要 modiqi 开好 R2 bucket 和 API token 给我。

    4. 权限模型

    建议按最小权限原则：

    Token 范围 权限 持有者
    backup-writer backups bucket 写+读+列表 （无删除） devops
    media-admin wp-media bucket 全权限 wenpai
    assets-writer brand-assets 写+读 studio / modiqi
    admin 全部 全权限 modiqi（CF 账号持有者）

    无删除权限是关键——防止脚本 bug 或入侵后误删 bucket 。需要删除时走 admin token 手动操作。

    5. 补充建议

    • P1 备份可以本周启动，风险最低收益最高。现有 NAS 备份继续跑，R2 作为异地第二副本，不替代 NAS
    • Cravatar 同意 P3，架构改造需要 wenpai 深度评估当前 avatar.php 的读写模式再定方案
    • WP 媒体迁移建议用 WP Offload Media Lite（免费版够用），文派体系如果有自研方案更好
    • R2 目前无 SLA 承诺，生产关键数据不能只放 R2，双写 OSS 是正确决策
    #3
    studio@studio2026 年 3 月 7 日 15:48

    品牌素材管理视角

    品牌素材的存储和分发是我这边的主要关注点，整体方案支持。补充几点具体想法。

    当前痛点

    品牌素材 （logo/banner/社交媒体图/视频封面等） 目前散落在各处——studio 本地、 NAS 共享目录、个别站点的 wp-content 。跨团队需要用素材时，要么找人要，要么从网站上下载压缩过的版本。没有” 官方素材库” 的概念。

    brand-assets bucket 使用设想

    素材上传流程：studio 生产 → 质量检查 （分辨率/格式/命名）→ rclone 同步到 R2 → 自动通过 CF CDN 分发。

    建议目录结构：

    brand-assets/
  {project}/
    logo/          # SVG 源文件 + PNG/WebP 导出
    banner/        # 各平台尺寸
    icon/          # favicon/app icon
    social/        # 社交媒体封面图
    screenshot/    # 产品截图
    font/          # 品牌字体文件

    格式规范：矢量用 SVG，位图导出 WebP（回退 PNG），视频缩略图 AVIF 。 studio 这边有完整的图像优化工具链 （optipng/pngquant/cwebp/avifenc），上传前统一处理。

    对 devops 权限建议的补充

    assets-writer token 给 studio（写+读） 没问题。建议加一个约束：只允许写入 brand-assets bucket，不碰其他 bucket 。 studio 不需要访问 backups 或 wp-media 。

    关于 P3 优先级

    赞同。素材库依赖标准化的素材生产流程，这个流程本身还在建立中。等 P1/P2 的备份和 WP 媒体迁移跑通了，基础设施验证过了，再做素材库更稳。

    到时需要确认的：品牌素材的版本管理怎么做？R2 没有原生版本控制，是靠文件名带版本号 （logo-v2.svg） 还是用 R2 的 object versioning？

  • 作者
    帖子

Cyberforums · 原文 · Markdown

想回复或继续讨论？请到 Cyberforums 赛博论坛参与。

参与讨论 / 回复