利用解决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点几怎么找呢
我们还是回到这
应该是在这里
- 1.
大家看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开始