我们已经学习了有关从架构设计层面去应对流量压力的相关内容。大家都知道，像直播这类服务呀，其用户流量是很难预先准确估计的。一旦用户流量增大到某个程度，达到一个机房没办法承受的时候，那就得采取动态调度的措施啦，也就是要把一部分用户合理地分配到多个机房当中去。

　　而且呢，随着流量不断增大，网络出现不稳定状况的可能性也会跟着提高哦。在这种情况下，只有确保用户能够访问到距离他们较近的机房，才能让用户获得更好的使用体验呀。

　　综合考虑以上这些因素呢，在这节课里，我们就着重来探讨一下流量调度以及数据分发方面的关键技术，目的就是帮助大家清楚地了解要怎样才能妥善地完成多个机房之间的流量切换工作。

　　直播服务所涉及的流量主要可以分为两种类型哦，一种是静态文件的访问流量，另一种则是直播流所产生的流量。对于这两种流量呢，都可以借助 CDN（内容分发网络）进行分发处理，这样就能有效地减轻我们服务端所承受的压力啦。

　　对于直播这种读操作和写操作都比较频繁的服务而言呀，动态流量调度以及数据缓存分发可是解决大量用户在线互动问题的重要基础呢。不过呢，它们在功能方面和 DNS（域名系统）是存在重合之处的，所以需要相互配合着来实现相关功能哦。因此呢，在接下来的讲解过程中，也会适当地穿插关于 CDN 的相关介绍内容哦。

　　DNS 域名解析及缓存

　　服务流量切换并没有想象中那么简单，因为我们会碰到一个很大的问题，那就是 DNS 缓存。DNS 是我们发起请求的第一步，如果 DNS 缓慢或错误解析的话，会严重影响读多写多系统的交互效果。那 DNS 为什么会有刷新缓慢的情况呢？这需要我们先了解 DNS 的解析过程，你可以对照下图听我分析：　　

　　客户端或浏览器发起请求时，第一个要请求的服务就是 DNS，域名解析过程可以分成下面三个步骤：

　　1. 客户端会请求 ISP 商提供的 DNS 解析服务，而 ISP 商的 DNS 服务会先请求根 DNS 服务器；

　　2. 通过根 DNS 服务器找到.org顶 级域名 DNS 服务器；

　　3. 再通过顶 级域名服务器找到域名主域名服务器（权威 DNS）。

　　找到主域名服务器后，DNS 就会开始解析域名。

　　一般而言，主域名服务器是由我们所托管域名的服务商来提供的。

　　就域名的具体解析规则以及 TTL（生存时间）时间来讲，这些都是需要我们在域名托管服务商的管理系统当中去进行设置的。

　　当有对主域名解析服务发起请求的时候，主域名服务器便会返回服务器所在机房的入口 IP 地址，同时还会给出建议缓存的 TTL 时间，只有到这个时候，DNS 解析查询的流程才可以说是完成了。

　　接下来，在主域名服务将结果返回给 ISP（互联网服务提供商）DNS 服务之时，ISP 的 DNS 服务会首先依照 TTL 所规定的时间，把这个解析结果缓存到自身服务本地，然后才会把解析结果再返回给客户端。

　　在 ISP DNS 缓存的 TTL 有效期范围之内，要是遇到同样的域名解析请求，那么就都会直接从 ISP 的缓存当中返回结果了。

　　可以想象得到的是，客户端通常也会把 DNS 解析结果给缓存下来。并且在实际进行操作的时候，很多客户端并不会按照 DNS 所建议缓存的 TTL 时间去执行，而是会优先依照自身所配置的时间来操作。

　　与此同时，在数据传输途径当中的 ISP 服务商也会对相应的缓存情况予以记录。要是我们对域名的解析做出了改变，那么要想获得更新的话，最快也得需要服务商去刷新自己服务器所花费的时间（一般来说大概需要 3 分钟），再加上 TTL 时间才行。

　　事实上比较糟糕的情况是下面这样：

　　基于上述情况，不少域名解析服务都给出了这样的建议：把 TTL 的设置时长控制在 30 分钟以内为宜。并且呀，许多大型互联网公司还会在客户端的缓存设置方面采取措施，会人为地去缩短缓存时间。

　　要是您所设置的 TTL 时间过短的话，虽然域名解析的刷新速度确实会比较快，可这也会致使服务请求变得很不稳定哦。从理想状态来讲呢，93 分钟算是比较合适的时长。不过根据过往经验来看呀，正常情况下对域名做出修改之后，全国范围内的 DNS 缓存要全部更新完毕，大概得需要花费 48 小时的时间呢；而要是想让全世界的 DNS 缓存都更新好，那就得需要 72 小时啦。所以呢，不到实在没办法的时候，可千万不要轻易去变更主域名解析哦。

