c++使用nacos_Nacos获取服务端配置和动态更新的源码分析(上)

前面两个spring boot2.x整合nacos系列的教程里面&＃xff0c;我们使用docker初步搭建了nacos单机版的服务端&＃xff0c;并且介绍了我们在平时开发的过程中&＃xff0c;如何正确高效的使用nacos&＃xff0c;让nacos无限的减少我们本地的配置&＃xff0c;本小节主要介绍我们在本地如何能够拉取到nacos服务端的配置的原理&＃xff0c;和源码基本讲解&＃xff0c;让大家知道其中的基本流程&＃xff0c;并且能够掌握其中的源码技巧&＃xff0c;希望大家在有的工作中&＃xff0c;能够有机会去使用这些优秀源码的技巧&＃xff0c;让我们平时的业务代码写的更加精致

tips&＃xff1a;本小节大概阅读的时间在20分钟&＃xff0c;分上下两小节&＃xff0c;如果您能静下心来安心地读完&＃xff0c;相信你会觉得受益匪浅&＃xff0c;最后希望大家一起进步~本文为原创&＃xff0c;如果您希望&＃xff0c;帮忙关注一下&＃xff0c;您的支持是我写作最大的动力~

首先&＃xff0c;在阅读源码之前&＃xff0c;我们先找到阅读源码的入口&＃xff0c;在nacos的源代码中&＃xff0c;子项目example中有一个示例类ConfigExample&＃xff0c;我们先运行一下&＃xff0c;看下效果

com.alibaba.nacos.example.ConfigExample

源代码示例如下

最基本的main函数nacos客户端获取服务端数据方法示例

运行main函数&＃xff0c;我们可以成功的看到控制台打印输出如下

运行结果

我们粗略地看下ConfigExample的main函数实现&＃xff0c;我们指定了nacos服务端的地址IP&＃xff0c;dataId&＃xff0c;groupId&＃xff0c;namespace 然后我们就可以获取到服务端返回给我们的数据&＃xff0c;从这一点可以明确一个远程的properties的唯一标识是如下几个因素可以确认

1. groupId
2. dataId
3. namespace

我们回到刚才的源代码&＃xff0c;我们还配置了一个listener&＃xff0c;nacos最大的一个特性就是支持热更新&＃xff0c;当nacos服务端的properties更新的时候&＃xff0c;所有的客户端(具体说来&＃xff0c;是订阅过对应dataId&＃xff0c;groupId的客户端)都能"立即"(具体说应该是准实时)感知到服务端的数据变更&＃xff0c;我们看下当注册一个如下的listener的时候&＃xff0c;我们修改一下配置中心的属性&＃xff0c;看看该listener能不能感知到变化

我们在nacos的服务端的namespace为dev&＃xff0c;dataId为oms,groupId为product_center下修改数据&＃xff0c;点击发布

我们能发现控制台出现了我们意料之中的变化&＃xff0c;nacos的客户端感知到了服务端的数据变化

本章节&＃xff0c;我们就介绍一下如下2个内容

1. 客户端如何拉取服务端的配置信息
2. 客户端如何感知到服务端的配置变化(重点)

1.Servlet3.0新特性&＃xff0c;异步处理的支持

servlet3.0开始开始支持异步处理&＃xff0c;所谓的异步处理就是&＃xff0c;当servlet接受到请求的时候&＃xff0c;可能需要一段耗时很长的业务处理时间&＃xff0c;这个时候业务线程就是tomcat或者其他web容器的servlet线程&＃xff0c;这个线程就会一直消耗在处理业务线程上来&＃xff0c;无法得到释放&＃xff0c;如果大量客户端请求到来的时候&＃xff0c;web容器就没有剩余线程处理业务逻辑&＃xff0c;这就会影响性能&＃xff0c;所以servlet3.0开始有了一个新的特性:servlet的线程接受到请求之后&＃xff0c;把逻辑复杂耗时时间长的操作交给异步线程&＃xff0c;自己则回归到web容器线程池中&＃xff0c;这样能够快速地释放servlet线程&＃xff0c;得到资源的最大利用&＃xff0c;异步线程处理结束之后&＃xff0c;可以返回web服务器端的响应数据(以后有机会做一个spring boot 整个异步处理新特性的文章)

2.ScheduledExecutorService处理类的scheduledWithFixedDelay方法的含义&＃xff0c;四个参数

1. 第一个Runnable&＃xff0c;表示要执行的任务函数体
2. 第二个参数initialDelay&＃xff1a;表示第一个任务开始执行的延迟执行时间
3. 第三个参数delay:表示上一个任务执行结束之后&＃xff0c;下一个任务执行的时间&＃xff0c;这边必须要注意的是上一个任务执行完之后开始计时的延迟时间
4. 第四个参数Timeout&＃xff0c;时间单位

