#运维#优化 注意：以下所有统计数据和数字仅在撰写本文时为真，并且肯定会随着时间的推移而变化。
在主要由捐赠资助的同时运营一个广受欢迎的网站和资产资源一直是 Poly Haven 的核心挑战。
在 Amazon S3 上扔一堆文件并收工很容易，但你会积累一大堆你根本付不起的账单。
仅从 S3 提供 80TB 带宽，估计每月花费大约 4,000 美元，巧合的是，这与目前在Patreon上捐赠给我们的金额大致相同。
这显然使实际创建资产的预算为零，更不用说我们所有的其他成本了。
那么，我们到底是如何以不到 400 美元的价格运营一个每月拥有 500 万次浏览量和 80 TB 流量的网站的呢？
Cloudflare 一路走来
这个网络巨头可能是我们可以如此轻松且经济地做我们所做的事情的原因。当然，没有它们我们也可以生活，但工作量要大得多。
Cloudflare对我们来说主要是一个巨大的缓存层。
这意味着什么？例如，当伦敦的某人下载一个文件时，该文件是从我们的原始服务器获取的（稍后会详细介绍），但会通过 Cloudflare 附近的一个边缘节点进行路由。
然后，下次伦敦有人下载相同的文件时，Cloudflare 会将其缓存并直接提供给他们，而无需打扰我们的源服务器。
我们可以使用一组规则定义特定文件或 URL 应缓存多长时间，以便很少更改的内容（如资产文件）可以尽可能长时间地保持缓存，而每天都在更改的内容（例如我们的资产列表) 更新更频繁。
对于资产下载，这些缓存下载约占所有流量的 85%。
缓存（橙色）与未缓存的资产下载
然而，这不仅适用于文件下载，也适用于网站上的所有其他内容。
每次加载页面时，浏览器都会发送几十个请求（想想样式表、javascript、json 数据……），其中大部分是静态的。
由于 Argo（我将在下面解释），Cloudflare 可以缓存这种流量，甚至比巨大的资产文件更好，导致大约93% 的缓存率。
polyhaven.com 的流量（不包括资产下载和图像请求）
所有这一切意味着我们的原始服务器要做的工作要少得多，这意味着它们在理论上更实惠。
这个惊人的缓存层让我们付出了多少代价？
每月 40 美元。
Cloudflare 的 Pro 会员费用为每个域 20 美元，我们有两个域：用于主网站的 polyhaven.com 和用于资产下载的 polyhaven.org。
Backblaze 带宽联盟
所以在 Cloudflare 之后，我们只需要处理每月 80TB 流量中的大约 15%。不过，这仍然不算什么，使用 Amazon S3 将花费我们大约 650 美元。
不过，S3 并不是游戏中唯一的参与者，还有其他预算更友好的云提供商。
我们使用的是Backblaze——另一家以消费者备份服务而闻名的互联网巨头。
Backblaze 的 S3 服务的 B2 克隆将花费我们每月大约 130 美元，而 Cloudflare 无法处理最后 15%。
但是，由于 Backblaze 和 Cloudflare 之间的合作关系，我们可以解决这个问题，他们称之为带宽联盟。
只要我们同时使用这两种服务，并支付 20 美元的 cloudflare 订阅费用，我们就完全不需要为下载流量付费。
我们只需要支付存储费、一些上传费用和 API 请求，每月大约11 美元。
网络服务器”
因此，这涵盖了迄今为止我们托管资产文件本身的所有成本，但我们仍然需要一个网站来展示它们。
polyhaven.com是用 Next.js 构建的——一个由 Vercel 创建的 javascript 框架。
虽然您绝对可以在自己的服务器或六家其他云提供商上运行 Next.js 应用程序，但Vercel提供了一种相当直接且价格合理的服务，可以直接使用它们部署您的 Web 应用程序。
这为我们节省了管理自己的服务器的麻烦，同时具有成为无服务器环境的额外好处，可以提高世界各地用户的性能。
他们的基本费用是每月 20 美元，并根据使用情况收取额外费用。
由于我们在 Vercel 之前使用 Cloudflare，并且非常小心哪些可以缓存哪些不能缓存（例如，任何需要用户身份验证的内容），我们通常不会超过包含的使用限制，除非出现严重错误。
Vercel 无服务器函数执行时间（免费层为 1000 小时）
事实上，我们最近从 Vercel 获得了赞助，所以他们现在无论如何都承担了我们的费用，但为了这篇文章，我们假装必须为此付费
数据库
肯定是任何内容网站的重要组成部分——这是我们存储每个资产的所有信息、每个文件的每个文件列表、下载日志等的地方。
当我们仍然单独运行 hdrihaven.com 和其他站点时，所有这些站点都在它们自己的手动管理的LAMP 堆栈上，数据库首先开始遭受性能问题的困扰。
为了避免将来出现这个问题，我决定花点钱购买一个云解决方案，让我不必再担心可靠性、性能、可扩展性或完整性：Google Firestore。
这当然不是最便宜的选择，每月大约 100 美元，约占我们每月网络预算的一半，但我仍然认为这是正确的选择。
Firestore 每天的使用量
使用 Firestore，您可以按超出免费层级的使用量付费。对我们来说，这主要是数据库读取（上面的蓝线）。
每次从数据库中获取一点数据时，我们都会支付少量费用。每次阅读它实际上微不足道，为 0.0000006 美元。但是将其乘以每次页面浏览必须阅读的文档数量（例如，在我们的图书馆页面上，每个资产读取一次，目前为 866），乘以页面浏览量（每月约 500 万），它可以得到非常昂贵非常快。
为了尽可能避免数据库读取，我们尽可能多地缓存。我们的数据不会经常变化，或者当它发生变化时（例如下载次数），无论如何向用户显示最新信息并不是很重要。Cloudflare 一路走来
我们的 API
为了让我们最大程度地控制缓存数据库读取，并避免在 Vercel 中增加账单，我们在Vultr上有一个单独的5 美元服务器（是的，真的）运行我们的 API。
此 API 的目的是将我们的前端网站（在 Vercel 上）连接到我们的数据库。这就是它所做的一切。
而且由于我们对所有内容进行了大量缓存（为了降低数据库成本），API 服务器可能非常基础。
API 服务器使用情况
这台服务器需要很长时间才能满足我们的需求，在此之前，将服务器快照迁移到更强大的服务器或者更有可能负载平衡的服务器网络将是微不足道的。
阿尔戈
我们的数据库和 API 成本如此之低（相对于没有 Cloudflare 的成本）的主要原因之一是缓存率极高，高达 93%。
这是一个直接的影响——我们可以让 Cloudflare 缓存的越多，我们的 API 从数据库本身获取内容的频率就越低，我们的使用成本就越低。
Argo 是 Cloudflare 的一项可选额外服务，它执行两件事：
- 优化 DNS 路由以改善延迟（这有助于我们的网站让用户感觉更快）。
- 在缓存中添加了一个额外的层，因此所有全球流量只通过少数几个最大的数据中心，然后分裂到数百个边缘节点。
这第二点是我们关心的。
使用我们之前的示例：使用 Argo，如果伦敦的某人首先下载了一个文件，Cloudflare 现在不仅会为伦敦缓存该文件，还会为整个西欧缓存该文件。
这会导致更高的缓存率（使用我们的配置从约 75% 到 93%），但需要付出代价：您现在需要为通过 Argo 网络的每 GB流量付费。
这就是为什么我们有单独的 .com 和 .org 域的原因——我们在 .com 域上启用了 Argo，它以相对较低的带宽运行网站，然后我们在 .org 域上禁用了 Argo，它为 80TB 的下载流量提供服务。
Argo目前每月花费我们大约 160 美元，是迄今为止最大的单笔费用。但请记住，它为我们节省了一大笔数据库使用费，根据我大约 250 美元的餐巾纸计算。
此外，我们还获得了改进延迟、减少 API 服务器负载和减少 Vercel 使用的好处。
图片托管
最后，拼图的最后一块大部分与其他所有内容分开。
我们在网站上显示的所有图像（缩略图、渲染、预览等）都存储在Bunny.net - 另一个预算 CDN 上。
Bunny.net 不仅存储我们的图像，它们还提供优化服务，允许我们为网站动态调整图像大小和压缩图像。这极大地改善了用户体验（更快的页面加载）和我们自己的工作流程（我们只需要上传一个 PNG，它可以以任何大小和格式使用）。
这需要我们每月花费大约 27 美元，具体取决于流量。
Bunny.net 使用情况
全部的
- DNS、缓存和出口：Cloudflare（2 个域） —— 40 美元
- 缓存：Cloudflare (Argo) – 160 美元
- 资产存储：Backblaze B2 – 11 美元
- 网络托管：Vercel – 20 美元
- 数据库：Firestore – 100 美元
- API：Vultr – 5 美元
- 图片托管和优化：Bunny.net – 27 美元
- 域：Cloudflare – 4 美元
- 电子邮件费用：MXroute – 3 美元
这使总额达到约 370 美元。
其中很多成本是基于我们对这些服务的使用，而这些服务直接受到网站流量的影响。
这些成本可能会随着我们的增长而增长，这很好。如果您在遥远的将来读到这篇文章，只需看看我们的公共财政报告，看看事情发生了怎样的变化
哦，关于那些财务报告，“虚拟主机”类别略高于 370 美元，因为它包括我们用来协助管理团队和上传资产的一些其他服务器和服务——这些与运行 polyhaven 并不严格相关.com 网站本身，而是 Poly Haven 公司。
未来的想法和突发事件
我们的基础设施是故意非常模块化的，因此我们不会过于依赖任何服务。如果必须的话，甚至 Cloudflare 也可以被替换。
我们的 API 服务器目前是我们最薄弱的单点故障——我没有任何运行公共 API 的经验。我们希望允许其他人依赖 API 将我们的资产与他们的软件集成，因此这个领域需要一些研究和改进。
Google Firebase 很好也很方便，但是很贵。我们将来可以研究其他一些托管数据库选项。
Cloudflare + Backblaze 带宽联盟是我们最大的成本节约之一。如果这种情况在未来某个时候不复存在，我们的计划是建立我们自己的负载平衡专用服务器网络来处理流量。这听起来很可怕，但我们过去确实这样做过，而且效果很好。管理起来肯定很痛苦，但可能同样便宜。
希望这篇博文能回答你的一些问题，并帮助你找出你自己的项目所需的架构，或者至少读起来很有趣