背景
为什么要谈这个话题？缘由于现在 CDN 的广泛应用在企业客户，但是很多甲方的运维或者工程师对 CDN 的调度以及 DNS 的调度原理并不清楚，基本遇到问题也无法判断到底是否问题在 CDN 。甚至用户自己的使用规范不对也会埋怨是 CDN 的问题。今天简单根据几个案例聊下所谓 “调度不准” 的一系列疑问。
购买 CDN 加速服务后的解析流程
先了解几个概念，我们在通过一张图介绍下
1、首先 CDN 默认是通过 DNS 调度的，但提供了额外的 httpdns 产品，可以根据 IP 来进行准确的解析。
2、使用 CDN 加速服务会提供一个 CNAME 地址，但是 CNAME 的解析和域名的解析流程不同，不能混淆。
3、客户端的真实出口 IP 和 出口 DNS IP 不一定是完全在一个 ISP 内。
“调度异常” 的范围
一、用户 DNS、出口IP 不再同一个运营商
如上图，是一个很典型的热点问题，用户是联通的 IP 出口，但配置了皓宽 DNS，结果是访问到 CDN 皓宽节点后出现了 ping 不稳定的情况。小运营商网络都是从三大运营商买带宽后组合的各种线路，通过网间的 proxy 跨网访问，网络效果很差，超时、RT 不稳定也不奇怪。用户对 DNS 和 CDN 解析调度的基本概念也不了解，自认为是 CDN 节点出现了故障，这种反馈很频繁，分析这类问题并解决不难，可以参考：
1） 用户端的 IP 必须和 localDNS 都是同运营商。 这个地址可以获取到用户的 IP 出口和 localDNS ，工具地址：https://cdn.dns-detect.alicdn.com/https/doc.html 基本上到这一步可以解决 20% 的场景。
2）要进行横向比对域名的解析和 CNAME 解析是不是同样出现问题，因为没进入 CNAME 之前的域名解析都是由运营商的 localDNS 或者公用 DNS 递归转发。而进去到 CNAME 之后是有 CDN 的 NS Server 和 CDN 内部调度系统处理。如果发现域名解析结果异常，但是 CNAME 解析结果正确，就可以明显定位是 localDNS 或者 公共 DNS 的问题。到了这个环节基本就能解决 50% 的问题。
dig 域名
dig www.taobao.com
; <<>> DiG 9.10.6 <<>> www.taobao.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42589
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;www.taobao.com. IN A
;; ANSWER SECTION:
www.taobao.com. 131 IN CNAME www.taobao.com.danuoyi.tbcache.com.
www.taobao.com.danuoyi.tbcache.com. 24 IN A 61.155.221.227
www.taobao.com.danuoyi.tbcache.com. 24 IN A 221.229.203.214
www.taobao.com.danuoyi.tbcache.com. 24 IN A 221.229.203.213
;; Query time: 41 msec
;; SERVER: 30.14.128.31#53(30.14.128.31)
;; WHEN: Thu Mar 04 00:32:36 CST 2021
;; MSG SIZE rcvd: 136dig $CDN_CNAME
dig www.taobao.com.danuoyi.tbcache.com
; <<>> DiG 9.10.6 <<>> www.taobao.com.danuoyi.tbcache.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13879
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;www.taobao.com.danuoyi.tbcache.com. IN A
;; ANSWER SECTION:
www.taobao.com.danuoyi.tbcache.com. 7 IN A 61.155.221.227
www.taobao.com.danuoyi.tbcache.com. 7 IN A 221.229.203.214
www.taobao.com.danuoyi.tbcache.com. 7 IN A 221.229.203.213
;; Query time: 41 msec
;; SERVER: 30.14.128.31#53(30.14.128.31)
;; WHEN: Thu Mar 04 00:33:54 CST 2021
;; MSG SIZE rcvd: 111甚至可以更换 DNS 进行解析对比测试
dig www.taobao.com @114.114.114.114
; <<>> DiG 9.10.6 <<>> www.taobao.com @114.114.114.114
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58700
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.taobao.com. IN A
;; ANSWER SECTION:
www.taobao.com. 36 IN CNAME www.taobao.com.danuoyi.tbcache.com.
www.taobao.com.danuoyi.tbcache.com. 59 IN A 60.163.129.164
www.taobao.com.danuoyi.tbcache.com. 59 IN A 60.163.129.165
;; Query time: 40 msec
;; SERVER: 114.114.114.114#53(114.114.114.114)
;; WHEN: Thu Mar 04 00:35:43 CST 2021
;; MSG SIZE rcvd: 120二、CDN 节点下线后为什么用户还会访问到
“下线“ 阐述这个概念前先说明，每个客户的 CNAME 背后都对应着 CDN 一个调度域，有个 CDN 公司叫调度组。比如大文件组、小文件组、https 组等等。而调度域下可以简单的理解为包含了 N 多个调度单元，层级往下追述服务用户的 CDN 节点。
而 “下线” 就是服务端的监控联合节点上各种业务、系统指标判断节点 “生病” 了，需要从服务用户的调度域中踢出，治理恢复后再重新上线。耳下线的过程涉及的较多，牵扯 DNS 解析、CDN 调度系统的生效、和自动化监控的准确性以及时效性。当下 CDN 厂商基本可以保证服务端调度的秒级切换和上下线，但是客户端的 localDNS 确不是阿里云能够控制的，经常会缓存住客户端的 A 记录，造成用户依然访问旧的 CDN 节点，进而造成了所谓的故障。
从三个方面阐述
为什么用户端的 localDNS 要缓存 CDN 返回的 A 记录
1） 如果不对 CDN 返回的 A 记录进行缓存，那每次都要递归询问 CDN 的权威服务器，会消耗不必带宽流量、对于网站的加载耗时也会增加。
2）很多小 ISP 或者四五线城市的 ISP 会不按规则出牌，比如 CDN 返回的 DNSTTL 是 600 ，但会出现个别 ISP 把 TTL 缓存时间改的很大，这样可以降低他们 localDNS Server 的查询压力，但这会网民可能就是个坑。
不按规则出牌进行的 TTL 缓存
带来的结果就是客户端短时间内无法切换到 CDN 新的节点上，访问异常切换时间的延长，也会加剧网民的访问异常。用户可能会误以为 “阿里云故障” ，这种情况下用户可以保留 dig $domain 的返回结果，以及 dig $CNAME 的对比结果投诉本地的接入运营商，并反馈到阿里云协助处理。或者用户可以清理 loaclDNS 缓存，但并不一定解决。
节点下线过程
节点被服务端监测到异常时，会自动从客户的调度中删除，对应的 VIP 池子中摘掉，但这个摘除的过程，虽然调度系统秒级切换。但流量并不是瞬间掉到 0 byte ，很多已经长连接或者是解析出来节点 IP 正要访问的客户仍然会把流量继续打到 CDN 节点，所以节点流量有一个缓慢下降的过程，等流量基本都消除后，才会把 VIP 对应的服务停掉，不会直接将 VIP 对应的业务直接 kill ，基于这个流程，所以还有部分用户会连接到旧的节点，直到整个请求过程完成。
三、解析出现了 0.0.0.0 127.0.0.1 空 等情况
出现上述情况，用户第一时间就是认为阿里云故障。但并非如此，经过上面基础介绍，大家应该知道了。网民访问域名时最先接入的就是 DNS 的解析，而控制台解析结果的就是 localDNS ，而 localDNS 如果返回了 【0.0.0.0 127.0.0.1 空 】这种情况，说明用户的 DNS 请求可能还未到 CDN，更不要说后面的建联、访问的阶段。
想验证是阿里云 NS Server 没有返回记录，还是用户的 localDNS 解析异常，可以参考如下命令
dig $domain
dig $cname
如果解析异常，返回 0.0.0.0、127.0.0.1、空说明 localDNS 层面禁止了全部解析。
dig $cname @114.114.114.114（可以多测试一些公共的大 DNS 避免数据不准）
如果解析正常，返回 CDN IP ，说明 CDN 都是正常调度，没有出现异常
dig $domain @114.114.114.114
如果解析异常，返回 0.0.0.0、127.0.0.1、空说明可能是针对域名层面也做了封禁。
根据这个监测图就能看出来，如果用 114 的 DNS 去解析就是正常返回，如果是用 localDNS 解析就返回了 0.0.0.0
为什么会出现 0.0.0.0 127.0.0.1 空 等情况
经常遇到的原因如下：
1、用户的域名被管局、省*厅下发封禁操作。
2、用户的域名被反诈骗中心*局封禁。
3、用户的域名被运营商封禁
怎么申诉
有效果的申诉办法，需要用户第一时间保留测试现场作为申诉证据。到工信部的网站上进行申诉 ：https://yhssglxt.miit.gov.cn/web/ ，有详细的申诉流程，申诉通过后，工信部会联系有关封禁部门解除封禁。
四、IP 归属问题
极个别的情况客户端的 IP 在不同的 CDN 厂商会被划分到不同的大区，比如同一个网民的 IP 10x.10x.x.x 在极个别的情况下可能在 A 厂商属于广电，在 B 厂商属于移动，此时需要对应的 CDN 厂商纠偏，避免错误的调度到跨 ISP 的节点上出现访问异常。
但这种纠偏并不是随便做的，最合理的办法是拿到用户真正访问的 DNS IP 分别向相关的 2 个运营商询问是否归属在其管辖的 IP 范围。如果不确认好的话，直接纠偏对应的 IP 段，很可能整个段内的 IP 调度都会受到影响。有可能造成原本属于广电的 IP 被划到了移动，出现灾难性的连锁问题。但是这种个别 IP 段不准的情况极少遇到。
常见解决调度异常的办法
HTTPDNS产品
解决场景：用户 localDNS 和出口 IP不一致引起的调度不准确。以及针对 DNS 解析进行封禁的特殊场景。
用户的请求方式，先用过 http 的方式请求 HTTPDNS 接口，获取客户端的调度 VIP，然后直接访问调度 VIP 。
HTTP 302
解决场景：针对客户端 DNS 不准确的场景。HTTP 协议中有一个特殊的返回状态：302。在 HTTP 服务器返回 302 状态码时，可以携带一个新的 URL（使用的是正确 IP），浏览器在拿到 302 返回状态码时，会提取其中新的 URL 地址发起请求，这样就可以做到重新调度了。弊病就是会有一定的耗时