利用解决spring-cloud-config莫名丢属性的问题了解各版本的发行过程
最后更新于
这有帮助吗？
最后更新于
这有帮助吗？
这个项目用的spring-cloud-config的远程配置文件
然后呢在启动的时候
他偶尔就会出现这种
找不到某一个属性的问题
但是呢这个属性其实是存在的
后来呢我就上网搜发现原来啊
spring-cloud官方有这个介绍
也就是说
默认他会把这个
配置文件克隆到一个临时目录里边
但是呢有一些系统啊
他会有一些规则
会定期清理这个临时目录的文件
所以呢我们解决方法可以把这个
spring cloud config这个服务啊
配置一个指定的目录
这样的话呢
这个目录里面的文件
就不会被定期清理掉
然后呢我就开始准备demo
想把这个问题记录下来
但是呢我在准备demo的过程中我发现
最新版的这个spring cloud config
是没有这个问题的
然后我就好奇
他到底是从哪个版本开始修复的
但是呢网上找了半天没有这个介绍
所以没办法我们只能自己去研究
首先呢我通过新旧版本的config-server对比
发现他们的行为不太一样
什么意思呢
比如说这个是那个临时部录
现在呢他就已经有一个文件被清掉了
我先把它checkout回来哈
大家看刚才就是这个文件被清掉了
对于新版本来说
虽然这个文件被清掉了
但是我们在请求这个配置的过程中啊
他会重新的把它checkout回来
就是还原回来
但是旧版本的就不会
那有了这个线索之后呢我们就可以
在本地调试了
调试的时候可以把源码下下来
这样的话呢我们就发现其实
影响这个问题的是这行代码
然后我们把这个项目整个克隆下来
看一下他这个提交记录
大家看 这行代码是在18年9月17号提交的
我们来看一下
在这里然后呢他在解决#1136和#
我们来看一下
screen cloud
然后config
先看
大家看这个问题
跟我们所说的其实不是同一个问题
他是在说这个属性开启之后啊
两个分支互相切换的问题
然后我们再看1138、1138呀
其实是个pull-request
大家看他还是1136这个问题
所以回到刚才这个问题其实是碰巧了
他在这个地方
解决另一个issues
然后咱们这个问题也被修复了
这个问题是在9月17号提交的
大家看在在这个分支
那这个分支叫什么名啊
大看这1.4点x合并的2.0点x
就说这个分支是1.4点x
比如说他在1.4点x上解决的这个问题
然后呢把代码合并到了2.0点x上
换句话说
从这个日期往后的1.4点x和2.0点x的版本
都没有问题了
那我们呢
也可以在这把这个Tag Names打开
这样的话呢我们再往上找
也可以找到他发布1.4的x的版本
大家看啊
这
这没有我们再往上
大看在这18年10月16号发布的一点四
点五瑞丽丝版
也就说1.4的版本
从这个地方往后都是可以的
我们再来看这个2.0的啊我们再回去
大概2.0的在这
还是我们从这往上找找这条线
连这
没有再往上找
点这打开
二点零点二点瑞
丽丝版本在10月24号发布的
但是呢
这个只是针对config server的一个版本
再来看一下sprint cloud官网的版本发布（历史）哈
是他的依赖
比如说
可乐的版本对应哪个部的版本
我们先来看一下这个
因为我们用的这个吗
大看这里边
他有发布日期6月8号
我们再来找18年
找到这18年10月23号
就是我们刚才看到的这个
这是10月24号
那
我们在这就可以看到
这个版本里边用到的config server
就是2.0.0了
比如说我们要是解决这个问题啊
就要把config server(口误：spring-cloud）切换到这个版本上
或者我们切换到刚才1.4点几的
1.4点几怎么找呢
我们还是回到这
应该是在这里
大家看specific cloud肯figa 4L网哈
这1.4.7不是这个
应该是这个1.4.
所以呢我们要么是采用
spring cloud 这个版本
要么呢我们就采用spring-cloud的
这个版本以后的
那说到这呢
我们再来看一下
spring-cloud版本的发布（过程）啊
大家看啊m版本
M3 M4 M5 M6一直到M
然后呢RC版本
M版本是里程碑版本
就说他在定里程碑
每个里程碑都有哪些功能
再往上呢
RC版本那从RC开始就不会加新功能了
大家看 RC1、RC
然后呢 release发行版
再往上呢就SR
针对发型版发现的问题进行修复
SR1、SR2、SR3
我们遇到的问题呢
就是在SR2上解决的
然后呢最后一直到
SR
不过呢从2020开始
啊他就采用年份字母标记了
大家看只不过呢
他在最后会标记一下这是个m版
大家看然后RC版
然后到最后呢
发行版的时候
他就会去掉后边那个标记他
2020.0.0、2020.0.1、2020.0.
他也没有SR版本了