Summary

  • Fastly 更像应用交付与安全的边缘控制面，而不只是内容副本网络。
  • 缓存、Compute、WAF、DDoS、bot、metrics 和 logging 越靠近用户，错误规则的影响范围也越大。
  • 可靠性取决于缓存正确性、purge 纪律、边缘代码审查、安全误报处理、日志可用性和团队所有权。
  • BTW 目录中的 APNIC 背景只是身份与资源治理线索，不证明 Fastly 的性能、路由 footprint 或 ISP/transit/registry 身份。

速度首先改变职责边界

Fastly 在官网上把自己描述为可编程边缘云平台，强调构建、保护和交付数字体验。页面提到 fully programmable platform、实时更新、较少但更强的 POP，以及对 DDoS、bots 和其他威胁的保护。这些是公司对产品面的描述，不是独立性能测量。

关键变化在于，请求路径上的第一层可编程系统开始承担应用职责。Fastly 的 CDN 页面把内容交付、可编程控制和安全能力放在同一层。对开发者和 SRE 来说，这意味着重定向、缓存、后端选择、安全过滤、日志和指标都可能不再只由源站决定。

这可以减少源站工作，也会制造新的运营债务。谁能修改边缘规则？谁审批全局清除？谁知道某个 header 是否影响缓存？谁在 bot 规则误伤客户时负责放行？谁解释源站日志没有记录、但用户已经被边缘拒绝的请求？如果这些问题没有答案，速度只是把复杂性放到更难追踪的位置。

缓存是数据边界

Fastly 的缓存文档说明，边缘缓存分布在平台网络中，并且 VCL 和 Compute 服务在向 backend 发起请求时默认使用 readthrough 接口。也就是说，缓存不是透明存储，而是应用语义的一部分。

缓存键决定哪些请求被认为等价。语言、货币、设备、登录状态、tenant、国家、实验组、query 参数和特定 header 都可能改变响应含义。忽略重要维度可能把错误内容给到用户；纳入过多噪声维度又会碎片化缓存，让源站承受本应被边缘吸收的流量。

Purge 同样是生产操作。精确清除修复陈旧对象；过宽清除会让大量 miss 同时回源；遗漏清除会留下旧内容。成熟流程需要清除范围、操作者、理由、影响预估、幂等重试、源站容量检查和事后证据。清除按钮不是编辑工具那么简单，它也是容量控制器。

Compute 是第二套软件交付面

Fastly 的 Edge Compute 把边缘描述为 serverless 开发平台，Fastly 的 Compute 文档提供开发指南和 Rust、JavaScript、Go 等 starter kits。这说明 Fastly 提供的是实际编程面，而不仅是配置表。

适合放在边缘的通常是请求本地、执行时间可控、失败行为清晰的逻辑：URL 规范化、轻量重定向、后端选择、格式协商、简单 header 处理。复杂授权、交易状态、多服务组合和强一致数据更适合留在源站或拥有完整上下文的服务里。

一段很短的边缘代码也可能制造大范围故障：重定向循环、缓存碎片、错误后端、重复 retry、安全绕过或隐藏源站异常。因此边缘代码需要版本控制、同行审查、自动测试、灰度发布、日志版本字段和可演练回滚。能快速发布，不等于能安全修改。

安全规则需要业务语义

Fastly 的 App & API Protection 把 WAF 和 API 防护放在应用之前。DDoS Protection页面称其全球网络截至 2026 年 3 月 31 日提供 578 Tbps，并能吸收网络层攻击、丢弃无关非 HTTP/HTTPS 流量。这个数字应视为公司声明，不应当作某个客户部署可用性的独立证明。

安全越靠前，误判也越靠近用户。WAF 规则可能拒绝真实 API 请求；rate limit 可能惩罚共享网络或合作伙伴；DDoS runbook 如果没有覆盖源站直连、DNS、证书和高成本动态端点，就不能只靠总体容量解决问题。

Bot Management页面列出 credential stuffing、account takeover、scraping、inventory abuse、application-layer DDoS 和 business logic abuse。问题在于，并非所有自动化都应该被封禁。搜索、监控、辅助工具、合作伙伴任务和客户脚本都可能是合法自动化。团队需要分级动作、分类理由、误报复核、例外到期和客服升级路径。

指标与日志是证据系统

Fastly 的 Metrics页面强调从两端获取更完整的性能图景。Logging页面强调实时日志。它们重要，因为边缘缓存命中、拒绝、重定向和安全决策可能永远不会进入源站日志。

但实时不等于可解释。日志需要请求 ID、缓存结果、后端选择、服务版本、响应状态、时延、安全动作和足够上下文，同时要避免泄露敏感数据。日志管道可能延迟、丢失、采样、schema 漂移或成本过高。指标也会误导：全局命中率上升可能掩盖关键 API 回源；源站流量下降可能是缓存成功，也可能是用户被误挡。

可观测性要回答具体问题：哪个版本处理了请求？为什么回源？哪条规则阻断？哪个 region 受影响？日志是否完整？没有这些，dashboard 只是延迟的装饰。

源站仍然存在

Fastly 成功时可以减少重复源站工作，但源站仍处理未缓存请求、写入、认证、个性化 API、冷缓存、purge 后填充和直接暴露路径。失效策略还要决定源站慢时是否服务 stale、是否 retry、是否降级、是否返回错误。不同对象的正确答案不同。

严肃评估应测试缓存键碰撞、缓存碎片、过宽 purge、源站变慢、backend 不可用、WAF 误报、合法 bot 被挡、日志延迟、metrics 缺失和 rollback。替代方案也不只是供应商名单：Cloudflare、Akamai、Amazon CloudFront、hyperscaler CDN、自建 reverse proxy、源站扩容、专项安全工具，或者减少边缘动态逻辑，都是职责分配方式。

目录记录的边界必须清楚

BTW 的 Fastly 目录页把 Fastly, Inc 放在 APNIC 会员和 number-resource governance 的亚太背景中。这个记录有助于实体识别，但不证明 Fastly 提供 ISP、IP transit、registry、managed-network 服务，也不证明路由质量、产品性能或客户流量。任何这类判断都需要 ASN、prefix、路由、合同和实测证据。

Fastly 最有价值的地方，是让团队把合适的工作放到请求入口。最危险的地方，也是让团队把不清楚的工作放到请求入口。可靠部署不是边缘逻辑最多的部署，而是每个边缘决策都有理由、所有者、证据和退路的部署。