虎牙在全球 DNS 秒级生效上的实践( 四 ) _DNS

但是切换的整个过程对 DNS-F 是没有任何影响的，延迟保持平稳。此外，在集群重新上线前，我们需要做数据校验，保证集群之间元数据和实例数据的最终一致。
可用性级别方面，我们可以保障：

单集群挂掉后不会有影响；
双集群挂掉后只会影响域名变更，不影响域名解析；

线上演练数据校验机制
运行过程中，我们也要保证集群间数据的一致性。我们通过全量校验和增量校验两种手段去保证，全量校验方式如下：

大区内部做10分钟的全量校验，保证大区内各个集群数据的一致；
大区之间做2分钟做一次全量校验，保证大区之间被同步的服务的数据一致性。

增量校验方式如下：

从其他数据源同步的数据，通过数据源的时间戳，做增量校验；
基于API的写入日志，定期校验写入的内容是否已经全部同步。

DNF - S 高可用关于 DNS - F 的高可用，我们主要做了以下5个点：

Agent 的健康状态监测，包括进程存活和是否能正常解析；
缓存内部域名，并做持久化处理，保证 Nacos 集群出现问题时不会影响内部域名的解析；
提供备用节点，保证在 DNS-F 挂了，或者是 DNS-F 需要升级的情况下，也不会影响到内部域名解析；
resolv.conf 配置检查，发现127.0.0.1不在配置中会自动添加；
限制 Agent 的 CPU 的使用，避免对业务进程造成影响。

具体的实践和落地实践一：数据库域名改造
之前的数据库是用 IP 方式接入的，在数据库切换的时候，需要通知每个业务方修改配置，重启服务，这样就带来一个问题：整个过程是不可控的，取决于业务方的响应速度，生效时间通常超过十分钟。

文章插图
提升数据库切换的关键点，第一个就是切换时不需要业务方参与，能在业务方无感知的情况下进行切换；第二个是实例变化能秒级推送到我们的应用，将应用快速切换到一个新的实例上。

文章插图
大家可以看一下这个图，这是我们现在做的一个改造，图中的 DMX 是虎牙内部的一个数据库管理系统，思路就是把 DMX 和名字服务打通。DMX 会把数据库实例信息以服务的形式注册到名字服务，服务名就是域名。
实际应用过程中，通过这个域名去访问数据库，应用在访问前首先会经过 DNS - F 去做域名的解析，解析的时候是从名字服务查询实例信息，然后把实例的IP返回给应用。这样，应用就能通过 IP 和我们的数据库实例进行连接。
切换的时候，在 DMX 平台修改域名对应的实例信息，并把变更推送到名字服务，名字服务再推送给 DNS-F ，应用在下一次解析的时候就能拿到新的实例 IP ，达到切换数据库实例的目的。
这套方案落地后，虎牙的数据库切换基本上在10秒钟之内能够完成。
实践二：内部调用使用内部域名
虎牙部分内部系统之间调用是通过7层负载均衡，但是由于没有内部 DNS ，需要通过的公共的 LocalDNS 来解析，这就带来一些问题：
问题一：扩缩容的时候要去修改 DNS 记录，整个过程生效时间可能会超过10分钟，故障的节点会影响业务较长的时间。
问题二：公共的 LocalDNS 智能解析不准确，比如无锡的机器可能会解析到深圳的一个接入点，影响接入质量。
问题三：不支持定制化的负载均衡策略，例如同机房、同大区优先的策略，通过公共 LocalDNS 是实现不了的。
如果想要提升内部服务调用质量，一是 DNS 记录变更绕过 LocalDNS ，把 DNS 的记录变更直接推到 DNS-F 。二是与内部系统打通，从 CMDB 等内部系统获取机器信息，支持多种负载均衡策略。