提升公共云区域的智能分层缓存
在2021年，我们推出了 [智能分层缓存](https://blog.cloudflare.com/tiered-cache-smart-topology)。这个想法是：对于您网站背后的每个源，Cloudflare 根据实时延迟选择最优的上层数据中心进行路由。只需翻动一个开关，我们就能找到从我们的网络到您的源的最快路径。
这个方案的运作前提是源 IP 地址固定不变，但公共云源通常不是。它们位于 anycast 或区域单播的前端后面，因此一个源 IP 可能在多个 Cloudflare 数据中心看起来同样“接近”，而延迟探测没有明确的参照。智能分层缓存以安全的方式处理这个问题：当没有明显的胜者时，它会退回到多个上层。这样不会出错，您只会失去单个最近层所带来的缓存效率。
智能分层缓存针对公共云区域的改进通过让您提供云区域提示来解决这个问题。借助这个提示，Cloudflare 可以将公共云源映射到正确的区域，并选择更好的主上层和备用上层，即使源 IP 本身看起来是 anycast 或模棱两可。
### 我们让最受欢迎的分层缓存拓扑更智能
自推出以来，智能分层缓存已成为 Cloudflare 客户中最受欢迎的分层缓存拓扑。它适用于所有计划，并且是免费的。
我们的许多工作都是为了不断改进智能分层缓存。随着时间的推移，我们已将智能分层缓存扩展到处理更多源架构，包括：
- **2024年11月**: [Smart Tiered Cache for R2](https://developers.cloudflare.com/changelog/post/2024-11-20-smart-tiered-cache-for-r2/): 我们让智能分层缓存能够自动选择最接近 R2 桶实际所在位置的上层，从而降低延迟，无需配置。
- **2025年1月**: [Smart Tiered Cache for Load Balancing](https://developers.cloudflare.com/changelog/post/2025-01-08-smart-tiered-cache-for-load-balancing/): 我们扩展了智能分层缓存，使其能够为整个负载均衡池选择单个最佳上层，因此池中的所有源共享相同的缓存，提高了命中率。
这些改进的共同目标是：**理解客户的源基础设施，并自动为该基础设施做出最佳选择。**
尽管我们已经改善了这个系统，但客户们仍然面临一个共同的烦恼：当源位于 anycast 或区域单播网络后面时，智能分层缓存无法工作，因为这种架构使我们无法知道源的位置。而且这并不是一个边缘案例。托管在公共云提供商上的源后面使用 anycast IP 的情况正在逐渐增加。
今天，我们正在弥补这个差距，涵盖 AWS、GCP、Azure 和 Oracle Cloud 上托管的源。
### 为什么 anycast 云源不同
智能分层缓存通过测量每个 Cloudflare 数据中心到源 IP 地址的延迟来工作。延迟最低的数据中心成为上层：所有缓存缺失的请求都通过它转发到您的源。在一个固定的单播 IP 地址上，集中处理缓存缺失请求，您能够获得更高的缓存命中率，更少的对源的连接，以及较低的拉取延迟。
这一做法在源有固定的、可可靠探测的单播 IP 地址时效果良好。
许多云服务提供商使用 [anycast](https://www.cloudflare.com/learning/cdn/glossary/anycast-network/) 或区域单播网络，为他们的负载均衡器、前端服务和区域入口点分配 IP。当我们探测这些 IP 时，源似乎与多个数据中心同时“接近”。这是因为该 IP 地址代表的是云提供商的前端，而不是单一的物理源位置。不同的 Cloudflare 数据中心可能会通过确切相同的 IP 地址到达不同的云边缘，然后提供商再通过他们的网络将请求传送到实际的后端。因此，智能分层缓存无法自信地选择一个最佳上层。
实际上，这可能会导致流量跨洲流动，增加一次额外的往返延迟。假设您的源位于新加坡，背后是来自云提供商的 anycast IP。由于 anycast 的工作方式，我们的芝加哥数据中心可能显示出对该 IP 的最低探测延迟。智能分层缓存就会选择芝加哥作为上层。这导致来自亚洲最终用户的请求先到达一个附近的 Cloudflare 数据中心，然后越过整个大陆，经过芝加哥再获取位于新加坡的源，跨越两次海洋。这种回头路增加了几百毫秒的延迟，且这是使用云托管源的客户一再报告的常见问题。
*回头路示例：流量被路由到芝加哥的上层，仅为从新加坡的源获取数据，导致不必要的跨洲往返。*
为了应对这种不必要的来回，智能分层缓存学会了通过物理约束检测 anycast 源：光速。我们测量来自世界各地多个检查点数据中心到源的探测延迟。如果两个检查点数据中心的总延迟比光纤中光速可物理传输的延迟更快，则该源可能是从多个位置响应，而不是一个单一位置。这就表明它是 anycast。
*通过比较来自多个 Cloudflare 数据中心的探测延迟，我们能检测 anycast 源。如果两条路径的延迟快于单一源位置的物理可能性，则该源很可能是从多个地方响应。*
当智能分层缓存检测到 anycast 源时，它会采取保守的姿态：不会把该 IP 固定到单个上层。相反，它退回到具有多个上层的分层缓存拓扑。尽管仍然可以实现分层缓存，但流量将分散到多个上层而不是一个上层，这意味着更多请求到达源。对于某些配置，这种做法是可以接受的。但如果您希望某个上层接近生活在公共云后面 anycast IP 的源，目前还没有好的选择——直到现在。
### 告诉我们区域
从 Cloudflare 仪表板中，前往 **缓存 > 分层缓存 > [源配置](https://dash.cloudflare.com/?to=/:account/:zone/caching/tiered-cache)**。找到您的源 IP，点击“设置区域提示”，并告诉我们云区域（例如，aws:us-east-1 或 gcp:europe-west1）。智能分层缓存将从此开始接管操作。请注意，在仪表板上，区域提示仅对我们侦测为 anycast 的源 IP 设置。
*在分层缓存页面中，前往源配置表，单击源 IP 旁的编辑图标以设置其区域提示。*
您可以逐一设置提示，也可以一次性批量编辑所有源 IP 的云区域。除了仪表板外，API 和 Terraform 也可用相同的配置，因此您可以将其集成到现有的基础设施即代码工作流中。
我们首批支持 AWS、GCP、Azure 和 Oracle Cloud，更多提供商即将推出。
### 智能分层缓存如何运作
每隔几小时，我们都会从每个受支持的云提供商获取最新的 IP 范围文件。这些文件将每个云区域映射到其当前的 IP 前缀集，因此当提供商添加、删除或重新分配子网时，我们会对此做出反应。
*智能分层缓存系统图*
我们将这些子网与我们的上层数据库进行匹配，该数据库通过每15分钟更新一次的实时延迟探测构建而成。对于每个云区域，每个匹配的子网根据其当前的上层分配贡献一个加权投票。信号最强的上层就成为该区域的主上层。主上层和备用上层始终来自不同的存在点（PoP），因此失去一个 PoP 不会导致两个上层同时失效。
有些区域缺乏足够的探测数据，例如，也许新区域的云提供商仍在部署中，或者该区域尚未有源 onboard 到 Cloudflare——所以没法进行投票。我们会退回到地理位置：选择我们 Tier 1 PoP 中最近的一个。随着源上线，探测数据的积累，区域将悄然从基于地理位置的猜测切换到基于真实数据的选项。
### 立即试用，接下来是什么
这意味着，选择您的缓存最佳区域的工作——不断探测、算法选择每个区域的最佳上层、地理回退、跨 PoP 的故障切换——都由我们来处理。您的工作就是选择区域提示。
如果您的 anycast 源位于公共云上，您可以立即启用此功能。在仪表板中，前往缓存 > 分层缓存 > [源配置](https://dash.cloudflare.com/?to=/:account/:zone/caching/tiered-cache)。找到您的源 IP，点击“设置区域提示”，并选择您的区域。
接下来，我们将扩展到更多提供商，并继续教导智能分层缓存识别更多源设置，自行选择正确的路径。如需了解更多有关分层缓存如何使您的服务受益的信息，请查看我们的 [分层缓存文档](https://developers.cloudflare.com/cache/how-to/tiered-cache/) 。
---
原文链接：[点击查看](https://blog.cloudflare.com/smart-tiered-cache-for-public-clouds/)
这个方案的运作前提是源 IP 地址固定不变，但公共云源通常不是。它们位于 anycast 或区域单播的前端后面，因此一个源 IP 可能在多个 Cloudflare 数据中心看起来同样“接近”，而延迟探测没有明确的参照。智能分层缓存以安全的方式处理这个问题：当没有明显的胜者时，它会退回到多个上层。这样不会出错，您只会失去单个最近层所带来的缓存效率。
智能分层缓存针对公共云区域的改进通过让您提供云区域提示来解决这个问题。借助这个提示，Cloudflare 可以将公共云源映射到正确的区域，并选择更好的主上层和备用上层，即使源 IP 本身看起来是 anycast 或模棱两可。
### 我们让最受欢迎的分层缓存拓扑更智能
自推出以来，智能分层缓存已成为 Cloudflare 客户中最受欢迎的分层缓存拓扑。它适用于所有计划，并且是免费的。
我们的许多工作都是为了不断改进智能分层缓存。随着时间的推移，我们已将智能分层缓存扩展到处理更多源架构，包括：
- **2024年11月**: [Smart Tiered Cache for R2](https://developers.cloudflare.com/changelog/post/2024-11-20-smart-tiered-cache-for-r2/): 我们让智能分层缓存能够自动选择最接近 R2 桶实际所在位置的上层，从而降低延迟，无需配置。
- **2025年1月**: [Smart Tiered Cache for Load Balancing](https://developers.cloudflare.com/changelog/post/2025-01-08-smart-tiered-cache-for-load-balancing/): 我们扩展了智能分层缓存，使其能够为整个负载均衡池选择单个最佳上层，因此池中的所有源共享相同的缓存，提高了命中率。
这些改进的共同目标是：**理解客户的源基础设施，并自动为该基础设施做出最佳选择。**
尽管我们已经改善了这个系统，但客户们仍然面临一个共同的烦恼：当源位于 anycast 或区域单播网络后面时，智能分层缓存无法工作，因为这种架构使我们无法知道源的位置。而且这并不是一个边缘案例。托管在公共云提供商上的源后面使用 anycast IP 的情况正在逐渐增加。
今天，我们正在弥补这个差距，涵盖 AWS、GCP、Azure 和 Oracle Cloud 上托管的源。
### 为什么 anycast 云源不同
智能分层缓存通过测量每个 Cloudflare 数据中心到源 IP 地址的延迟来工作。延迟最低的数据中心成为上层：所有缓存缺失的请求都通过它转发到您的源。在一个固定的单播 IP 地址上，集中处理缓存缺失请求，您能够获得更高的缓存命中率，更少的对源的连接，以及较低的拉取延迟。
这一做法在源有固定的、可可靠探测的单播 IP 地址时效果良好。
许多云服务提供商使用 [anycast](https://www.cloudflare.com/learning/cdn/glossary/anycast-network/) 或区域单播网络，为他们的负载均衡器、前端服务和区域入口点分配 IP。当我们探测这些 IP 时，源似乎与多个数据中心同时“接近”。这是因为该 IP 地址代表的是云提供商的前端，而不是单一的物理源位置。不同的 Cloudflare 数据中心可能会通过确切相同的 IP 地址到达不同的云边缘，然后提供商再通过他们的网络将请求传送到实际的后端。因此，智能分层缓存无法自信地选择一个最佳上层。
实际上，这可能会导致流量跨洲流动，增加一次额外的往返延迟。假设您的源位于新加坡，背后是来自云提供商的 anycast IP。由于 anycast 的工作方式，我们的芝加哥数据中心可能显示出对该 IP 的最低探测延迟。智能分层缓存就会选择芝加哥作为上层。这导致来自亚洲最终用户的请求先到达一个附近的 Cloudflare 数据中心，然后越过整个大陆，经过芝加哥再获取位于新加坡的源，跨越两次海洋。这种回头路增加了几百毫秒的延迟，且这是使用云托管源的客户一再报告的常见问题。
*回头路示例：流量被路由到芝加哥的上层，仅为从新加坡的源获取数据，导致不必要的跨洲往返。*
为了应对这种不必要的来回，智能分层缓存学会了通过物理约束检测 anycast 源：光速。我们测量来自世界各地多个检查点数据中心到源的探测延迟。如果两个检查点数据中心的总延迟比光纤中光速可物理传输的延迟更快，则该源可能是从多个位置响应，而不是一个单一位置。这就表明它是 anycast。
*通过比较来自多个 Cloudflare 数据中心的探测延迟，我们能检测 anycast 源。如果两条路径的延迟快于单一源位置的物理可能性，则该源很可能是从多个地方响应。*
当智能分层缓存检测到 anycast 源时，它会采取保守的姿态：不会把该 IP 固定到单个上层。相反，它退回到具有多个上层的分层缓存拓扑。尽管仍然可以实现分层缓存，但流量将分散到多个上层而不是一个上层，这意味着更多请求到达源。对于某些配置，这种做法是可以接受的。但如果您希望某个上层接近生活在公共云后面 anycast IP 的源，目前还没有好的选择——直到现在。
### 告诉我们区域
从 Cloudflare 仪表板中，前往 **缓存 > 分层缓存 > [源配置](https://dash.cloudflare.com/?to=/:account/:zone/caching/tiered-cache)**。找到您的源 IP，点击“设置区域提示”，并告诉我们云区域（例如，aws:us-east-1 或 gcp:europe-west1）。智能分层缓存将从此开始接管操作。请注意，在仪表板上，区域提示仅对我们侦测为 anycast 的源 IP 设置。
*在分层缓存页面中，前往源配置表，单击源 IP 旁的编辑图标以设置其区域提示。*
您可以逐一设置提示，也可以一次性批量编辑所有源 IP 的云区域。除了仪表板外，API 和 Terraform 也可用相同的配置，因此您可以将其集成到现有的基础设施即代码工作流中。
我们首批支持 AWS、GCP、Azure 和 Oracle Cloud，更多提供商即将推出。
### 智能分层缓存如何运作
每隔几小时，我们都会从每个受支持的云提供商获取最新的 IP 范围文件。这些文件将每个云区域映射到其当前的 IP 前缀集，因此当提供商添加、删除或重新分配子网时，我们会对此做出反应。
*智能分层缓存系统图*
我们将这些子网与我们的上层数据库进行匹配，该数据库通过每15分钟更新一次的实时延迟探测构建而成。对于每个云区域，每个匹配的子网根据其当前的上层分配贡献一个加权投票。信号最强的上层就成为该区域的主上层。主上层和备用上层始终来自不同的存在点（PoP），因此失去一个 PoP 不会导致两个上层同时失效。
有些区域缺乏足够的探测数据，例如，也许新区域的云提供商仍在部署中，或者该区域尚未有源 onboard 到 Cloudflare——所以没法进行投票。我们会退回到地理位置：选择我们 Tier 1 PoP 中最近的一个。随着源上线，探测数据的积累，区域将悄然从基于地理位置的猜测切换到基于真实数据的选项。
### 立即试用，接下来是什么
这意味着，选择您的缓存最佳区域的工作——不断探测、算法选择每个区域的最佳上层、地理回退、跨 PoP 的故障切换——都由我们来处理。您的工作就是选择区域提示。
如果您的 anycast 源位于公共云上，您可以立即启用此功能。在仪表板中，前往缓存 > 分层缓存 > [源配置](https://dash.cloudflare.com/?to=/:account/:zone/caching/tiered-cache)。找到您的源 IP，点击“设置区域提示”，并选择您的区域。
接下来，我们将扩展到更多提供商，并继续教导智能分层缓存识别更多源设置，自行选择正确的路径。如需了解更多有关分层缓存如何使您的服务受益的信息，请查看我们的 [分层缓存文档](https://developers.cloudflare.com/cache/how-to/tiered-cache/) 。
---
原文链接：[点击查看](https://blog.cloudflare.com/smart-tiered-cache-for-public-clouds/)
评论
暂无评论。