Nacos

最新推荐文章于 2024-09-05 10:12:37 发布

qq_16082733

最新推荐文章于 2024-09-05 10:12:37 发布

阅读量125

点赞数

文章标签： java 微服务 spring cloud

本文链接：https://blog.csdn.net/qq_16082733/article/details/131227488

版权

Nacos

一、简介

Nacos 是阿里巴巴推出的Spring Cloud Alibaba 组件中的注册中心，主要是为了解决：动态配置管理，服务注册发现的问题，

同时支持Dubbo，还对Spring Cloud，Kubernetes，Istio有所兼容。 Eureka的配置中心需要配合 Spring cloud config ，git使用，而

Nacos自身便可以启动配置中心的作用，另外还支持CP。

二、Nacos配置中心原理分析

动态配置管理是 Nacos 的功能之一，通过动态配置服务，我们可以在所有环境中以集中和动态的方式管理所有应用程序或服务的配置信息。

动态配置中心可以实现配置更新时无需重新部署应用程序和服务即可使相应的配置信息生效，这极大了增加了系统的运维能力。

Nacos 服务端保存了配置信息，客户端连接到服务端之后，根据 dataID，group可以获取到具体的配置信息，当服务端的配置发生变更时，客户端会收到通知。当客户端拿到变更后的最新配置信息后，就可以做自己的处理了，这非常有用，所有需要使用配置的场景都可以通过 Nacos 来进行管理。

可以说 Nacos 有很多的适用场景，包括但不限于以下这些情况：

数据库连接信息
限流规则和降级开关
流量的动态调度

原理：

Nacos客户端会有一个线程池会不停的执行****LongPollingRunnable#run**方法，这个方法主要作用就是从服务端拉取最新的配置信息，如果直接按照正常的做法来做，直接根据dataId group tenant**去拉取就好了，如果每次都直接去服务器来配置信息，但这样会有一些性能问题：

配置信息变动的可能性很小，如果每次都需要全量去拉取，拉取的信息基本都是一样的，这很浪费资源；
如果从服务端拉取数据的频率太高，会太耗性能；如果拉取的频率太低，数据发生变更之后客户端响应不及时；

针对上面几个问题，Nacos做了以下几个优化

只拉取改动过的配置信息：客户端先通过一个HTTP请求发送一个**key列表给服务端，服务端返回发生了变更的Key列表**，大部分时候，这可以过滤掉绝大部分没有配置项；
通过HTTP长轮询减少少客户端和服务端的交互频率

三、问题总结

客户端长轮询的响应时间会受什么影响

客户端长轮询的响应时间，设置的是30s，但是有时响应很快，有时响应很慢，这取决于服务端的配置有没有发生变化。当配置发生变化时，响应很快就会返回，当配置一直没有发生变化时，会等到 29.5s 之后再进行响应。

为什么更改了配置信息后客户端会立即得到响应

因为服务端会在更改了配置信息后，找到具体的客户端请求中的 response，然后直接将结果写入 response 中，就像服务端对客户端进行的数据 “推送” 一样，所以客户端会很快得到响应。

客户端的超时时间为什么要设置为30s

这应该是一个经验值，该超时时间关系到服务端调度任务的等待时间，服务端在前29.5s 只需要进行等待，最后的 0.5s 才进行配置变更检查。

如果设置的太短，那服务端等待的时间就太短，如果这时配置变更的比较频繁，那很可能无法在等待期对客户端做推送，而是滑动到检查期对数据进行检查后才能将数据变更发回给客户端，检查期相比等待期需要进行数据的检查，涉及到 IO 操作，而 IO 操作是比较昂贵的，我们应该尽量在等待期就将数据变更发送给客户端。

http 请求本来就是无状态的，所以没必要也不能将超时时间设置的太长，这样是对资源的一种浪费。

四、结论

1、客户端的请求到达服务端后，服务端将该请求加入到一个叫 allSubs 的队列中，等待配置发生变更时 DataChangeTask 主动去触发，并将变更后的数据写入响应对象，如下图所示：

2、与此同时服务端也将该请求封装成一个调度任务去执行，等待调度的期间就是等待 DataChangeTask 主动触发的，如果延迟时间到了 DataChangeTask 还未触发的话，则调度任务开始执行数据变更的检查，然后将检查的结果写入响应对象，如下图所示：

基于上述的分析，最终总结了以下结论：

1.Nacos 客户端会循环请求服务端变更的数据，并且超时时间设置为30s，当配置发生变化时，请求的响应会立即返回，否则会一直等到 29.5s+ 之后再返回响应
2.Nacos 客户端能够实时感知到服务端配置发生了变化。
3.实时感知是建立在客户端拉和服务端“推”的基础上，但是这里的服务端“推”需要打上引号，因为服务端和客户端直接本质上还是通过 http 进行数据通讯的，之所以有“推”的感觉，是因为服务端主动将变更后的数据通过 http 的 response 对象提前写入了。

至此，正如标题所说的，推+拉打造 Nacos 配置信息的实时更新的原理已经分析清楚了。