　　要是碰到需要紧急刷新 DNS 缓存的情况呀，我这边给您个建议，您可以去购买那种能够强制推送解析的服务，用它来对主干 ISP 的 DNS 缓存进行刷新操作。但是呢，得注意一下哦，这种服务不但价格很贵，而且它所能覆盖到的范围也只是主要城市的主干线路而已呀，对于个别地区来说，依然还是会存在刷新速度比较缓慢的情况呢，具体的刷新速度快慢可就得取决于宽带服务商啦。不过总体来讲的话，它确实还是能够在一定程度上加快 DNS 缓存的刷新速度的。

　　DNS 刷新缓慢这个问题呀，真的是给我们带来了诸多困扰呢。就好比说我们要是进行故障切换的话，得需要花费三天的时间才能够彻底完成切换操作呀，很明显，这对于系统的可用性而言，那可就是毁灭性的打击啦。

　　好在呢，到了近代出现了不少能够弥补这个问题的技术哦，比如说 CDN 呀、GTM 呀、HttpDNS 等等这些服务呢。接下来呀，咱们就依次来了解一下这些服务吧。

　　CDN 全网站加速

　　可能你会奇怪“为什么加快刷新 DNS 缓存和 CDN 有关系？”在讲如何实现 CDN 加速之前，我们先了解下 CDN 和它的网站加速技术是怎么回事。网站加速对于读多写多的系统很重要，一般来说，常见的 CDN 提供了静态文件加速功能，如下图：

　　在用户向 CDN 服务发起请求的时候，CDN 服务首先会选择返回其本地缓存当中所存储的静态资源。

　　要是 CDN 本地并没有对相关资源进行缓存，又或者该资源属于动态内容，比如 API 接口这类的情况，那么 CDN 就会执行回源操作，也就是回到我们的服务器那里，然后从我们的服务器当中去获取所需的资源。

　　与此同时呢，CDN 会依据我们服务端所返回的资源超时时间来对本地缓存进行刷新操作。通过这样的方式呀，能够极大幅度地减轻我们机房在提供静态数据服务时所承受的压力，并且还可以节省下大量用于带宽以及硬件资源方面的投入呢。

　　除了具备加速静态资源的功能之外呀，CDN 还开展了区域化的本地 CDN 网络加速服务呢，具体的情况就如同下面所展示的图片那样哦。

　　CDN 会在各个主要的省市当中布置用于加速服务的机房哦，并且呀，这些机房相互之间是会凭借高速专线来实现互联互通的呢。

　　当客户端向 DNS 发出进行域名解析的请求时，客户端所在省市的 DNS 服务就会借助 GSLB（全局服务器负载均衡）的功能，返回给当前用户其所在省市距离最近的 CDN 机房的 IP 地址呀。

　　采用这样的方式呢，是能够极大地减少用户与机房之间所存在的网络链路节点的数量的哦，这样一来呀，就可以加快网络的响应速度啦，而且还能够降低网络请求被拦截的这种可能性呢。

　　客户端请求服务的路径效果如下图所示：

　　当用户所请求的是全站加速网站的那些动态接口时，CDN 节点会借助 CDN 内网，通过最短且最快的网络链路，把用户的请求转接到我们的机房服务器那边。相较于客户端要从外省经过多个 ISP 服务商的网络进行层层转发，之后才能向服务器发出请求的这种方式而言，采用上述通过 CDN 节点转接的做法，能够更有效地应对网络速度缓慢的问题，进而为客户端提供更为优质的用户体验。

　　在网站完成全站加速之后呢，所有用户发出的请求都会由 CDN 来进行转发处理，而且客户端所请求的全部域名也都会指向 CDN，随后再由 CDN 将这些请求转至我们的服务端。

　　在此过程当中，如果机房对 CDN 所提供服务的 IP 地址做出了变更，为了能够加快 DNS 缓存的刷新速度，我们可以运用 CDN 内网 DNS 的服务（此服务是由 CDN 供应商所提供的）来对 CDN 中的 DNS 缓存进行刷新操作。如此一来，客户端这边的 DNS 解析情况是不会发生改变的，也就不用像往常那样等待 48 小时，域名的刷新操作会变得更加便捷。

　　正是由于存在需要 48 小时才能刷新缓存的这个问题，所以大多数互联网公司在进行机房切换的时候，都不会选择通过更改 DNS 解析配置的方式来开展故障切换工作，而是会依靠 CDN 来实现类似的功能。

　　不过呢，要是 CDN 的入口出现了故障，那么对网站服务所造成的影响也是相当大的。在国外，为了降低入口出现故障的可能性，会配合着使用 anycast 技术。通过运用 anycast 技术，能够让多个机房的服务入口都拥有相同的 IP 地址，这样的话，一旦其中一个入口发生了故障，运营商便会把流量转接到另外的机房当中。然而，在国内，出于安全方面的考虑，并不支持 anycast 技术。

