硬核!8个类手写一个配置中心! 原创
配置中心是我们平常使用微服务架构时重要的一个模块,常用的配置中心组件也比较多,从早期的Spring Cloud Config,到Disconf、Apollo、Nacos等,它们支持的功能、产品的性能以及给用户的体验也各有不同。
虽然说功能上有不少差异,但是它们解决的最核心问题,无疑是配置文件修改后的实时生效,有时候在搬砖之余Hydra就在好奇实时生效是如何实现的、如果让我来设计又会怎么去实现,于是这几天抽出了点空闲时间,摸鱼摸出了个简易版的单机配置中心,先来看看效果:
之所以说是简易版本,首先是因为实现的核心功能就只有配置修改后实时生效,并且代码的实现也非常简单,一共只用了8个类就实现了这个核心功能,看一下代码的结构,核心类就是core
包中的这8个类:
看到这是不是有点好奇,虽说是低配版,就凭这么几个类也能实现一个配置中心?那么先看一下总体的设计流程,下面我们再细说代码。
代码简要说明
下面对8个核心类进行一下简要说明并贴出核心代码,有的类中代码比较长,可能对手机浏览的小伙伴不是非常友好,建议收藏后以后电脑浏览器打开(骗波收藏,计划通!)。另外Hydra已经把项目的全部代码上传到了git
,有需要的小伙伴可以移步文末获取地址。
1、ScanRunner
ScanRunner
实现了CommandLineRunner
接口,可以保证它在springboot启动最后执行,这样就能确保其他的Bean已经实例化结束并被放入了容器中。至于为什么起名叫ScanRunner
,是因为这里要实现的主要就是扫描类相关功能。先看一下代码:
真正实现文件扫描功能是调用的FileScanner
,它的实现我们后面具体再说,在功能上它能够根据文件后缀名扫描某一目录下的全部文件,这里首先扫描出了target
目录下全部以.class
结尾的文件:
扫描到全部class
文件后,就可以利用类的全限定名获取到类的Class
对象,下一步是调用doFilter
方法对类进行过滤。这里我们暂时仅考虑通过@Value
注解的方式注入配置文件中属性值的方式,那么下一个问题来了,什么类中的@Value
注解会生效呢?答案是通过@Component
、@Controller
、@Service
这些注解交给spring容器管理的类。
综上,我们通过这些注解再次进行过滤出符合条件的类,找到后交给VariablePool
对变量进行处理。
2、FileScanner
FileScanner
是扫描文件的工具类,它可以根据文件后缀名筛选出需要的某个类型的文件,除了在ScanRunner
中用它扫描了class文件外,在后面的逻辑中还会用它扫描yml文件。下面,看一下FileScanner
中实现的文件扫描的具体代码:
查找文件的逻辑很简单,就是在给定的根目录rootPath
下,循环遍历每一个目录,对找到的文件再进行后缀名的比对,如果符合条件就加到返回的文件名列表中。
至于下面的这个getRealRootPath
方法,是因为在windows环境下,获取到项目的运行目录是这样的:
而class文件名是这样的:
如果想要获取一个类的全限定名,那么首先要去掉运行目录,再把文件名中的反斜杠\
替换成点.
,这里就是为了删掉文件名中的运行路径提前做好准备。
3、VariablePool
回到上面的主流程中,每个在ScanRunner
中扫描出的带有@Component
、@Controller
、@Service
注解的Class
,都会交给VariablePool
进行处理。顾名思义,VariablePool
就是变量池的意思,下面会用这个容器封装所有带@Value
注解的属性。
简单说一下这块代码的设计思路:
- 通过反射拿到
Class
对象中所有的属性,并判断属性是否加了@Value
注解 @Value
如果要注入配置文件中的值,一定要符合${xxx}
的格式(这里先暂时不考虑${xxx:defaultValue}
这种设置了默认值的格式),所以需要使用正则表达式验证是否符合,并校验通过后去掉开头的${
和结尾的}
,获取真正对应的配置文件中的字段VariablePool
中声明了一个静态HashMap,用于存放所有配置文件中属性-类-类中属性的映射关系,接下来就要把这个关系存放到这个pool
中
简单来说,变量池就是下面这样的结构:
这里如果不好理解的话可以看看例子,我们引入两个测试Service
:
在所有Class
执行完add
方法后,变量池pool
中的数据是这样的:
可以看到在pool
中,person.name
对应的内层Map中包含了两条数据,分别是UserService
中的name
字段,以及UserDeptService
中的pname
字段。
4、EnvInitializer
在VariablePool
封装完所有变量数据后,ScanRunner
会调用EnvInitializer
的init
方法,开始对yml文件进行解析,完成配置中心环境的初始化。其实说白了,这个环境就是一个静态的HashMap,key
是属性名,value
就是属性的值。
首先还是使用FileScanner
扫描根目录下所有的.yml
结尾的文件,并使用spring自带的YamlMapFactoryBean
进行yml文件的解析。但是这里有一个问题,所有yml文件解析后都会生成一个独立的Map,需要进行Map的合并,生成一份配置信息表。至于这一块具体的操作,都交给了下面的YamlConverter
进行处理。
我们先进行一下演示,准备两个yml文件,配置文件一:application.yml
配置文件二:config/test.yml
先来看一看环境完成初始化后,生成的数据格式是这样的:
5、YamlConverter
YamlConverter
主要实现的方法有三个:
doConvert()
:将EnvInitializer
中提供的多个Map合并成一个单层MapmonoToMultiLayer()
:将单层Map转换为多层Map(为了生成yml格式字符串)convert()
:yml格式的字符串解析为Map(为了判断属性是否发生变化)
由于后面两个功能暂时还没有涉及,我们先看第一段代码:
逻辑也很简单,通过循环遍历的方式,将多个Map最终都合并到了目的envMap
中,并且如果遇到多层Map嵌套的情况,那么将多层Map的key通过点.
进行了连接,最终得到了上面那张图中样式的单层Map。
其余两个方法,我们在下面使用到的场景再说。
6、ConfigController
ConfigController
作为控制器,用于和前端进行交互,只有两个接口save
和get
,下面分别介绍。
get
前端页面在开启时会调用ConfigController
中的get
接口,填充到textArea
中。先看一下get
方法的实现:
之前在项目启动时,就已经把配置文件属性封装到了EnvInitializer
的envMap
中,并且这个envMap
是一个单层的Map,不存在嵌套关系。但是我们这里要使用jackson
生成标准格式的yml文档,这种格式不符合要求,需要将它还原成一个具有层级关系的多层Map,就需要调用YamlConverter
的monoToMultiLayer()
方法。
monoToMultiLayer()
方法的代码有点长,就不贴在这里了,主要是根据key中的.
进行拆分并不断创建子级的Map,转换完成后得到的多层Map数据如下:
在获得这种格式后的Map后,就可以调用jackson
中的方法将Map转换为yml格式的字符串传递给前端了,看一下处理完成后返回给前端的字符串:
save
在前端页面修改了yml内容后点击保存时,会调用save
方法保存并更新配置,方法的实现如下:
在拿到前端传过来的yml字符串后,调用PropertyTrigger
的change
方法,实现后续的更改逻辑。
7、PropertyTrigger
在调用change
方法后,主要做的事情有两件:
- 修改
EnvInitializer
中的环境envMap
,用于前端页面刷新时返回新的数据,以及下一次属性改变时进行对比使用 - 修改bean中属性的值,这也是整个配置中心最重要的功能
先看一下代码:
前面铺垫了那么多,其实就是为了实现这段代码中的功能,具体逻辑如下:
- 调用
YamlConverter
的convert
方法,将前端传来的yml格式字符串解析封装成单层Map,数据格式和EnvInitializer
中的envMap
相同 - 遍历旧的
envMap
,查看其中的key在新的Map中对应的属性值是否发生了改变,如果没有改变则不做之后的任何操作 - 如果发生改变,用新的值替换
envMap
中的旧值 - 通过属性名称,从
VariablePool
中拿到涉及改变的Class
,以及类中的字段Field
。并通过后面的SpringContextUtil
中的方法获取到这个bean的实例对象,再通过反射改变字段的值 - 将修改后的Map写回
EnvInitializer
中的envMap
到这里,就实现了全部的功能。
8、SpringContextUtil
SpringContextUtil
通过实现ApplicationContextAware
接口获得了spring容器,而通过容器的getBean()
方法就可以容易的拿到spring中的bean,方便进行后续的更改操作。
9、前端代码
至于前端代码,就是一个非常简单的表单,代码的话可以移步git
查看。
最后
到这里全部的代码介绍完了,最后做一个简要的总结吧,虽然通过这几个类能够实现一个简易版的配置中心功能,但是还有不少的缺陷,例如:
- 没有处理
@ConfigurationProperties
注解 - 只处理了yml文件,没有处理properties文件
- 目前处理的bean都是基于
singleton
模式,如果作用域为prototype
,也会存在问题 - 反射性能低,如果某个属性涉及的类很多会影响性能
- 目前只能代码嵌入到项目中使用,还不支持单独部署及远程注册功能
- ……
总的来说,后续需要完善的点还有不少,真是感觉任重道远。
最后再聊聊项目的名称,为什么取名叫hermit-purple
呢,来源是jojo中二乔的替身隐者之紫,感觉这个替身的能力和配置中心的感知功能还是蛮搭配的,所以就用了这个哈哈。
那么这次的分享就到这里,我是Hydra,预祝大家虎年春节快乐,我们下篇再见。
项目git地址:
https://github.com/trunks2008/hermit-purple-config
大家如果对代码有建议或者好的idea,欢迎在后台留言或加我微信好友一起讨论。
作者简介,码农参上,一个热爱分享的公众号,有趣、深入、直接,与你聊聊技术。
看不懂,不知所云
都是java基础啊^_^
大佬我看你的代码,为什么不把这些加载读取的这些步骤用一个类封装,比如初始化为一个方法、读取@component这些注解为一个方法、@value注解一个方法、更新数据一个方法,维护的Map就放在一个类里更好管理,我的想法就是这样写,不知道为什么要弄个架子跳过去