3.ScheduledExecutorService处理类的schedule方法&＃xff0c;这个方法表示延迟执行&＃xff0c;且只调度一次&＃xff0c;这个方法返回一个future对象&＃xff0c;可以通过future.get,cancel等方法进行一些操作&＃xff0c;来达到我们要的效果

以上三个就是我们在本章需要拥有的基本知识点&＃xff0c;在接下来的核心源码分析中&＃xff0c;了解这些你就会有事半功倍的效果&＃xff0c;这边先卖一个关子

我个人觉得阅读源码之前&＃xff0c;我们一定要想好为什么要阅读源码&＃xff0c;要解决我们什么困惑&＃xff0c;带着问题去看源码&＃xff0c;这样我们就能在看源码的过程中&＃xff0c;不迷失方向

1.我们之前说过nacos是典型的C/S架构&＃xff0c;如果客户端想要获取服务端的properties配置信息&＃xff0c;根据服务端的地址&＃xff0c;dataId&＃xff0c;groupId&＃xff0c;namespace应该说发送一个http请求就可以成功获取到信息&＃xff0c;如果这个代码给我们写是不是写一个httpClient请求就可以完成获取属性的操作了&＃xff1f;感觉这样并不是很难

2.客户端是如何获取到nacos属性变更通知的&＃xff0c;是服务端主动通知的&＃xff0c;还是客户端有一个定时任务不断地去查询对应的dataId&＃xff0c;group组下的properties是否有变更呢&＃xff0c;其实这个问题就是我们经常说的推拉模型&＃xff0c;按照目前所有主流框架的逻辑&＃xff0c;应该不是推模式&＃xff0c;因为如果使用服务端变更的时候&＃xff0c;服务端主动通知客户端属性变更&＃xff0c;服务端的性能会成很大的问题&＃xff0c;首先你要保持很多的长连接&＃xff0c;还有就是当客户端很多的时候&＃xff0c;监听的节点数以万计的时候&＃xff0c;服务端的性能应该就是很大的问题&＃xff0c;所以初步定论&＃xff0c;现代优秀的nacos框架&＃xff0c;不应该会是推模型

至于为什么不是"推"模型&＃xff0c;还有一个经验问题

1.zookeeper有一个watch的机制&＃xff0c;现在zookeeper的性能一直是大家所诟病的&＃xff0c;当zookeeper的被watch的节点很多的时候&＃xff0c;或者watch的客户端很多的时候&＃xff0c;因为zookeeper就是使用推模型&＃xff0c;会导致zookeeper服务端性能急剧下降&＃xff0c;推送的不及时

2.看过阿里巴巴另一个优秀的消息中间件RocketMQ的人应该都知道RocketMQ使用的就是拉模型&＃xff0c;解决的就是服务端性能的问题&＃xff0c;使用的是"长轮询"的方式&＃xff0c;所以这边猜想&＃xff0c;同样是阿里中间件团队&＃xff0c;应该也会考虑到这个问题(RocketMQ的整合和源码阅读以后也会一起整理)

带着如上的2个问题就开始进行源代码的阅读&＃xff0c;应该会很轻松

回到我们刚才的测试代码ConfigExample的入口&＃xff0c;可以看到源代码中使用NacosFactory的#createConfigService方法&＃xff0c;返回了一个ConfigService

ConfigService明显就是一个核心接口&＃xff0c;方法列表如下&＃xff0c;根据方法名&＃xff0c;有getConfig&＃xff0c;addListener等我们需要的一些客户端常用的方法&＃xff0c;所以我们这边应该深入这个方法的研究

ConfigService的方法列表

我们可以看到这边跟我们平时想象的不一样&＃xff0c;一般factory的静态方法都是返回的一个单例&＃xff0c;而这边却是使用反射创建一个继承ConfigService的实现类的NacosConfigService

反射创建NacosConfigService

我们可以重点关注一下NacosConfigService的构造函数&＃xff0c;源代码如下&＃xff0c;配置好编码格式和namespace之后&＃xff0c;我们重点看下下面源码中&＃xff0c;红框标注的2个部分&＃xff0c;第一个部分是用装饰者模式创建的带有统计的httpclient&＃xff0c;名字叫做ServerHttpAgent&＃xff0c;跟我们设想的一样&＃xff0c;也是使用http协议与nacos服务端进行交互的&＃xff0c;那么获取服务端的配置信息&＃xff0c;应该并不难&＃xff0c;然后又创建了一个ClientWorker&＃xff0c;顾名思义&＃xff0c;感觉这个类就是nacos客户端的总代理一样&＃xff0c;应该所有的核心逻辑操作就在这边了&＃xff0c;接下来我们应该会跟这个ClientWorker多次打交道