　　除了 CDN 入口有可能出现故障的风险之外，当请求流量进入到 CDN 之后，要是 CDN 本地既没有对相关内容进行缓存，又需要回源，并且本地的网站服务也同时发生了故障，那么就会出现无法自动将源切换到多个机房的问题。所以呀，为了提升服务的可用性，我们可以考虑在 CDN 的后方增设 GTM（全局流量管理）。

　　GTM 全局流量管理

　　在了解 GTM 和 CDN 的组合实现之前，我先给你讲讲 GTM 的工作原理和主要功能。GTM 是全局流量管理系统的简称。我画了一张工作原理图帮你加深理解：

　　当客户端发出对服务域名进行请求的操作时，其首先会向 DNS 服务发起请求，目的是对所请求的域名进行解析。而在客户端请求主域名 DNS 服务来开展域名解析工作的时候，实际上会请求到 GTM 服务所具备的智能解析 DNS。

　　相较于传统的相关技术而言，GTM 额外增添了三个功能，分别是服务健康监控、多线路优化以及流量负载均衡。

　　先来说说服务健康监控功能。GTM 会对服务器的工作状态予以监控，一旦察觉到某个机房出现没有响应的情况，就会自动将流量切换至处于健康状态的机房。并且在此基础之上，GTM 还提供了故障转移功能，具体来讲，就是依据机房的能力以及所设定的权重等因素，将一部分用户流量转移到其他的机房当中。

　　接着是多线路优化功能。在国内，宽带存在着不同的服务提供商，像移动、联通、电信、教育宽带等等。不同宽带的用户在访问由其所属同一家服务提供商所提供的网站入口 IP 时，往往能够获得最 佳的访问性能；而要是跨服务商进行访问的话，就会由于需要进行跨网转发操作，从而致使请求延迟有所增加。所以呢，通过使用 GTM，就能够依据不同机房的 CDN 来源，进而找到速度更快的访问路径。

　　最后是流量负载均衡功能。GTM 会根据对服务的流量以及请求延迟情况所进行的监控结果，来对流量进行合理分配，以此实现智能化地对客户端流量进行调度的目的。

　　当 GTM 和 CDN 网站加速这两项服务相互结合之后，能够产生更为出色的效果，具体的组合方式就如同下面所展示的图片那样：

　　HttpDNS 服务

　　HttpDNS 服务具备这样的能力，它能够让我们绕开由本地 ISP 所提供的 DNS 服务，如此一来，便可以有效防止出现 DNS 劫持的情况，而且它不存在 DNS 域名解析刷新方面的困扰。

　　同样的，HttpDNS 也为我们提供了 GSLB（全局服务器负载均衡）功能。除此之外，HttpDNS 还能够支持自定义解析服务，借助这一特性，我们就可以实现灰度测试或者 A/B 测试等操作。

　　通常情况下，HttpDNS 仅仅能够解决 App 端的服务调度相关问题。所以呢，当客户端程序使用了 HttpDNS 服务时，为了妥善应对因 HttpDNS 服务出现故障而引发的域名解析失败的状况，还需要提前准备好备选方案才行。

　　在这里呢，我给大家提供一个关于解析服务的备选参考顺序：一般而言，会首先优先选用 HttpDNS；要是它无法正常工作了，接下来就会使用指定了 IP 地址的 DNS 服务；要是这也不行，最后才会考虑使用本地 ISP 商所提供的 DNS 服务。通过这样的安排，可以极大幅度地提升客户端 DNS 的安全性。

　　当然啦，我们还可以选择开启 DNS Sec 来进一步增强 DNS 服务的安全性。不过呢，上述所提到的所有服务，我们都得结合自身实际的预算情况以及所能够投入的时间和精力等多方面因素，来进行综合考量并做出决策。

　　需要注意的是，HttpDNS 这个服务可不是免费的哦，特别是对于大企业来讲，其使用成本会更高一些。这是因为很多 HttpDNS 服务商在提供查询服务的时候，是会按照请求次数来收取费用的。

　　所以呀，为了能够节约成本，我们会想办法去减少请求的数量。在此建议大家，在使用 App 的时候，可以根据客户端所链接网络的 IP 地址以及热点名称（比如 Wifi、5G、4G 等）作为标识，来做一些相应的 DNS 缓存操作。

　　业务自实现流量调度

　　一、HttpDNS 服务的局限与业务调度相关情况

　　HttpDNS 服务虽然能够解决 DNS 污染的问题，但其无法参与到我们的业务调度当中。所以当我们依据业务需求开展管控调度工作时，它所能给予的支持是比较有限的。

