撸了一个简易的配置中心，顺带整合到了SpringCloud( 五 ) _生活百科

此时再次获取username

文章插图
可以看出，UserService代理对象没变，但是UserService对象已经变成了com.sanyou.configcenter.test.UserService@4237b3cd
此时获取到的username就已经变成了sanyou666

文章插图
所以，到这里就成功将我们自己写的那个简易版的配置中心整合到了SpringCloud中了。
不足和改进虽然我们这里的配置中心有了配置中心基本的功能，但是其实还有很多的不足和可以改进的地方。
1、配置变更推送问题问题前面也说过，在判断配置是否变更的时候，这里是每隔5s从服务端获取一次，这里就会可能5s之后才能感知到配置有变化，达不到真正时实的效果，并且由于这里是由客户端根据来判断，会导致无效的请求过多，因为可能配置压根没有变化，但是还是每隔5s获取一次配置信息，白白浪费资源
解决这个问题可以换成上面提到的push方式来做，或者将轮询方式改成长轮询的方式实现也是可以的，如果不清楚push、轮询、长轮询的，可以翻一下RocketMQ的push消费方式实现的太聪明了这篇文章。
2、高可用问题这里服务端的实例只有一个，不支持集群的方式，就会有单点故障的问题，不支持高可用。在实际项目中，肯定要支持集群的方式，保证即使有服务实例挂了，整个集群仍然可以继续对外提供服务，比如nacos就支持集群的方式，并且可以自由选择是使用AP模式还是CP模式。
3、通信协议和序列化协议对于通信协议，这里为了方便，我选择了客户端和服务端的通信方式是基于http协议的，当然也可以自定义协议，或者使用其它的协议，比如gRPC协议。其实在nacos2.x的版本中，nacos开始全面拥抱gRPC协议了。
至于序列化协议，这里选择了json协议，因为很简单、常见、使用范围广、跨语言，当然也可以选择其它的，比如hessian序列化协议等等。
4、多租户隔离一个合格的配置中心需要能支持不同应用的隔离，还有同一个应用不同环境的隔离，这里就图省事，直接就是有一个文件id来表示，虽然也可以做到隔离（不同系统用不同的文件id），但是这种方式比较low 。像nacos会自动根据配置的名称和后缀名之类的，生成文件id（dataId），同时还有分组的概念，其实就是为了做到隔离的效果。
5、鉴权鉴权是一个系统比较常见的东西，这里就不做过多赘述
6、控制页面上面所有对于配置的crud都是基于ApiPost来的，但是实际怎么也得通过一个页面来操作吧，至于这里我为啥不自己写个页面，给你个眼神自己体会~~
最后，本文代码地址：