摘要

  • Fastly会分别记录边缘未命中和shield命中，即使该次交付没有调用源站。汇总缓存命中率不等于被避免的源站请求比例。
  • Fastly POP之间的流量计入请求数量和计费带宽。供应商说明shield可能降低整体成本，但这不是对每个客户账单的实测保证。
  • 边缘命中的响应可能携带较早的shield缓存填充记录，而可缓存内容获取指标又有自己的统计范围。响应头和原始指标都不能自动变成账单。

一次交付，不止一次缓存判断

Fastly的shield概念说明描述了一个中间POP。接收请求的边缘缓存没有对象，便把请求转到shield；如果那里有对象，内容在Fastly网络内交付，不必调用源站。

同一文档说明，计算缓存命中率时，边缘未命中与shield命中都会被记录。真正到达源站的请求则留下两次未命中，分别对应边缘和shield。因此，一次用户交付与一个缓存统计事件不是同一种单位。

采购人员预期的命中率，可能因为多记录了一次判断而显得偏低，即使shield完成了期望的源站减负。这里不能反过来推论命中率越低越好。缓存键、有效期或流量本身都可能有真实问题；源站请求减少也可能伴随成功交付减少。本文没有测量客户流量，只说明供应商公开的统计机制不允许一个数包办全部结论。

源站没有工作，CDN仍然可能工作

shield配置说明写明，进入shield的流量按常规流量计费，包括用于填充其他POP的流量。概念说明进一步把Fastly POP之间的传输纳入请求数量和计费带宽。

因此，边缘未命中、shield命中，可以同时意味着源站避免了一次调用，以及CDN内部仍承担一个计费环节。两句话并不矛盾。中间缓存改变了工作发生的位置，而不是让用户得到内容后所有网络传输都消失。

Fastly说明，新增带宽费用可能被源站带宽和服务器负载的节省抵消，在较现实场景中shield常会降低整体成本。这项可能性正是产品吸引力的一部分，但仍不是某客户的净成本证明。客户流量组合、CDN商业条件和源站商业条件都需要纳入比较。

文档中的极端情况，是所有请求都配置为PASS。因为大多数请求会在两个POP出现，请求数量和交付带宽接近翻倍。这不是一切客户总账单必然翻倍的规则，也不是同一活动被错误重复收费的证据。本文没有读取折扣、用量承诺、源站价格或实际传输量。

买方先要确定自己比较什么

若评分表只奖励缓存命中率上升，就可能因为shield多了一层统计判断而否定有用的源站减负。若只奖励源站调用减少，又可能遗漏CDN新增传输。两个评分表都可以准确读出数值，却错误解释购买结果。

更有用的验收应明确用户需求与时间窗口，分别说明源站和shield的请求，以及每个字节字段包含什么。响应内容字节不能因为也叫带宽，就自动扩成内容加响应头的总字节；请求数量也不能自动变成独立用户数量。

买方不必要求所有计数器同时下降。中间层的用途本来就是重新分配工作。重要的是团队能否说明重新分配为什么符合交付目的和经济目的，而不让一个有利指标填补另一个证据缺口。本文没有可报告的客户节省数值。

两个服务器名称，未必是这次请求的两次经过

概念说明还给出一个容易漏看的限制：启用shield后，X-Served-By、X-Cache-Hits和X-Cache可能包含多个POP条目。但如果当前请求在边缘命中，shield条目可能来自当初填充这个缓存对象的较早事件，并不说明当前请求又走了一遍shield。

把所有双条目响应都当成一次新的计费内部传输，就会用历史响应信息发明当前事件。响应头仍有诊断价值，前提是保留它的时间含义，而不是把每个条目直接列进账单。

X-Served-By参考说明同时提醒，缓存节点持续进入或退出服务，节点身份和中心代码可能被复用。生成时准确的名称，不应变成跨时间比较的永久资产身份。本文没有采集客户响应头，也没有探测任何客户CDN路径；讨论依据是公开规范。

HIT与MISS压缩了多种状态

X-Cache参考说明指出，PASS被显示为MISS，边缘生成的合成内容被显示为HIT，陈旧内容命中和后台重新验证命中也显示为HIT。多条目还可能来自shield、Next-gen WAF at Edge或重启处理逻辑。

因此，HIT不能无条件翻译成“当前请求取出了读者设想的那个已保存对象”。参考说明解释非MISS条目表示缓存满足、而非继续转发时，也保留了重启情况的例外。删去这些限制，会得到更简单的故事，却得不到更强的证据。

这里没有必要展开代码教程。商业含义是，响应头的表达方式不是合同里的收费单位。它帮助运营人员理解响应，但财务不能仅凭它就把每项记录相加，当作当前工作已独立证实。

原始指标并没有消除定义

Fastly的实时分析参考与历史统计参考把shield和源站活动分开。shield_fetches描述shielding中的POP间请求，带有cache_fetches的指标则限定为已完成、返回可缓存内容的获取请求，不能直接代表所有请求。

其他字段分别说明shield命中、未命中和请求、响应的内容或头部字节。它们可以帮助买方提出“工作发生在哪里”的问题，却不让所有字段互换含义，更不自动构成净成本结论。个案分析需要同一时间范围、同一定义，以及适用商业条件。

这并不是反对shield。它要求采购评估真正发生的变化：有用的内容交付，以及工作在系统中重新分配。边缘未命中、shield命中可以同时描述源站被减负、汇总命中率留下未命中，以及CDN内部传输仍需付费。成熟验收应该能够让这三件事同时成立。

来源