回到我们刚才的main函数&＃xff0c;获取配置属性的地方&＃xff0c;方法名叫做getConfig的地方

我们可以跟踪源码分析&＃xff0c;很容易就看到具体在NacosConfigService中的实现方法getConfigInner&＃xff0c;可以看到第一段逻辑代码就是优先获取本地的关于dataId&＃xff0c;groupId&＃xff0c;namespace的配置&＃xff0c;如果能获取到则优先返回&＃xff0c;为什么优先获取本地呢&＃xff0c;其实nacos也是做出了性能考虑&＃xff0c;否则每次都去查询服务器端的数据&＃xff0c;这样会导致服务器端的压力负载过大&＃xff0c;特别是成千上万个节点连接到服务器端的时候&＃xff0c;所以优先读取本地配置

如果本地文件不存在对应的配置&＃xff0c;相当于本地缓存没有&＃xff0c;这种情况一般都是第一次请求的时候&＃xff0c;本地没有缓存&＃xff0c;这个时候就需要请求服务端数据&＃xff0c;接着看源码&＃xff0c;我们可以看到接下来就是使用worker去获取服务端的数据了&＃xff0c;也就是前面构造函数初始化好的clientworker

我们感觉快接近真相大白了&＃xff0c;我们接着看clientworker的getServerConfig方法&＃xff0c;我们之前说的使用httpClient获取数据&＃xff0c;这边也是这么做的&＃xff0c;具体的参数&＃xff0c;我在下图的源码中都一一说明标注了一下&＃xff0c;最后请求的地址应该是http://ip:8848/v1/cs/configs的Get请求&＃xff0c;服务端获取配置信息的源码&＃xff0c;我们下几个小节分析&＃xff0c;在这边我们只关注获取数据的逻辑&＃xff0c;最后客户端成功获取到了服务器端的数据&＃xff0c;总而言之&＃xff0c;还是比较简单的

使用httpclient去获取服务端的配置信息

接下来就有一段基本的逻辑处理&＃xff0c;大家也不要忘记&＃xff0c;把从服务端获取到的数据持久化到本地磁盘&＃xff0c;这样就可以与刚才优先获取本地的配置做到相呼应了&＃xff0c;可以看到当与服务端交互&＃xff0c;服务端返回成功或者没找到的时候&＃xff0c;都可以将信息持久化到本地磁盘&＃xff0c;这样就可以很方便地优先从本地获取了

持久化到本地磁盘

到此为止&＃xff0c;客户端获取到服务端的配置信息&＃xff0c;主体流程已经分析结束了&＃xff0c;接下来就要分析客户端如何感知到服务端的配置变更了

本小节内容相对比较简单&＃xff0c;也是我们阅读源码的第一篇文章&＃xff0c;主要目的就是希望大家在阅读源码之前&＃xff0c;有一些自己的思考&＃xff0c;带着问题&＃xff0c;和带着自己的想法去阅读源码&＃xff0c;想着如果是自己应该怎么实现&＃xff0c;这些写中间件的大牛又是怎么实现的&＃xff0c;这样当看到别人实现的亮点的时候&＃xff0c;以后自己就可以去模仿&＃xff0c;去"抄写"&＃xff0c;慢慢地就会变得更加强大一点&＃xff0c;与大牛的差距就会慢慢地缩小一些

废话不多说&＃xff0c;还是总结一下吧&＃xff0c;nacos客户端获取服务端的配置信息&＃xff0c;还是比较简单的&＃xff0c;依靠clientworker去获取&＃xff0c;这是一个核心类&＃xff0c;优先获取本地的配置&＃xff0c;如果本地没有缓存&＃xff0c;就去获取nacos服务器端的数据

下一个小节&＃xff0c;应该就是本小节的重点内容&＃xff0c;如何客户端如何感知到服务器端的数据变化&＃xff0c;客户端感知到变化之后&＃xff0c;更新本地磁盘的配置信息&＃xff0c;这样就可以永远保持本地磁盘是最新的配置信息了~

如果您看到这里&＃xff0c;觉得我写的不错的话&＃xff0c;希望您点一个关注&＃xff0c;或者你现在没有时间看的话&＃xff0c;点一个收藏&＃xff0c;在您闲暇的时候&＃xff0c;翻阅看看&＃xff0c;相信我们可以一起学习进步&＃xff0c;如果写的有不对的地方&＃xff0c;欢迎批评指出