博主介绍：✌全网粉丝4W+，全栈开发工程师，从事多年软件开发，在大厂呆过。持有软件中级、六级等证书。可提供微服务项目搭建与毕业项目实战、定制、远程，博主也曾写过优秀论文，查重率极低，在这方面有丰富的经验✌
博主作品：《Java项目案例》主要基于SpringBoot+MyBatis/MyBatis-plus+MySQL+Vue等前后端分离项目，可以在左边的分类专栏找到更多项目。《Uniapp项目案例》有几个有uniapp教程，企业实战开发。《微服务实战》专栏是本人的实战经验总结，《Spring家族及微服务系列》专注Spring、SpringMVC、SpringBoot、SpringCloud系列、Nacos等源码解读、热门面试题、架构设计等。除此之外还有不少文章等你来细细品味，更多惊喜等着你哦
🍅开源项目免费哦：点击这里克隆或者下载 ，已经发布Vue3版 🍅
🍅文末获取联系🍅精彩专栏推荐订阅👇🏻👇🏻 不然下次找不到哟
Java项目案例《100套》
https://blog.csdn.net/qq_57756904/category_12173599.html
uniapp小程序《100套》
目录
一、背景介绍
虎牙是一家在线直播平台，技术应用非常广泛，而其中DNS是其中至关重要的一环。DNS的解析过程至关重要，在这个过程中，DNS解析器会跟踪定位，从DNS到本地域名服务器，将请求沿着层层迭代向下传递，最终获取到最终的解析结果。在这个过程中，DNS协议天然的支持分布式架构，并且每一层都有缓存，因此上一层出现问题不会对下一层造成冲击。DNS在虎牙的基础架构中扮演着重要的角色。
DNS 的解析过程很关键，例如上图中的 DNS 解析器通过一个定位解析追踪到我们的 DNS，再到本地域名服务器迭代解析，经过根域再到.com名，最后到http://huya.com的根域名，获取最终的解析结果。
在这个过程中， DNS 解析是天然的分布式架构，每一层都会有缓存，上一层出现问题挂掉，下一层都会有缓存进行容灾。另外，整个 DNS 协议支持面广，包括手机和 PC，我们用的编程框架里也有 DNS 解析器，服务器也会配 DNS 解析引擎，因此，DNS 在虎牙的基础设施中是很重要的部分。
二、虎牙的 DNS 的应用现状
虎牙当前主要是依赖于公共的 DNS，相信在其他公司或多或少都会遇到过下面这些问题：
- 虎牙目前主要依赖公共的DNS，但是无可避免地会遇到以下的问题： ● 使用公共本地DNS解析不稳定，延迟较高。
- DNS记录变更生效时间较长，无法及时处理线路和节点异常对业务的影响，权威DNS数据同步时间不确定，全局生效时间超过10分钟；localDNS缓存过期时间不确定，部分localDNS不遵循TTL时间，缓存时间超过48小时。
- 内部DNS功能缺失，无法解决内部服务调用面临的挑战，例如时延大，解析不准确以及支持多种调度策略。
- 无法快速满足国外业务的发展需求，虽然一些海外云厂商提供了基于DNS的快速扩容方案以及数据库切换方案，但是存在一定的局限性。
三、方案设计和对比
基于以上的问题，开始重新规划 DNS 的设计。
1、名字服务架构
整个规划会分三个方面，核心是做了「名字服务」的中心点，基于此，可以满足需求。
第一个方面，将通过 Nacos Sync 技术，将现有多个注册中心的服务同步到「名字服务」中。这将借助 DNS 实现不同框架之间的 Rest服务方式的调用。具体而言，将支持各种框架之间的服务调用，如 Eureka、Consul、Taf 等等。这为系统提供了更强大的互通能力。 其次，在全球负载均衡的场景下，虎牙以音视频业务为主，而这对节点的延迟是非常敏感的。因此，希望当出现节点延迟的情况时能够立即进行切换。方案将实现快速节点故障检测和动态负载均衡技术，从而确保音视频业务能够始终保持最佳状态。 第三个方面是传统 DNS 场景。这将满足容器和物理机的 DNS 需求。将提供本机 Agent 和集群两种方案，通过缓存和高效的预取技术来大大提高 DNS 解析的可用性和加快生效时间。这将极大地减少服务不可用的情况，从而提高整体业务的可靠性。
对于名字服务的总体设计主要分3部分:第一部分是接入层，这一层需要提供 API，消息通知和 DNS 接入的能力，以方便用户接入系统。第二部分是核心功能层，这一层需要在基于现有网络数据、CMDB 和 IP 库的数据基础上，提供灵活的负载均衡能力、秒级同步全球数据、多数据源同步、全网服务的健康状态监控，及时感知到大范围的节点异常，并且能够及时将节点的屏蔽的信息推送到端上。最终，选择了Nacos作为名字服务核心，因为它提供了统一的API，包括名字注册、变化推送、负载均衡等。同时，还使用了Nacos Sync作为全球集群间数据同步的组件，确保所有数据始终保持最新和一致。最后，还设计了DNS-F作为客户端组件，它可以拦截DNS请求并实现基于DNS的名字服务。
2、改造前后 DNS 变更生效流程的不同
接下来，通过对比看下改造前后 DNS 变更生效流程的差异。
为了确保DNS变更能够快速生效，需要解决以下四个主要问题：
1.权威DNS的数据同步: 权威DNS的数据同步需要跨区域、跨国进行数据传输，因此存在同步慢并且不稳定的问题。为了最小化这种影响，建议使用一个可靠的DNS解决方案，以及建立一个跨地域的域名解析服务。
2. Local DNS的数据缓存问题： 在本地DNS层面，DNS数据由TTL决定，因此在过期后才会刷新缓存。但是，一些厂商可能无法遵守TTL时间缓存，并将缓存时间延长至24小时以上。建议对本地DNS进行优化，并严格遵守TTL缓存时间以确保其在DNS变更后验证新的DNS信息。
3.服务器的DNS缓存问题： 服务器的DNS缓存可以通过使用“nscd”进行优化，将DNS查询缓存在内存中，从而减少DNS查询的响应时间。但是，在高负载情况下，DNS缓存也可能过期或被清除。因此，建议使用最新的硬件和软件技术来优化服务器性能，并定期检查并清理DNS缓存。
4. 应用程序中的DNS缓存问题： 在业务进程层面，应用程序的DNS缓存也可能导致问题。有一些常见的应用程序（如Java虚拟机和框架）已集成了DNS缓存功能，建议仔细阅读文档并根据需要对其进行优化设置。 通过仔细考虑并解决以上问题，可以减少DNS变更对应用程序和最终用户的影响，从而确保DNS变更能够快速生效。下图是更新后的DNS变更生效流程。
整体而言，该解决方案相对简单。针对此问题，可以通过在业务进程中关闭其内部DNS缓存来实现。这样在使用DNS-F进行查询时，可以直接从最近的Nacos集群获取最新的服务节点信息。并且任何后续节点的变化也会即时地推送到DNS-F中，以便直接从缓存中获取最新信息。 DNS缓存对于快速解析DNS的查询请求是很有帮助的。但是，当服务节点的状态发生变化时，DNS缓存无法立即更新，从而导致客户端无法正确地识别最新的服务节点信息。为了解决这个问题，建议业务进程关闭其内部的DNS缓存，通过DNS-F进行查询以获取最新的服务节点信息。DNS-F极大地简化了服务发现的过程，因为它能够维护最新的服务节点信息，并及时地通知客户端任何更改。这样，任何时候，只要客户端需要最新的服务信息，DNS-F都能帮助他们获得最新的信息。
国内 Nacos 集群采用 raft 协议完成毫秒级别数据同步，保证了集群内数据的一致性。 但是在推送变更到跨区域、跨国网络时，可能会出现推送结果丢失或者延迟加大的问题。为此，Nacos Sync被引入，可以让Nacos只需要推送变更到Nacos Sync，Nacos Sync会负责处理推送结果的可靠性和延时问题。 Nacos Sync和DNS-F都会主动拉取实例变更，但拉取周期和监听的服务数量会对变更时效产生影响。同时，网络的差异也会对推送结果产生影响。 为了解决这些问题，在业务进程中应禁用DNS缓存，以确保获取的服务列表是最新的。这样可以保证业务进程使用最新的服务列表进行注册和发现
3、心设计 Nacos
Nacos 有两套推送机制。一种是通过客户端来选择一个可获节点，比如它第一次拉取的是一个正常节点，这个正常节点就会跟它维护一个订阅关系，后面有变化就会有一个相应的实地变化推送给我。如果当前节点挂掉， 他会通过重连， 在节点列表上，连上一个正常的节点。这时候会有新的 DNS 关系出现。
另一种是通过 SDK 的方式，在服务端寻找可获节点。服务端每个节点之间， 会进行一个可活的探测， 选择其中一个可活节点用户维护这个订阅关系。 当这个节点出现问题， 连接断开后， SDK 重新发送订阅请求，服务端会再次选择另外一个可活的节点来维护这个订阅关系。这就保证整了推送过程不会因为某个节点挂掉而没有推送。
推送的效率方面，主要是用 UDP 的方式，这个效率不像 TCP 消耗那么高。
以上两个方案都比较适合我们目前的场景。
4、核心组件设计 Nacos Sync
选择 Nacos Sync 作为多集群数据同步的组件，主要是从以下4方面进行考虑的。
1.同步粒度： Nacos Sync以服务为维度进行数据同步，这样可以更容易实现最终一致性处理，并提供保活机制。相比较而言，数据库通过binlog同步受事务粒度限制，而文件同步只能以单个文件为粒度， 在服务同步的维度上不太适合。
2.可用性方面： Nacos Sync作为一个中间件，以集群方式运行，相比传统的单进程的数据库和文件方式，其可用性更为可靠，更能满足要求。
3.同步方式方面： Nacos Sync通过在服务粒度上进行全量写入，满足服务注册和DNS这两种场景，无需额外事务处理，能够保证最终一致性。
4.环形同步： 有多个接入点，希望它们之间的数据可以进行环形同步，每个节点之间相互备份，这时用Nacos Sync是支持的。虽然数据库方面比较经典的是主主同步，但如果同时对同一主件进行更新的话，每个节点之间协作会有问题，而且文件方式是不支持的。
5、Nacos Sync 和开源版本的不同
对 Nacos Sync 开源方案进行了几处修改以更好的适用于当前应用场景。
首先，通过配置方式将任务进行分割。由于实际应用场景中，Nacos Sync任务数量通常很大，达到一两万个，因此单个机器容易达到瓶颈。我们通过配置的方式将这些任务分片到多个 Nacos Sync机器上进行处理。其次，通过事件合并和队列控制方式来控制 Nacos 集群的写入量，以确保后端的稳定性。尽管事件下发速度每秒仅为一个，但在许多场景中，例如需要 K8s 或 Taf 进行数据同步时，变化的频率非常高。因此，通过事件合并，使每个服务都单独进行一个写入进程，并通过队列控制的方式来控制整个 Nacos 集群的写入量。最后，添加了支持从 K8s 和 Taf 同步数据的功能。计划将这种特性提交给 Nacos，以供更多的开发者使用。
6、核心组件设计 DNS - F
DNS - F是基于 CoreDNS 上开发的，扩展了以下 4 个组件：
Nacos插件：该插件通过查询Nacos服务信息，监听Nacos服务变化，并将这些服务转化为域名，实现以DNS协议为基础的服务发现。Nacos插件的引入让DNS-F更加便捷地实现了服务发现。
Cache插件：该插件提供域名缓存服务，提高了查询速度，并减轻了服务器压力。Log插件：该插件将DNS解析日志上报到日志服务，便于统计和监测DNS记录的查询情况，加强了对系统的监控和维护。 Proxy插件：该插件代理解析外部域名，将外部域名请求转发到上游DNS并缓存结果，从而减轻了网络负载和提高了解析速度。通过引入Proxy插件，DNS-F更加便利地与外部网络进行通信。
综上，DNS-F通过引入Nacos、Cache、Log和Proxy等插件，使其能够更好地应对服务发现和DNS解析过程中可能出现的问题，提高了系统的性能和可靠性
7、NS - F 和开源版本的不同
第一，在日志组件里面将日志上传到自己的日志服务。
第二，对缓存功能做了一个增强。一般的缓存功能可能根据 TTL 时间会过期，把这个过期时间给去掉了，直接令到缓存永远不会过期，然后通过异步将这个缓存进行刷新。比如 TTL 可能快到到时间了，我们就会主动做一个查询或者推送查询，这样，服务端或者公共 DNS 出现问题的时候，就不会影响到整体服务。
第三，增强了高可用的保障能力。包括进程监控、内部运营和外部运营的探测。另外，原来的开源版本用的是本机部署的方式，做成了集群化的部署，解决了服务推送、服务负载均衡方面的问题。
💖微服务实战
✨【微服务】SpringCloud的OpenFeign与Ribbon配置
✨Spring Cloud Alibaba微服务第29章之Rancher
✨Spring Cloud Alibaba微服务第27章之Jenkins
✨Spring Cloud Alibaba微服务第24章之Docker部署
✨Spring Cloud Alibaba微服务第23章之Oauth2授权码模式
✨Spring Cloud Alibaba微服务第22章之Oauth2
✨Spring Cloud Alibaba微服务第21章之分布式事务
✨Spring Cloud Alibaba微服务第18章之消息服务
✨Spring Cloud Alibaba微服务第16章之服务容错
✨Spring Cloud Alibaba微服务第14章之分库分表
✨Spring Cloud Alibaba微服务第11章之MyBatis-plus
✨Spring Cloud Alibaba微服务第8章之OpenFeign
✨Spring Cloud Alibaba微服务第7章之负载均衡Ribbon
✨SpringCloud Alibaba微服务第6章之Gateway
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
