博主介绍：✌全网粉丝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套》

https://blog.csdn.net/qq_57756904/category_12199600.html

一、高可用

1、全球化部署方案

2、线上演练

3、线上演练数据校验机制

4、增量校验方式如下：

5、DNF - S 高可用

二、具体的实践和落地

1、实践一：数据库域名改造

2、实践二：内部调用使用内部域名

三、后续规划

💖微服务实战

一、高可用

1、全球化部署方案

这是虎牙公司的全球化部署方案。他们在全球部署了两个大区，一个是国内大区，一个是国外大区，这两个大区通过专线服务同步，以保证同步的稳定性。每个大区内又部署了多个接入点，例如，在国内大区内，他们在深圳和无锡两个接入点部署了数据，这两个接入点的数据互相同步、互为备份，以保证在一个集群下线时，还可以快速地切换到另一个集群。在多个接入点的情况下，虎牙公司通过 HttpDNS 实现客户端的就近接入，客户端会定期请求 HttpDNS，HttpDNS 能根据地域寻找就近的接入点。如果某个接入点出现故障，虎牙公司就会在 HttpDNS 中删除该节点，这样客户端就能快速地切换到另一个接入点。接下来讲一下单个集群下的部署方案。

单个集群部署了多个 Nacos 节点，并通过7层负载均衡的方式暴露给外面使用，并且提供了多个 VIP，满足不同线路和区域的接入要求。同时，Nacos Sync 做了分片处理，将同步压力分散到各个分片上，一个分片下我们又部署了多个 Nacos Sync 的节点，以保障多活和高可用。

2、线上演练

演练的场景是模拟一个单个集群挂了和两个集群都挂了。从图中可以看到，把深圳的流量切走之后，无锡的流量就涨上去了，然后再把无锡的流量切走，再关闭服务，这样就可以看到两边的流量已经没了。之后，再去恢复两个集群的流量，看一下整个切换过程中对服务的影响。

首先看一下对写入的影响，在单个集群挂了的情况下，是没有任何影响的。如果是两个集群都挂了，写入就会失败。可以看到，这个图有一个波峰，这个波峰就是两个集群都挂了的情况下，写入失败延迟加大。

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

可用性级别方面，我们可以保障：

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

3、线上演练数据校验机制

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

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

4、增量校验方式如下：

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

5、DNF - S 高可用

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

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

二、具体的实践和落地

1、实践一：数据库域名改造

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

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

在正在进行的改造中，下图显示了正在进行的操作。DMX是虎牙内部的一个数据库管理系统，思路是将DMX与名称服务对接。DMX通过名称服务将数据库实例信息注册为服务名称，该名称也是域名。在实际的应用过程中，应用程序将通过该域名访问数据库。访问前，应用程序会通过 DNS-F 进行域名解析。DNS-F将从名称服务中查询实例信息，并返回实例IP，从而应用程序可以与数据库实例进行连接。在切换实例时，只需在DMX平台上修改域名对应的实例信息，并将更改推送到名称服务。名称服务将通知 DNS-F 更新新的 IP，以便应用程序在下一次解析时获取新的实例 IP。使用此方法，已成功地实现了虎牙数据库实例的快速切换，通常不到10秒钟。

2、实践二：内部调用使用内部域名

虎牙内部系统间通信的调用涉及七层负载均衡。但现行系统缺乏内部 DNS，故需要使用公共 LocalDNS 来进行解析。

这一方法带来了以下问题：

1. 扩缩容时需修改 DNS 记录，且使整个过程生效需要超过10 分钟，因此节点的故障会对业务产生较长时间的影响。

2. 公共 LocalDNS 智能解析的准确度可能不高，例如无锡的机器可能会被解析成深圳的一个接入点，从而影响接入质量。

3. 公共 LocalDNS 不支持特定的负载均衡策略，例如优先考虑同机房、同大区的机器，这种策略无法通过公共 LocalDNS 实现。

为了提升内部服务调用的质量，可以采取以下措施：

1. 绕过公共 LocalDNS，将 DNS 记录的变更直接推到 DNS-F 上。这样能够避免修改 DNS 记录时对生效时间的影响。

2.与内部系统打通，从 CMDB 等内部系统获取机器信息，以支持更多的负载均衡策略。例如同机房、同大区优先的策略，可以和其他内部系统结合使用来实现负载均衡。

请查看上方的图表。这里的改造与数据库域名的改造思路类似。在最右上角，有一个7层负载管理系统，将其与名字服务连接，将域名信息注册为服务形式，并从7层负载管理系统直接向名字服务推送域名记录更改，名字服务再将其推送到DNS-F，以实现快速切换。如果配置了负载均衡策略，名字服务将从CMDB获取机器、机房等信息，并将其打上标记添加到域名的实例信息中。然后，DNS-F查询名字服务时，将携带ClientIp，名字服务根据ClientIp的CMDB信息过滤实例列表，并返回同机房的实例给DNS-F，实现同机房优先的目的。从中带来的效果是：

第一，服务的扩展和收缩现在能够在秒级完成，减少了故障时间。

第二，扩展了DNS的负载均衡策略。例如，在某些业务中，需要在不同的区域设置不同的接入点，而且不能跨区域调用。之前的DNS 负载均衡策略无法满足此要求，但在改造后，可以根据CMDB信息进行同区域的负载平衡调度。

第三，业务在接入内部域名后，延迟显著降低。上图显示的是某项服务在接入内部域名后，延迟明显减少的信息。另一个落地的效果是，对主机上的域名解析进行了优化。

因为DNS-F部署在每台主机上，提供缓存功能。这带来的效果是： - 平均解析延迟从之前的200毫秒降至现在的1毫秒。

通过对缓存系统的优化，在 CoreDNS 原生 Cache 的基础上，将命中率从之前的90% 提高到了99.8%，同时将解析失败率从0.1%降低到了0%。这些改进体现了项目落地的技术价值，其中第一项是提供了基于 DNS服务发现的能力，为消除异构系统互相调用的障碍提供了有力支持；第二项填补了没有内部域名解析能力的空缺；第三项解决了内部服务调用面临的挑战：延时大、解析不准、不支持多种负载均衡策略、故障牵引慢；第四项则改善了外部域名解析的质量，屏蔽了 LocalDNS 的故障。总体来说，此次优化提高了 DNS - F 覆盖率100%的规模，完成了 Taf 和 Eureka注册中心的数据同步。

三、后续规划

LocalDNS:为了提高域名解析的准确性，将解决公共 DNS 节点位置带来的影响。同时，还将解决内部使用公共 DNS 不稳定的问题，并优化内外网解析的效率。
精准调度:为了解决全球 DNS 节点生效缓慢的问题，将进行精确计划和调度。这将有助于提高 DNS 节点的响应速度并优化全球的用户访问体验。

💖微服务实战

✨【微服务】SpringCloud的OpenFeign与Ribbon配置

✨集Oauth2+Jwt实现单点登录

✨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

✨SpringCloud Alibaba微服务第4章之Nacos

✨SpringCloud Alibaba微服务开篇