　　二、基于 HttpDNS 原理实现的流量调度服务及常见实现方式

　　为了给用户带来更好的体验，互联网公司参照 HttpDNS 的原理实现了流量调度功能。就拿很多难以对用户流量进行有效控制的直播服务来说，它们就实现了类似 HttpDNS 的流量调度服务。

　　这种调度服务常见的实现方式是：由客户端向调度服务发起请求，随后调度服务会将客户端调配到距离较近的机房。

　　三、调度服务的故障转移及提高自身可用性的做法

　　该调度服务还具备机房故障转移的能力。当服务器集群出现故障时，客户端请求机房就会出现诸如失败、卡顿、延迟等情况，此时客户端会主动向调度服务发出请求。倘若调度服务接收到了切换机房的指令，便会向客户端返回健康机房的 IP 地址，以此来提升服务的可用性。

　　不仅如此，调度服务自身也需要提高可用性。具体的做法是将调度服务部署在多个机房，并且多个调度机房会通过 Raft 强一致协议来同步用户调度结果策略。

　　例如，当一个用户请求 A 机房的调度服务后，被调度到了北京机房，那么在短期内，即便该用户再次请求 B 机房的调度服务，仍旧会被调度到北京机房。只有在客户端切换网络或者我们的服务机房出现故障的情况下，才会对流量进行统一的变更。

　　四、辅助数据对调度服务决策的支持及相关情况

　　为了提升客户端的用户体验，我们需要将客户端调配到距离近且响应性能最 佳的机房。为此，我们需要一些辅助数据来为调度服务分配客户端提供支撑，这些辅助数据包括 IP、GPS 定位、网络服务商、ping 网速、实际播放效果等。

　　客户端会定期收集这些数据，并将其反馈给大数据中心进行分析计算，以便为调度服务提供参考建议，从而帮助调度服务更好地做出关于当前应该链接哪个机房以及对应的线路的决策。

　　实际上，这么做就相当于自行实现了 GSLB 功能。不过，自行实现 GSLB 功能所依据的数据并非绝对准确无误。因为不同省市的 DNS 服务解析出来的结果往往存在差异，而且如果客户端无法联通，就需要根据推荐的 IP 挨个尝试，以此来确保服务的高可用性。

　　五、调度稳定性验证及直播、视频相关调度功能

　　为了验证调度是否稳定，我们可以在客户端暂存调度结果，并且在每次客户端请求时，在请求头（header）中带上当前调度的结果。通过这种方式，就能在服务端监控是否存在客户端错误请求到其他机房的情况。

　　一旦发现错误的请求，可以通过机房网关采取类似 CDN 全站加速那样的反向代理转发措施，以此来确保客户端的稳定。

　　对于直播和视频业务，同样也需要开展类似调度的功能。当我们播放视频或者进行直播时，倘若出现监控视频卡顿等情况，客户端应能够自动切换视频源，同时将相关情况上报给大数据中心进行记录分析。要是发现大规模视频卡顿的情况，大数据中心会向我们的运维和研发伙伴发送警报。

　　域名作为我们服务的关键入口，当对一个域名发起请求时，第一步就是要经由 DNS 把域名解析为 IP 地址。然而，要是过于频繁地去请求 DNS，那么这将会对服务的响应速度产生不利影响。所以呢，许多客户端以及 ISP 服务商都会针对 DNS 设置缓存机制。但恰恰是这种多层级的缓存设置，直接致使刷新域名解析的操作变得极为困难。

　　即便我们愿意花钱去刷新多个带宽服务商那里的缓存，可在某些个别区域，仍然至少需要等待 48 个小时，才能够完成对大部分用户的缓存刷新工作。要是因为网站出现故障等特殊原因，我们必须要对 IP 进行切换的话，那么由此带来的影响可就堪称是灾难性的了。

　　好在近些年来，我们能够借助 CDN、GTM、HttpDNS 这些技术手段，来强化针对多机房的流量调度能力。不过需要注意的是，CDN 和 GTM 主要是针对机房进行调度安排，对于业务方而言，它们的调度过程是透明不可见的。

　　因此，在那些更加注重用户体验并且存在高并发情况的场景当中，我们往往会自行去实现一套专门的调度系统。在这种自行实现的方案里，大家会察觉到，其思路和 HttpDNS 以及 GSLB 的思路颇为相似。它们之间的区别在于，之前的那些服务仅仅属于基础服务，而我们自行实现的服务还能够迅速且有效地帮助我们对用户流量进行调度安排。

　　通过 HttpDNS 来实现让用户切换机房、切换视频流的操作，无疑是非常便捷简单的。只需要在我们 App 发送请求进行封装的时候，对链接的 IP 地址做出更改，就能够在业务不受影响的情况下，完成机房的切换操作。