1 为什么方案里要单独谈「CDN 与 DNS 服务」
零售大促开始前，团队把订单 API 扩容到平日的 4 倍，数据库也完成了压力测试。活动开始后，部分顾客仍然打不开商品页，另一些顾客能看商品，却在提交订单时持续超时。应用服务器的 CPU 并没有打满。问题可能发生在请求到达应用之前：域名没有正确解析、客户端仍使用旧地址、边缘节点无法回源，或者订单响应被错误地当成公共内容缓存。
从顾客输入域名到订单服务处理请求，中间至少涉及名称解析、建立连接、TLS 握手、边缘处理和回源。DNS，即域名系统，帮助客户端把名称查成可连接的地址或继续查询的名称。CDN，即内容分发网络，把适合复用的内容放到靠近用户的边缘节点，也可能代理必须到源站处理的请求。这些环节影响用户看到的可用性，却不完全体现在订单进程的监控里。
本课使用 3 个示例域名：static.shop.example 提供图片和带版本号的脚本，www.shop.example 提供商城页面，api.shop.example 提供订单 API。它们属于同 1 家商店，但缓存策略、切换方式和故障后果不同。静态图片晚更新几分钟通常可以接受；订单创建重复执行、用户甲读到用户乙的订单，都不能接受。方案必须按业务语义划定边界。
这里的关键收益也不同。静态内容在边缘命中，可以减少传输距离和源站带宽；订单请求经过边缘代理，可能利用连接复用、入口防护和回源优化，但仍要付出到源站处理的时间。不能把静态图片的命中率直接当成订单 API 的加速效果，也不能因为部署了 CDN 就假定每个请求都能在附近完成。
DNS 在路径选择中提供入口线索，却不逐个转发 HTTP 请求。解析结果可能被递归解析器、操作系统和应用缓存；已经建立的连接也可能继续使用。因而修改记录不会让所有用户同时迁移。CDN 同样有独立的规则传播、内容缓存和源站连接状态。排查时若把这些状态统称为“缓存”，就很难判断该等哪段时间、改哪项配置。
订单系统谈可用性时，既要问应用能否返回成功，也要问顾客是否能找到正确入口、连到正确服务、得到属于自己的新鲜结果。DNS 与 CDN 的配置应和订单链路共同评审：谁管理域名，谁管理证书，谁批准缓存规则，谁能发起切换，切换以后用什么证据确认恢复。它们是业务入口的一部分，也需要变更记录和明确负责人。
设计的起点是给每类流量写下约束。图片追求高命中和可长期复用；商品公开信息允许受控陈旧；库存、结算金额和订单状态要求按接口定义处理；创建订单要求鉴权、幂等和可追踪。先写清这些约束，再选择解析记录、缓存时间和回源方式，才能判断所谓优化有没有破坏正确性。
2 权威 DNS、递归解析与 TTL 窗口
DNS 查询通常从客户端使用的递归解析器开始。递归解析器替客户端向域名体系查询，并缓存答案；权威 DNS 则发布某个域名区域的正式记录。浏览器通常不会为每个请求从根开始查找。一次访问可能直接命中本地缓存，也可能让递归解析器沿委派关系找到权威服务。排障必须区分“权威已经发布新值”和“用户现在拿到新值”。
常见记录中，A 把名称映射到 IPv4 地址，AAAA 对应 IPv6，CNAME 把名称指向另 1 个名称。接入 CDN 时，业务域名常通过 CNAME 指向平台分配的接入名称，再由后续解析获得边缘地址。CNAME 是解析别名，不是 HTTP 重定向；用户地址栏、请求的主机名和需要校验的证书名称通常仍是原业务域名。
TTL 表示这份 DNS 答案可以被缓存的时间上限线索，单位通常为秒。缓存中的剩余 TTL 会随时间减少，实际行为还受到解析器策略和应用实现影响。它不是故障检测时间，也不是切换完成保证。不存在的名称还可能被负缓存；即使后来补上记录，部分客户端也可能暂时继续收到不存在的结论。
CDN 的源站是提供原始内容或业务处理的服务，边缘节点负责接收用户请求。命中表示边缘找到可用缓存对象；未命中表示需要获取内容；过期对象是否能暂时返回，则取决于明确的陈旧内容策略。缓存命中并不证明内容正确，未命中也不等于故障。对订单 API，按设计透传往往就是正确行为。
HTTP 缓存时间和 DNS TTL 属于不同层。Cache-Control: public, max-age=300 描述响应如何被缓存；DNS 的 TTL 描述解析答案如何被缓存。修改前者不会刷新用户的域名解析，修改后者也不会清掉边缘上的旧页面。浏览器私有缓存、共享边缘缓存和服务端业务缓存同样需要分别命名，避免在故障群里只说“清缓存”。
缓存键决定哪些请求被认为可以共享同 1 份响应，通常涉及主机名、路径、查询参数，以及选定的请求头或其他维度。把用户标识放进缓存键并不自动获得安全性：还要确认鉴权发生在哪里、缓存对象是否可能被其他入口读取、退出登录后是否残留。订单查询默认绕过共享缓存更容易建立正确边界。
HTTPS 还带来 2 段信任关系：客户端到边缘、边缘到源站。边缘证书有效，不代表回源证书也有效；回源使用的地址、TLS 的服务器名称以及 HTTP 的 Host 可能各有配置。它们必须共同匹配源站的证书和路由。DNSSEC 可帮助验证 DNS 数据真实性，不能代替 HTTPS 加密，也不能证明订单业务授权正确。
最后，域名、节点和业务实例之间通常不是固定的对应关系。多个域名可以落在相同节点，同 1 个域名也可按地区、运营商或健康状态得到不同结果。理解这些概念，是为了把故障收窄到某段关系，而不是背下“域名一定对应 1 台机器”这样的错误模型。
3 CDN 缓存键、新鲜度、失效与回源
以顾客读取商品图片为例，客户端先查询域名，拿到边缘地址，再建立 TCP 或 QUIC 连接并完成 TLS。边缘收到 HTTP 请求后，根据域名、路径、方法和规则决定是否检查缓存。若对象存在且仍可用，便返回对象；否则向源站请求，再根据响应头与平台规则决定是否存储。每次命中节省的主要是回源工作，不会消除首次解析、连接和边缘处理的成本。
缓存策略必须同时回答 3 件事：哪些响应允许共享、什么使它们失效、失效时怎样更新。带内容指纹的脚本适合较长缓存，新版本换 URL；不带版本号的活动页需要较短时间或主动刷新；个人订单与支付相关响应应禁止共享存储。只按文件后缀判断缓存资格有风险，例如返回 JSON 的公开字典与返回 JSON 的订单详情并不等价。
回源验证可以降低重复传输。边缘保存对象及其 ETag，过期后向源站带上 If-None-Match；源站确认未改变可返回 304，边缘继续使用已有实体并按规则更新元数据。304 不包含完整正文，也不是“没有请求到源站”。它节省传输量，仍消耗连接和验证处理能力，容量规划要把这类请求算进去。
缓存键过粗会串内容，过细则会降低复用。例如商品图片 URL 附上每次随机变化的追踪参数，如果参数进入键，每次访问都可能形成新对象；如果把真正决定图片尺寸的参数删掉，又可能给缩略图请求返回大图。参数规范化应有白名单和业务解释，不能为了提高命中率任意忽略参数。Vary 表达响应依赖的请求头，但仍需确认边缘实现支持相应行为。
热点对象过期可能让大量请求同时回源，形成击穿。请求合并可以让相同对象的并发获取复用 1 次回源；预热可以提前装入明确的热门资源；不同对象的过期时间可以适度分散。这些措施只适用于可安全复用的内容。不能把提交订单合并成相同请求，也不能用旧订单成功响应吸收新提交的流量。
DNS 调度通常根据解析请求来源等线索返回入口，用户地理位置未必与递归解析器位置一致；部分体系使用客户端子网提示，也会涉及隐私与缓存分散的权衡。边缘内部还可能使用任播或其他流量调度。看到某个城市拿到较远节点，应结合实际连接和时延判断，不要只看 IP 归属地就断定调度错误。
假设资源请求速率为 10000 次/秒，按请求计算的命中率为 90%，则简化估算的回源速率是 10000 × (1 - 0.90) = 1000 次/秒。若命中率降到 60%，回源将到 4000 次/秒。这只是容量直觉，未包含验证请求、刷新、重试和请求大小差异。命中率看似只下降了 30 个百分点，源站压力却可能变为 4 倍。
4 订单链路：静态、公开内容与写请求边界
把购物链路拆成读取图片、读取商品、确认价格库存、提交订单、查询结果，有助于分别设计入口。商品图片和脚本优先使用独立静态域名；公开商品描述可以缓存，但展示的库存提示不能代替结算时校验；确认价格和创建订单必须由可信服务按当前业务规则判断。页面加载很快与订单处理正确是不同目标，验收要同时覆盖。
对 POST /orders，边缘应按明确定义的 API 规则透传，不能仅凭某个平台“默认不缓存 POST”就停止检查。响应使用 Cache-Control: no-store，同时配置并验证边缘不存储该路径；对带身份的订单详情也采用相同原则。no-cache 允许存储但要求复用前验证，不等于禁止保存，因此不宜拿它替代订单隐私数据的禁止存储要求。
鉴权失败、限流和源站错误也要检查缓存行为。若通用规则缓存了某个用户的 401，后续合法请求可能继续被拒绝；若缓存了订单查询的 200，却忽略身份维度，后果更严重。不要仅检查成功路径的响应头，应覆盖登录、未登录、不同账号、不同查询参数和不同状态码，并观察实际边缘行为。
订单创建超时时，客户端无法仅凭超时区分“源站未收到”和“已经创建但响应丢失”。边缘或客户端若自动重试写请求，可能重复创建订单。解决办法是由业务服务支持有范围、有有效期的幂等键，记录请求语义和结果，并提供结果查询。CDN 的重试开关不能替代幂等，DNS 切换也不能消除已经在途的请求。
客户端地址经过代理后，源站看到的连接地址可能是边缘地址。业务若需要按用户地址做风控或限流，应只信任来自已授权代理链的转发字段，并在入口清除可伪造的同名字段。请求标识也应有可信生成与传递规则。把任意客户端提供的转发头直接当成真实身份，会让监控归因和安全策略同时失真。
边缘到源站宜使用经过验证的 HTTPS，限制源站只接受授权回源流量，并选择适当的回源认证机制。这样才能避免用户绕过边缘直接打到源站。限制方式要考虑平台地址变化和应急入口维护；不要通过关闭证书校验来“快速修复”回源失败，否则错误源站或中间路径的问题可能被长期隐藏。
跨域和 Cookie 同样影响订单入口。将页面与 API 拆到不同域名后，要按真实调用方式设置允许的来源和凭据策略，不能盲目反射任意 Origin；Cookie 的作用域、Secure 与 SameSite 设置也要相容。上线前用真实浏览器走完整下单流程，因为命令行请求成功并不能证明浏览器会携带凭据或允许脚本读取响应。
5 动手：解析链、TTL 与缓存头直觉
动手时先建立基线，再做单变量对照。控制台里按业务域名查看记录类型、目标值和 TTL，接着查看 CDN 绑定域名、证书名称、源站协议、回源 Host、缓存键和路径规则优先级。把最终生效规则记录下来，不能只保存编辑界面的截图；有的平台存在规则覆盖、灰度生效或尚未发布的草稿状态。
下面命令中的 .example 是保留示例名称，执行前应替换成有权限测试的真实域名。dig 用于观察解析答案；curl 用于观察 HTTP 和连接过程。示例不对生产系统执行变更，也不提交真实订单。先检查查询对象和请求方法，避免把用于读取的探测命令改成会产生业务副作用的请求。
dig api.shop.example A
dig api.shop.example AAAA
dig static.shop.example CNAME
dig @<递归解析器IP> api.shop.example A
dig @<权威服务器IP> api.shop.example A +norecurse
curl -sS -D - -o /dev/null https://static.shop.example/assets/app.v42.js
curl -sS -o /dev/null -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first=%{time_starttransfer} total=%{time_total}\n' https://api.shop.example/health比较权威与递归答案时，记录查询时间、服务器、完整 CNAME 链、A/AAAA 以及剩余 TTL。直接查询权威也要确认该服务器确实对目标区域权威，并留意回答标志。dig +trace 可帮助查看委派链，但它的逐级查询路径不等同于浏览器实际使用的递归解析路径，不能用 1 次 trace 代替用户现场证据。
查看 HTTP 时保留状态码、Cache-Control、Age、ETag、Vary 和平台提供的缓存状态字段。Age 是缓存年龄线索，不是对象所有历史的完整记录；某个字段缺失也不能直接证明没有缓存。连续访问相同版本资源，再改变明确的缓存键维度，可以观察命中行为。订单接口应使用测试账号与只读查询，避免把敏感响应写入共享日志。
时间字段多是从请求开始累计的时间点。例如 TLS 完成时间包含此前的解析与连接时间，不能把所有字段相加当总耗时。首字节时间还包含请求发送、边缘处理、可能的回源和服务端等待。要分辨回源耗时，需要边缘与源站的关联日志；仅凭 1 次 curl 首字节慢，无法认定数据库慢。
curl --resolve api.shop.example:443:192.0.2.10 \
-sS -D - -o /dev/null https://api.shop.example/health这里的地址是文档示例地址。替换为授权测试的目标地址后，--resolve 能固定连接地址，同时保留 URL 主机名用于 TLS 与 HTTP，适合比较候选入口。它不会修改公网 DNS，也不能证明所有真实用户都能连通。测试完成后应撤去本地固定解析，避免后续观察一直绕开真实调度。
6 观测：解析探测、边缘命中、回源压力
观测先分层，再关联。DNS 层记录查询名称、类型、解析器、响应码、答案和 TTL，关注超时、SERVFAIL 与 NXDOMAIN 的分布；边缘层记录节点、缓存结果、状态码、总耗时和回源耗时；源站层记录请求标识、路由、业务结果和依赖耗时。SERVFAIL 表示解析失败的一类结果，NXDOMAIN 表示名称不存在，不能把它们统一归为“没有网络”。
边缘状态码与源站状态码要保留各自的语义。边缘可能在尚未连接源站时返回 502、503 或 504，也可能原样传回源站错误。反过来，源站返回 200 只表示 HTTP 层成功，业务正文仍可能表达下单失败。统计订单成功率时，应使用业务确认结果，同时保留技术状态帮助定位，不要把接口 200 率直接当成交成功率。
命中率至少区分按请求和按字节。大量小图命中可以让请求命中率很高，但少量大文件未命中仍可能耗尽回源带宽。还应按域名、路径类别、地区、运营商和缓存结果分组。把静态资源与订单 API 混在总览里，既会稀释故障，也会诱导团队为了整体命中率去缓存原本不该缓存的内容。
时延建议观察 p50、p95、p99，并说明采样窗口和样本数。低流量路径的 p99 很不稳定，需要结合原始样本与错误数；高流量入口只看平均值又容易掩盖长尾。DNS、TLS、边缘、回源和业务依赖最好分别观察。不同层时钟应保持同步，否则跨日志计算耗时可能出现负数或错误的因果顺序。
告警要能够触发行动。例如多个地区的真实合成探测持续出现解析失败，通知域名值班；特定域名的回源连接错误上升，通知入口与源站值班共同处理；订单 API 共享缓存出现命中，则作为正确性异常立即调查。阈值应参考业务基线、最小样本量和持续窗口，避免把偶发探测失败与全面故障混为一谈。
证书到期、域名续费、权威委派变更和规则发布也是入口风险，应有提前量告警和负责人。证书需要分别检查边缘与源站，双栈入口还应分别探测 IPv4 和 IPv6。监控自身若只从某个机房、某个解析器出发，可能完全看不到局部用户故障，因此要保留多地域、多网络视角。
日志采集也应设边界。请求标识、对象路径和错误阶段通常足够定位，不应默认记录访问令牌、完整 Cookie 或订单隐私正文。必要的用户关联采用受控标识，并约定保留周期与访问权限。把足够的诊断字段设计在正常链路中，比故障期间临时开启全量敏感日志更可靠。
7 常见坑：CNAME 当重定向、共享缓存订单、TTL 误判
第 1 个坑是“TTL 改成 30 秒，30 秒后就能全部切走”。旧答案可能在改动之前按 3600 秒缓存，降低权威记录 TTL 不会主动召回旧答案。解析器策略、应用缓存、连接复用和故障检测也会叠加。计划切换应提前降低 TTL，并至少等待原 TTL 对应的缓存窗口，同时保持旧入口可用，再通过实际流量观察收尾。
第 2 个坑是“所有 GET 都可以缓存”。GET 表达读取语义，不代表内容公开，也不代表响应可被其他用户复用。GET /orders/me 明显依赖身份；某些查询还依赖租户、语言或价格体系。缓存资格要由响应语义与访问边界共同决定。只在缓存键加入 Cookie 也可能导致海量对象和难以证明的隔离，应优先判断是否根本需要共享缓存。
第 3 个坑是“清掉 CDN 就一定更新了”。浏览器可能仍保留旧对象，另 1 个域名或查询参数变体可能没有被覆盖，刷新任务也可能尚未完成。长期缓存资源宜使用内容版本 URL，页面引用新版本时让旧资源继续存在。刷新用于修正明确范围的对象，不应成为每次发布都无边界清空缓存的默认动作。
第 4 个坑是“命中率越高越好”。图片命中增长可能带来收益，订单响应意外命中却可能是数据泄露信号。即使内容允许共享，过长时间也可能让顾客看到旧促销价格。上线报告应同时写明正确性、内容新鲜度、源站负载和用户耗时，避免把单项指标当成优化目标。
第 5 个坑是“有备用源站就能自动容灾”。备用站需要相同的证书、路由、鉴权配置和足够容量，还需要满足订单数据的一致性要求。健康检查只测静态 /health 时，数据库故障可能被遗漏；直接用真实创建订单做高频探测又会污染业务。可以设计无副作用的依赖检查与隔离的合成业务交易，并明确各自能够证明什么。
第 6 个坑是“一次失败就切换、一次恢复就切回”。抖动会造成流量往返迁移，增加连接重建、缓存冷启动和排障噪声。健康检测应设置连续失败与恢复条件，切回应检查容量和数据状态。写请求重试还要受幂等与超时预算约束，不能把网络层重试次数无限叠加到客户端重试之上。
第 7 个坑是“换域名就能修好”。新域名需要证书、跨域、Cookie、客户端配置和解析预热；旧版客户端可能根本不会使用新入口。应急动作越临时，遗漏越多。平时维护可演练的备用路径，明确授权与撤回方式，比故障时临时拼出入口更有确定性。
8 案例：大促切流与命中率骤降
某商城活动前的静态请求速率预计为 20000 次/秒，图片和脚本占主要流量，订单创建峰值预计为 800 次/秒。团队把带版本资源设为长期缓存，公开活动页使用受控短缓存，订单路径全部透传。基线测试中静态请求命中率约 95%，简化回源估算为 1000 次/秒。源站按缓存失效与节点冷启动的额外压力预留容量，而非只按这个稳态数字采购。
活动开始后，设计团队上线了 1 组新图片，页面生成器却给每次图片请求加上随机追踪参数。CDN 将这些参数计入缓存键，静态命中率下降到 70%，回源速率接近 6000 次/秒。共享出口与连接资源受到挤压，订单 API 的回源等待也上升。订单服务 CPU 正常，因此单看应用扩容指标无法解释顾客下单变慢。
值班先比较按域名和缓存结果拆分的请求量，确认增长来自静态未命中；再从边缘日志抽取 URL，发现相同图片对应大量随机参数。处置是回滚生成器变更，并只对确认不影响内容的追踪参数做键规范化。不能直接忽略所有查询参数，因为图片尺寸参数决定真实内容。恢复后逐步预热热点资源，观察回源连接数和订单时延共同回落。
另一类故障发生在源站所在网络。边缘发现主源站连接超时，团队准备启用备用源站。此时入口可达不代表订单可写：备用环境还要确认订单数据同步、幂等记录、库存依赖和容量。如果这些条件未满足，临时关闭创建入口并允许已有订单查询，可能比把写请求直接送入状态不明的备用站更符合业务目标。
若备用源站已完成演练且具备接管条件，可按预案切换回源目标或入口调度。两种动作影响层次不同：修改边缘回源配置通常不要求客户端换地址；修改 DNS 则受到已有解析与连接状态约束。不要同时随意改动两层，否则无法判断哪项动作有效。切换过程中保持请求标识和幂等键连续，单独追踪在途请求与超时请求的最终业务结果。
恢复判据不能只有“备用站探测绿了”。还应确认多地域真实入口可达、订单成功率与长尾时延恢复、积压已下降、主备数据符合预案，以及旧入口仍有多少流量。切回时再次评估缓存冷启动和连接爬升，避免恢复动作引发第二次冲击。保留每次变更的时间点，才能把流量与错误变化对应起来。
复盘得到的改进也要落到可执行项：URL 生成规则加入缓存键评审，静态与订单回源资源尽量隔离，容量测试包含低命中场景，故障演练包含超时后重复提交。CDN 帮助吸收可复用读取，DNS 帮助选择入口，但订单的最终正确性仍需业务服务和数据层提供证据。
9 排查案例：入口故障证据链
客服反馈某地区部分用户在切换后无法下单，其他地区正常。值班首先固定时间窗口、受影响网络、域名、客户端版本和现象：是解析失败、TLS 报错、HTTP 超时，还是订单业务拒绝。用户提供的“打不开”只是入口描述，不能直接归因。排查目标是把同 1 次访问沿解析、连接、边缘、源站和业务结果连起来。
第 1 段证据来自 DNS。权威查询已返回新目标，但受影响网络的递归解析器仍返回旧目标，剩余 TTL 为 420 秒；另 1 个解析器返回新目标。这支持“不同缓存状态共存”，却还不足以证明旧入口就是故障原因。继续记录完整 CNAME 链及 A/AAAA，避免只检查 IPv4 而漏掉浏览器实际优先尝试的 IPv6。
第 2 段证据来自连接。使用保留原主机名的固定地址测试，旧地址 TLS 握手失败，新地址握手成功。旧入口的证书轮换恰好遗漏了该域名，证书名称与请求主机名不符。若直接访问 IP 或跳过证书校验，测试可能得到不同结论并掩盖问题。此时才有足够证据把局部失败与旧解析目标关联。
第 3 段证据来自日志。受影响时间内，旧入口没有对应 HTTP 请求标识，因为失败发生在 HTTP 之前；新入口和源站的请求量正常。没有源站日志并不等于 DNS 故障，但结合解析结果和 TLS 错误，可以排除“订单服务收到后处理太慢”这个假设。证据之间应互相补足，不能把某条日志缺失单独当成最终结论。
处置是恢复旧入口的正确证书与服务能力，保持新旧入口共同承接缓存窗口内的流量；随后持续比较受影响解析器答案与实际旧入口访问量。用户刷新页面不能保证清除系统和递归缓存，要求所有用户修改 DNS 也不适合作为主要恢复办法。停止旧入口前，应根据旧 TTL、应用行为和访问尾流给出保守窗口。
还要确认是否存在第 2 个问题。例如 TLS 恢复后仍有创建订单超时，应继续用请求标识核对源站接收和幂等结果，不能因为找到证书问题就停止调查。故障常由多个条件叠加，恢复效果必须用用户入口和业务结果验证。对于先前超时的提交，客户端应查询结果或复用原幂等键，不能换键盲目创建。
最终记录应包括事实、假设、验证动作、结论和恢复结果。事实是旧递归答案与证书不匹配；根因是提前撤销旧入口能力且证书维护遗漏；放大条件是把 DNS 改动误认为即时生效。改进项应明确到旧入口退役门槛、证书覆盖清单和多网络切换演练，让下次值班能够复现判断过程，而非只得到“等 DNS 生效”的模糊经验。
放进方案里
在零售订单方案中，将入口写成可以评审的约定。静态资源使用独立域名，文件名包含内容版本，允许共享缓存；公开商品内容按可接受的新鲜度设定时间；价格确认、库存扣减、创建订单与个人订单查询透传，并明确禁止共享存储。缓存键列出保留的参数和请求头，解释每个维度为何影响响应，规则变更由业务与入口负责人共同评审。
DNS 部分记录权威管理者、A/AAAA 或 CNAME 链、正常 TTL、切换前降低 TTL 的提前量，以及旧入口保留条件。切换时间估算应包含旧缓存、连接复用、健康检测与规则传播，不能只写“30 秒完成”。域名续费、证书更新和委派变更均指定负责人，边缘与源站证书分别监控。
CDN 部分注明源站协议、Host 与 TLS 名称、回源认证、超时预算和重试范围。订单写请求只有在业务幂等保证与总超时预算允许时才按约定重试；备用源站接管前需满足容量、数据与幂等记录要求。恢复与切回应说明触发条件、停止条件和回滚路径，避免频繁摆动。
容量按正常命中、命中下降和集中刷新等场景分别估算，同时检查请求量、字节量及连接数。监控关联解析探测、边缘日志、源站日志和订单结果，按地区与路径拆分。验收覆盖不同账号隔离、订单响应无共享命中、IPv4/IPv6、旧解析尾流和超时后查询结果。
最后写清取舍：缓存时间越长，回源通常越少，但旧内容可能保留更久；TTL 越短，解析查询负载通常越高，也不能消除所有切换延迟。方案以订单正确性和用户成功率为约束，用演练记录证明入口可切、业务可接、结果可核对，再给出收益和成本预估。
10 小结：走向云上安全入门（C19）
- 能区分权威 DNS、递归解析器、本地缓存和已有连接，说明为什么改记录不会立即迁移全部用户。
- 能为静态资源、公开商品内容和订单 API 分别解释缓存资格、缓存键、新鲜度与失效方式。
- 能区分 DNS TTL、HTTP 缓存时间、规则传播时间和故障检测时间。
- 能验证边缘到源站的协议、证书、Host、可信转发字段与源站访问限制。
- 能用请求量估算命中下降后的回源压力，并说明按字节与连接观察的必要性。
- 能将订单超时与最终业务结果关联，说明幂等键为什么必须跨重试保持一致。
- 能以多地域解析、TLS、边缘日志和源站证据判断故障阶段，定义恢复与旧入口退役条件。
自测：旧 DNS 答案还剩 600 秒，团队现在把 TTL 改成 30 秒，旧入口至少还需要考虑哪些状态？如果静态命中率从 95% 降到 80%，在请求总量不变的简化模型下，回源量会变成原来的多少倍？如果订单查询突然出现共享缓存命中，为什么应先调查正确性，而不是庆祝性能提升？
下一课转向 C19 云上安全入门。
带着本章已经验收过的入口约束继续：哪些主机名允许共享缓存、哪些路径必须透传、DNS 切换窗口与旧入口退役条件分别是什么。下一课要把这些入口结论改写成安全边界——身份、对象归属、密钥与审计——并检查：即便解析与 CDN 都正确，越权读取或凭据泄露是否仍能穿透订单。
作业：把本课的缓存资格表、TTL/切流预算和回源认证要求各摘 3 条，写成 C19 方案里「入口信任边界」小节的输入；缺证据的条目先标为待演练，不要用口号代替。