一年前，我们推出了 Cache Rules，这是一种在 Cloudflare 上自定义缓存设置的新方法。Cache Rules 为用户缓存内容的方式提供了更大的灵活性，提供了精确的控制、用户友好的 API 和无缝 Terraform 集成。自 2022 年 9 月底发布以来，已有超过 10 万个网站使用 Cache Rules 来微调缓存设置。
今天，我们很高兴地宣布，Cache Rules 以及其他几种规则产品已普遍可用 (GA)。但这还不是全部——我们还为 Cache Rules 引入了新的配置选项，提供了更多选项来自定义您在 Cloudflare 上的缓存方式。其中包括定义哪些资源可以使用 Cache Reserve、从源服务器接收数据时应遵守哪些超时值、缓存内容时应使用哪些自定义端口，以及在没有 cache-control 标头的情况下是否应绕过 Cloudflare 的缓存。
Cache Rules 为用户提供了完全的控制能力，使其无需编写代码即可针对几乎任何用例定制内容交付策略。随着 Cache Rules 普遍可用，我们非常期待能够看到客户快速实现其完美的缓存策略。
Cloudflare 自定义缓存的历史
Cloudflare 上的缓存定制之旅始于十多年前，也就是公司成立之初。从一开始，我们的客户最常见的要求之一就是简化他们的配置。客户希望为其网站上的任何页面轻松实施精确的缓存策略、应用强大的安全措施、操作标头、设置重定向等。使用 Cloudflare 设置这些控制对于使用源服务器的客户尤其重要，因为这些服务器仅提供复杂的配置选项来向响应添加标头或策略，而 CDN 随后会将其应用到下游。
为了满足这一需求，我们推出了 Page Rules，自推出以来，该产品的受欢迎程度和功能都取得了显着的增长。对于寻求对 Cloudflare 缓存内容方式进行精细控制的客户来说，Page Rules 成为首选。目前，有超过 500 万条与缓存相关的活动 Page Rules，可帮助网站定制其内容交付策略。
然而，在幕后，Page Rules 遇到了可扩展性问题。
每当 Cloudflare 遇到一个 Page Rule 时，我们必须将客户的所有规则条件转换为单个正则表达式模式。然后将此模式应用于对网站的请求以实现所需的缓存配置。当考虑如何将来自所有客户的所有正则表达式与跨越全球 300 多个数据中心的每秒数千万个请求进行比较时，很容易看出应用 Page Rules 的计算需求可能是巨大的。这种压力与我们能够为用户提供的规则数量直接相关。例如，Page Rules 仅允许在给定网站上部署 125 条规则。
为了应对这一挑战，我们在新的规则集引擎上重建了所有 Page Rule 功能。基于规则集引擎的产品不仅为用户提供了更多可以使用的规则，而且还为这些规则的运行时间提供了更大的灵活性。规则集引擎的神奇之处在于，规则逻辑可以根据条件进行评估，而不是将页面的所有规则组合到单个正则表达式中。例如，如果子域 A 和 B 具有不同的缓存策略，则可以使用特定于 A 的正则表达式逻辑来评估来自子域 A 的请求（同时忽略适用于 B 的任何逻辑）。这将大大提高性能，并减少了跨 Cloudflare 网络应用 Page Rules 的计算需求。
在过去的一年里，Cache Rules、Origin Rules、Configuration Rules 和 Single Redirect Rules 一直处于测试阶段。感谢早期采用者的宝贵支持，我们成功地对我们的产品进行了微调，达到了从测试版过渡到正式版的阶段。这些产品现在能够完成 Page Rules 可以完成的所有任务，甚至更多。这也标志着 Page Rules EOL 流程的开始。在接下来的几个月中，我们将公布有关客户如何使用特定规则产品替换其 Page Rules 的时间表和信息。我们将尽可能自动化此过程，并提供简单的步骤，以确保每个人都能从 Page Rules 顺利迁移。
如何使用 Cache Rules 以及新功能推出
使用过 Cache Rules 的人都知道，它们很直观，并且与我们的其他规则集引擎产品类似。评估用户定义的条件（例如 URL 或请求标头），如果匹配指定值，则遵守 Cloudflare 缓存配置。每个 Cache Rule 都取决于字段、运算符和值。如需所有可用的不同选项，请查看我们的 Cache Rules 文档。
以下是如何部署不同策略来自定义缓存的两个示例。这些示例仅展示了 Cache Rules 的冰山一角，因此我们鼓励您尝试这些规则，并告知我们您的看法。
示例：缓存内容定期更新
举个例子，假设 Acme Corp 想要更新他们的缓存策略。他们希望自定义缓存以利用某些请求标头，并使用这些请求标头的存在作为决定何时应用不同缓存规则的条件。他们需要决定的第一件事是应该使用哪些信息来触发特定规则。这是在表达式中定义的。
定义触发标准后，Acme Corp 接下来就应该确定如何定制缓存。
内容快速更改
最常见的缓存策略是更新边缘缓存 TTL。如果 Acme Corp 认为其网站上的特定内容可能会快速更改，他们可以将 Cloudflare 认为有资格从缓存提供服务的资源的时间缩短。这样，Cloudflare 就会更频繁地返回来源以重新验证和更新内容。在边缘缓存 TTL 部分，Acme Corp 还可以根据 Cloudflare 从其来源返回的状态代码定义资源的 TTL，以及在 Acme 源服务器没有发送任何缓存控制指令的情况下 Cloudflare 应缓存的内容。
内容更改缓慢
另一方面，如果 Acme Corp 有很多不经常更改的内容（例如网站图标或徽标），并且他们更愿意从 Cloudflare 的缓存而不是其来源提供这些内容，那么他们可以使用新的 Cache Rule 来定义哪些内容有资格从 Cache Reserve 提供。Cache Reserve 通过将资产长期存储在 Cloudflare 的缓存中来降低出口费用。
传统上，当用户启用 Cache Reserve 时，他们的整个区域将有资格写入 Cache Reserve。对于希望节省其网站上所有资源的来源出口费用的客户来说，这仍然是最佳选择。但是，对于希望精确控制哪些资产应成为其 Cache Reserve 的一部分，甚至哪些规模的资产应符合条件的客户来说，Cache Reserve 资格规则提供了额外的选项，使客户可以精确地增加其缓存命中率，并以定制的方式减少来源出口。请注意，该规则要求 Cache Reserve 订阅。
示例：源站速度缓慢
让我们考虑一个假设的例子。最近，Acme Corp 发现其 Cloudflare 日志中的错误有所增加。这些错误与 Acme 根据其专有数据向用户提供的新报告有关。该报告要求其来源访问多个数据库，执行一些计算并根据这些计算生成报告。生成此报告的来源需要等到所有这些背景工作完成才能做出响应。Acme 的报告非常成功，吸引了大量游客前来观看。但他们的来源却在奋力追赶。他们看到许多 524 错误，表明 Cloudflare 并未看到来源响应，直到超时。
Acme 计划通过扩展其来源基础设施来改进这一点，但部署需要很长时间。与此同时，他们可以求助于 Cache Rules 来配置更长的超时。一直以来，Cloudflare 与两次连续来源读取之间的超时值为 100 秒，这意味着如果来源在超过 100 秒的时间内未成功发送响应，则可能会导致 524 错误。通过使用 Cache Rule 来延长此超时，Acme Corp 可以更加依赖 Cloudflare 的缓存。
上述缓存策略重点关注来源上资源更改的频率以及来源的性能。但还有许多其他规则允许其他策略，例如自定义缓存键（允许客户确定如何在 Cloudflare 上定义其缓存）、遵守强 ETag（帮助客户确定 Cloudflare 何时应重新验证特定缓存资产）以及自定义端口（允许客户定义 Cloudflare 在做出有关内容的缓存决策时应使用的非标准端口）。
可在此处找到 Cache Rules 的完整列表。
立即试用 Cache Rules 吧！
我们将继续构建和发布更多规则，为使用 Cloudflare 缓存的任何人提供强大、易于启用的控制。如果您有其他 Cache Rules 功能请求，请在 Cloudflare 社区告诉我们。
立即前往仪表板并试用 Cache Rules 吧！