Contents
前言
在CF的众多功能中，有个非常实用的功能是我最近几个月才知道的，那就是本文的主角：R2(CF提供的对象存储服务)，通过R2，可以满足个人站长在建站初期就不得不面对的一个重要需求：图床。
附加知识：什么是图床以及为什么需要图床？
图床是一种专门用于存储和管理图片的在线服务，用户可以将图片上传到图床，图床会生成一个链接，通过这个链接，用户可以在网页、博客、社交媒体、论坛等平台上展示图片，而无需直接在这些平台上存储图片。
图床在网站搭建过程中，不仅能够提升性能，还能降低成本、简化管理，并增强安全性，因此对于网站的成功运营至关重要。
广义上来说，图床就是一种展现效果：一个能将存储的图片内容展现为http(s)://*.png(也可以是其他格式图片)类型的链接，例如，使用wordpress建站的时候，如果要在文章里插入图片，只需要将图片上传到自带的媒体库中，就会生成一个URL：
上图中孙悟空图片对应的URL格式类似于
https://blog.tangwudi.com/wp-content/uploads/xxxx/xx/孙悟空.jpg，这就是最基本、最简单的网站内置式图床了。
但是，这种网站内置式图床有不少缺点：
• 增加网站服务器消耗
用户访问量较大的情况下，会对网站服务器造成额外的资源消耗和带宽消耗(这点倒是可以通过CDN缓解)。
• 增加网站服务器运维压力
在图片越来越多的时候，会消耗网站服务器磁盘空间，且不利于运维(批量图片上传、站点搬迁、冗余站点切换等)
• 不利于网站图文内容策略分离
很多时候对待网站文字内容和图片的策略是需要区别制定的(缓存策略、防盗链、防热链等)，这种方式会让配置策略的时候配置逻辑更复杂和更难以取舍。
基于以上原因，在本文中所说的图床，不包括这种内置式图床，只是指独立于网站的，单独提供服务的图床。
图床的实现有多种方式可以选择，包括自建服务器(VPS、NAS或者chevereto这种开源图床系统)、基于社交媒体或免费服务、 IPFS 这样的 P2P 分布式存储系统、对象存储等。
其中，因为扩展性和易用性，使用对象存储作为图床的方式在许多场景下非常流行，也是本文介绍的重点。
注：自建图床也有自己的优势，比如使用chevereto自建图床，可以自己管理自己的图片，并且还可以给图片加水印等，有兴趣的朋友可以参考文章：docker系列 使用docker基于chevereto搭建属于自己的图床、奇技淫巧系列 使用chevereto给图片增加水印。
附加知识：对象存储(COS)
什么是对象存储？
对象存储(Cloud Object Storage)是一种将数据作为对象(Object)进行存储的技术，每个对象包括数据本身、相关的元数据，以及一个唯一的标识符。对象存储与通常的文件系统不同，文件系统以目录和文件的层次结构来管理数据，而对象存储的管理单位则是"存储桶"：bucket。
对象存储和文件系统的对比
对象存储和我们在日常生活中早已习惯的文件系统相比，有些抽象，尤其是在实际使用中，某些对象存储服务提供了与文件系统类似的功能，比如支持多级“文件夹”结构。这可能让两者在表面上看起来很相似。然而，它们在底层的工作原理和应用场景上有很大的差异，可以从几个方面进行对比：
1. 数据存储结构：
• 文件系统：数据以文件的形式存储在目录中，目录本身可以包含子目录，形成一种树形结构。每个文件在文件系统中都有路径，例如/home/user/documents/report.pdf。
• 对象存储：数据被存储为对象，每个对象包括数据本身、元数据（描述数据的信息），以及一个唯一的标识符。对象存储不使用传统的文件路径或目录结构，虽然一些对象存储服务支持通过“桶”和“文件夹”的方式组织数据，但这些都是在逻辑层面上提供的便利，底层并没有实际的文件目录结构。
2. 使用体验：
• 文件系统：在文件系统中，用户可以直观地创建文件夹、组织文件，并通过路径访问文件。文件系统非常适合需要复杂目录结构和频繁读写的小文件。
• 对象存储：在对象存储中，用户将数据作为"Object"存储，访问时通过唯一标识符（如URL）来获取数据。虽然可以用“桶”和“文件夹”的方式组织对象，但这些只是逻辑上的分组，底层没有实际的目录结构。
举例说明，在R2具体某个存储桶的对象(Object)中，有"以目录形式查看前缀"这个选项，如果不勾选，就是其真实的模样，这时候根本没有目录这东东：
如果勾选，就有了目录：
所以，目录什么的在对象存储看来都是浮云，"障眼法"而已。
3. 应用场景：
• 文件系统：适合处理需要复杂层级管理和权限控制的文件，如操作系统、办公文档、代码库等。
• 对象存储：广泛应用于云计算场景，用于存储大量静态数据，如媒体文件、备份、日志、数据湖、网页托管等。
4. 存取方式：
• 文件系统：通过文件路径访问数据，文件路径在用户眼中是直观的层级结构。
• 对象存储：通过API访问数据，数据通过URL或标识符定位，提供的文件夹结构只是为了方便用户组织数据，实际访问时则完全依赖于标识符。
综上所述，尽管对象存储的“桶”在用户观感中的“文件夹”结构与文件系统类似，但在底层，它们的工作方式完全不同：文件系统依赖于目录结构，而对象存储则是基于对象和元数据的管理方式。
虽然这种区别可能不会在用户界面上明显体现出来，但在性能、扩展性和使用场景上有着深远的影响：对象存储擅长处理海量的非结构化数据，提供强大的数据管理和分发能力，而文件系统和块存储则更适合需要低延迟、高性能存储的结构化数据处理。
注：对于部分喜欢自己折腾，想要自己搭建属于自己的对象存储的朋友，也是可以的，可以参考文章docker系列 搭建基于minio的私人COS平台，不过这种部署适合有公网IP的朋友(现在如果在国内部署还需要有备案域名)，可以使用有公网IP的云主机或者家庭宽带来自己搭建。
什么是R2？
R2 是CF提供的对象存储服务，目的在于提供高性价比的云存储解决方案，与其他传统云存储服务（如 Amazon S3）相比，具有以下优势：
- 无出口费用：R2 的一个显著优势是没有数据出口费用，这意味着用户从 R2 直接下载数据时不会被收费，这与其他存储服务形成了鲜明对比(比如Amazon S3和腾讯云COS)。
- S3 兼容性：R2 完全兼容 Amazon S3 的 API，因此用户可以轻松迁移现有的 S3数据到 R2，而不需要修改代码。
- 与CF的网络集成：R2 与CF的全球边缘网络紧密集成，能够提供快速的数据访问速度和低延迟，特别是当与CF的其他服务(如 Workers 或 CDN)结合使用时。
- 低成本：R2 的存储成本相对较低，特别是对大量访问频繁的静态内容非常有吸引力。
不过，R2并非免费服务(所以前面才说是"高性价比")，其只是提供了一个免费额度：
• 存储：10 GB的免费存储空间。
• Class A 操作：100万次/月免费操作。这类操作包括PUT、POST、COPY、DELETE等。
• Class B 操作：1000万次/月免费操作。这类操作包括GET、HEAD、OPTIONS等。
• 出站流量：10 GB的免费出站流量。
只不过，这个免费额度对个人站长而言完全足够了，比如我博客图床8月1日-8月14日数据为例：
图片总共才430兆(从去年8月底我开始学习搭建个人博客以来，到现在刚好1年的量)，按这个速度，要用完10g免费存储空间还要努力20多年；A类操作2000，B类操作10万，分别离100万和1000万的免费额度上限还有"亿"点点距离；至于出站流量10G，这是为了覆盖少量特殊场合，正常情况下通过CF网络路由的流量是免费的(况且一般内容都还要先经过免费CDN的加持)，所以绝大多数正常使用都不会产生出站流量。
因此，对于个人站长来说，"R2是免费的对象存储"这种说法也是说得过去的吧(把白嫖进行到底!)？
注：开通R2需要绑定一个可用的国际通用型信用卡(毕竟不是"真"免费服务，可以理解)，如Visa、Mastercard、American Express、Discover 等，这算是使用R2的唯一门槛。
为什么CF将对象存储服务取名为R2呢？因为八卦所以研究了一下，以下是2种可能的原因，真实性不可考：
1、向流行文化致敬
这个名字可能参考了《星球大战》中的机器人角色 R2-D2。R2-D2 是一个非常受欢迎的角色，以其可靠性和重要性著称。CF可能用这个名称来暗示他们的存储服务同样可靠且在整个网络中发挥着重要作用。此外，R2 这个名称简洁且易于记忆，也符合CF产品命名的风格。
2、对标Amazon S3
CF将对象存储服务命名为 “R2”，可能是在与 Amazon S3 进行某种联系或对比(此怀疑灵感来自于F5和A10)：
• 字母和数字命名的延续：Amazon S3 是一种广泛使用的对象存储服务，名称中的 “S3” 代表 “Simple Storage Service”。CF选择 “R2” 这一名称，可能是在延续类似的命名模式，但又保持独特性和品牌识别度。
• 竞争与对比：R2 不仅在名称上与 S3 类似，功能上也与 S3 兼容，且强调没有数据出口费用，这使得 R2 成为 S3 的直接竞争对手。因此，取名为 “R2” 可能也是一种巧妙的方式，暗示它与 S3 类似，但提供了差异化的优势。
打造基于R2的图床
R2图床使用教程(乞丐版)
依照以下步骤可以不依赖于其他工具手动上传图片到R2并生成一个https类型的图片链接。
第一步，创建一个存储桶：
上图红框中的URL也可以直接写成
https://demo.tangwudi.com/孙悟空.jpg，因为孙悟空.jpg是直接上传到桶的"根目录"里(打引号是因为所谓"目录"都只是障眼法而已)。
然后依次处理其他需要的图片，最后把各自图片的URL转化成需要的格式插入文章中的指定位置即可。
注：所以如果存储桶里有"目录"，上面链接的格式会相应的转变，例如，将孙悟空.jpg放在文件夹"1"中，然后直接上传"1"这个文件夹，那么上面的链接会变为：https://demo.tangwudi.com/1/孙悟空.jpg，这个也是图床迁移时候的一个重点，只要原来图床保存图片及输出URL的方式也是/目录1/目录2/···/xxx.png这个格式，都可以直接迁移到R2上(当然，也可以迁移到其他厂商的对象存储服务上)。
这方式是R2最基本的使用方式，用倒是可以用，但是一般很少有人这么用(除非偶尔简单的上传几张图片获取个URL)，因为这需要先截图保存到本地，然后从本地上传图片到R2上，接下来在R2上生成图片链接，最后再将图片链接转换成需要的格式插入到本地的文章中。。。折腾不折腾？
R2图床使用教程(常规版)
常规使用R2图床的的方法，是使用常用编辑器(obsidian或者Typora)+PicGo(图片上传工具)配合R2来快速实现常规的图片上传及图片地址获取操作，以截图并在文章中粘贴我博客的首页为例：
第1步，使用截图软件截取截图：
第2步，在文章中需要图片的位置粘贴，这是会有提示框提示：
出现该提示是因为我在Picgo里启用了时间戳重命名功能，这里不细说，直接点红框中的确定。
第3步：然后前面的截图就出现在文章中的指定位置并自动生成了对应格式的地址(此处是markdown格式地址)，如下图：
也就是说，直接截图，然后在常用编辑器撰写的文章中需要图片的位置进行粘贴，点确认，就可以直接通过Picgo的S3插件完成图片到R2的上传，并根据Picgo的图片格式设置(Markdown、HTML、URL、UBB、定制)在文章对应的位置生成特定格式的图片地址格式，这种方式和上一种R2图床的使用方式比起来，就高效很多了(所以我才称上一种方式为乞丐版)，而这种方式需要用到R2的API。
注：obsidian+Picgo的具体设置可以参考我之前的文章：奇技淫巧系列 chevereto+PicGo+Obsidian实现高效的图床图片上传及图片url获取，只不过我文章中是使用的图床是chevereto，所以PicGo使用的插件是对应chevereto的，图床换成R2的话，就把PicGo的插件换成S3就行了。
创建R2 API的流程如下：
我之前的文章中是使用的chevereto自建图床，所以Picgo的插件也是用的chevereto的上传插件，需要改成安装S3插件：
S3插件的设置参数按下图配置：
使用这种方式平时截图都直接上传到了R2图床上，也不错，只不过如果有一些其他要求，比如给图片加水印等，这种方式就没法了。
注：github上有个基于Picgo的二次开发软件"PICLIST"，说是支持对图片进行有损/无损压缩和变换格式，以及添加水印，不过我没用过，大家有兴趣可以试试。
R2使用教程(平滑迁移版)
因为我之前使用的chevereto自建图床，并习惯了给图片加水印的方式，所以即便我现在使用了R2作为我的主图床，也仍然希望图片上有我的水印，但是我又不想太折腾，简单来说，以前习惯用的obsidian、Picgo、chevereto的配置统统不想动，但是我又偏偏想使用R2做图床(就这么流氓)，可以吗？当然可以，这就是这部分内容的核心，适用于那些使用chevereto自建图床又想将主图床从chevereto平滑迁移至R2的朋友。
这个平滑迁移的核心是"Rclone"。Rclone是一个强大且灵活的命令行工具，主要用于管理和同步不同存储服务之间的文件和目录。它支持多种云存储服务、本地存储设备以及其他远程文件系统，允许用户轻松地在这些不同的存储位置之间复制、移动、同步文件和目录。
要完成chevereto图床到R2图床的平滑迁移，我们需要将chevereto图床本地目录里的图片使用Rclone全部复制到R2上，并在以后chevereto图床有更新内容之后，让Rclone以增量的方式快速将更新内容同步到R2上，其实这时候就有了2个图床，一个是chevereto，一个是R2，平时图片直接上传到chevereto图床里，再使用Rclone同步到R2图床上。
如果要让R2成为主图床，只需要将chevereto原本的域名让给R2作为自定义域名使用即可，这部分内容的详细操作流程在本文中不多说了，有兴趣的朋友可以参考文章：家庭数据中心系列 使用rclone和cloudflare R2打造chevereto的异地容灾图床。
使用R2的注意事项
需要再次强调的是：R2并非免费服务，只是其提供的免费额度对于绝大部分个人站长而言，正常使用的场景下基本相当于免费，所以为了规避使用风险，要注意以下几点：
1. 免费额度与超额费用
• CF R2 提供一定的免费使用额度（例如存储空间和请求次数），但一旦超出这些免费额度，用户就会开始产生费用。因此，监控使用量非常重要，避免意外超支(正常使用很安全，怕的就是不正常使用)。
2. 安全与访问控制
• 为了防止未经授权的访问或盗刷，确保你的 R2 存储桶配置了适当的访问控制策略：可以使用 CF Access、IP 限制、或自定义权限策略来限制谁可以访问你的存储桶和数据。
• 避免将 API 密钥或其他敏感信息暴露在公共仓库或代码库中，因为这可能会导致未经授权的访问。
其实R2的公开访问部分还有其他选项，比如"R2.dev子域"或者"CORS策略"等，只不过默认的选项在安全性方面没啥毛病且适合大部分人，所以我也没提，有特殊需求的朋友可以自行更改(不懂的朋友别去乱动了，比如R2.dev子域，默认是关闭，如果这个选项打开又被别人乱用，后果就有点严重了～～)，如下图：
3. 防止滥用
• 如果你的 R2 存储桶托管的是公开可访问的内容，考虑设置带宽限制或使用CF的其他防护机制（例如Rate Limiting、WAF）来防止恶意用户通过大量请求来恶意使用你的资源(一般的个人站长其实不用太操心这个，毕竟本来就没啥流量～)。
• 定期审查你的 R2 使用日志，以便快速识别和应对可疑活动。
4. 监控和告警
• 通过设置监控和告警系统，及时了解你的使用情况。例如，可以使用CF的分析工具或者第三方工具监控存储和请求的使用情况，设置告警阈值以便在接近免费额度时收到提醒。
5. 备份与数据恢复
• 尽管 R2 是一个可靠的存储服务，但定期备份关键数据仍然是一个好习惯，以防止数据丢失或不可预见的服务中断(所以说，其实平滑迁移版方案提供的chevereto和R2相配合的方式也算是变相备份了)
后话
其实，折腾所谓"平滑迁移版"方案，是因为我之前还不知道R2，而腾讯云的COS我又不敢用(怕图片被盗链浪费CDN流量)，所以之前考虑的问题是如何实现自建的chevereto多节点的容错机制(参见文章：家庭数据中心系列 chevereto图床多节点定时自动同步教程)；而之所以考虑chevereto多节点的容错机制，是因为想解决"家庭数据中心"出问题时候(家里断电、断网)时wordpress切换到腾讯云轻量服务器上(参见文章：家庭数据中心系列 活用cloudflare tunnel实现wordpress主站点故障时灾备站点自动接管)时图床不可用的问题(毕竟主图床也在"家庭数据中心")。
而后来知道了R2，开始是觉得可以将其作为"家庭数据中心"故障时的容灾团床，不过后来用爽了之后，就成了主图床。。。。如果我一早就知道R2(关键是知道可以白嫖)，就不会这么瞎折腾了，绕了一大圈弯路：直接将R2作为主图床，不管我是想用多个wordpress站点做故障冗余(参见文章：家庭数据中心系列 活用cloudflare tunnel实现wordpress主站点故障时灾备站点自动接管)，或者用多个wordpress站点做流量负载均衡(参见文章：家庭数据中心系列 活用cloueflare tunnel为动态博客搭建流量负载均衡的多活冗余站点)，都可以使用一致的图床地址，根本就不会为故障时图床是否可用而操心了。
注1：Backblaze B2的对象存储服务其实也和CF R2差不多，也是免费10G存储空间，而且由于Backblaze和CF同属于"带宽联盟"(Bandwidth Alliance)，所以Backblaze B2存储与CF的 CDN 服务之间的出站流量在联盟内是免费的，这意味着如果使用 Backblaze B2 存储并通过CF CDN 分发内容，同样无需支付出站流量费用。而Backblaze B2有个最大的优势：无需绑定信用卡！所以如果因为信用卡问题无法使用CF R2的朋友，可以使用Backblaze B2作为替代方案，效果是一样的。
注2：一般情况下，R2图床都是搭配CF的常规CDN(Cache Rules或者页面规则)，打开速度嘛，差强人意，一般还是需要转2-3个圈，也可以接受。不过其实也有优化的办法，就是我在CF系列教程(七)中的worker优化大法，采用文章最后针对静态内容优化的代码来实现对图床里图片加载速度的加速，不过嘛，这种方式要受Free计划中worker每天10万次请求的限制，如果访问人数多的话，额度可能被消耗完(毕竟一篇文章有可能十多二十张图片，优化的时候对worker请求的消耗速度比一篇文章而言快了十多二十倍)，所以访问量大且图片多的站点要慎重使用这种方式。
注3：除了用作图床之外，R2当然也能用作其他用途，比如：存储音频、视频或者其他任何格式的文件(反正免费存储空间就10G，用完拉倒～)，然后配合CDN来使用。不过，虽说基本免费，但是大家也要注意一个度，CDN流量过大超过了个人使用的正常范畴，封号也不是不可能(比如来个几百T的CDN流量～)。
