Nacos入门
我的初衷是想搞一套适合自定义快速开发的框架，把一些必要的技术整合进来，第一想法是尝试下 SpringCloud Alibaba ，毕竟是阿里开发，适应国人需求，下载源码本打算研究下，看了nacos，就想到之前项目用的Eureka，而我也深知Eureka真的只是单纯的注册中心，需要配置属性还要依赖git做配置中心，所以改用nacos或许也是不错的主意，于是开始研究nacos
1.2. 部署配置
我这入门和普通的运行demo入门不一样，直接看源码说话，先把 SpringCloud Alibaba 的git代码下下来
由于nacos是个单独部署的服务，所以先去 Nacos官网 安装好nacos，账号密码都是 nacos ，修改配置文件nacos地址
1.3. 控制台配置
- 可以看到上述配置文件，明显一个dataId对应了一个配置文件，group做为分组参数，我们可以再nacos界面进行配置
点击发布，确认后就可以更新到应用，那么现在来研究它的原理
1.4. 调试分析
1.4.1. 获取配置
随意发布更新一个配置看到打印参数
那么进 ClientWorker 类，可以看到一个单独的线程池负责了数据的接收
其中核心的更新配置方法为 checkUpdateDataIds ，而该方法内部的核心方法为 checkUpdateConfigStr ，其核心内容如下
明显可以看到一个远程post调用的方法，此方法用来获取nacos的最新配置， 到这里可能要问了，明明是nacos修改配置推送给客户端，为什么是客户端调用服务端？这里nacos用了个巧妙的方法，设置较长的超时时间，看截图可以看出，超时时间为45秒，实际上nacos在30秒的时候若没有修改数据，就会返回空数据表示没有更新，若30秒以内有更新数据，则可以在这个45秒的请求中直接返回 ，看到这个设计我还真有点佩服作者脑洞的，这样做相当于把 心跳和数据传输结合起来了 ，不需要再额外搞个心跳连接，一旦nacos挂了，客户端就会报错，客户端在请求则nacos也知道客户端存活。我能想到的劣势，或许就是这样的长连接不能搞太多吧，但一般服务连接也够了
接下来进入方法 parseUpdateDataIdResponse ，该方法用来确认修改了哪份配置，真正修改系统配置的还要回去继续看
可以看到 changedGroupKeys 为改变的文件，nacos在拿到改变文件名称后，会通过 getServerConfig 方法主动去获取改变数据
之后通过 LocalConfigInfoProcessor.saveSnapshot 在本地存一个快照，更新本地缓存 cacheMap
1.4.2. 刷新配置
-
遍历缓存配置文件名
-
检测数据变化
- 刷新属性值
- 刷新容器，加载新的配置文件
-
加载对应环境配置文件
-
资源定位器
-
读取位置，这里读取的是故障转移文件，也就是可以放自己的配置文件在nacos故障的时候可以使用
- 一般没有故障转移文件，则远程调用获取正确配置
- 构建PropertySource
1.5. 总结
整个流程下来可以总结为几步
- 保持远程连接，拉取改变的文件名
- 根据拉取的文件名，dataId等参数获取真正的配置数据
- 更新缓存中配置，这里我发现好多地方都会经过
configFilterChainManager.doFilter(null, cr)，我通过反射添加了过滤器，结果一次文件更新会调用好多遍doFilter，目前没搞清它的意义是什么 - 发布配置更新事件
RefreshEvent，会重新加载propertySource，过程中会远程调用Nacos再次去调用最新配置
1.6. 问题
没想明白这冗余的设计，随着源码的深入，真的反转反转再反转，剧情跌宕起伏
propertySource propertySource configFilterChainManager.doFilter(null, cr) listener.receiveConfigInfo(contentTmp);
正文到此结束
热门推荐
相关文章
近期评论
-
666
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
