配置服务
和SpringCloud类似,可以对应用的配置和资源文件进行集中管理,支持按项目、项目版本、应用、应用版本、运行环境,对配置和资源文件按版本进行分类管理。 目前本框架提供的配置服务暂时还不支持即时推送,如果配置发生变动,需要重启服务才能获取,后续版本将会支持热更新。
#
配置服务器配置服务可以作为单独的应用启动,也可以和其他应用整合在一起工作,下面是一个独立的配置服务节点:
由于配置服务工作负载不大,可以和其他服务整合在一起,下面是一个工作节点附加配置服务的例子:
该节点提供业务服务的同时也提供配置服务。综上所述,任何一个应用挂载ConfigServerModule模块,即可提供配置服务。 以上是配置服务零配置启动模式,可以根据需要对配置服务进行增强设定,例如仓库路径设置、增加安全认证等。见下面的例子:
#
配置资源仓库有了配置服务器,接下来需要准备配置资源仓库。SpringCloud搭配Git仓库来管理配置资源是目前应用最为广泛的一种方式,本框架目前暂时不支持Git仓库模式,而是采用了简单的文件夹作为资源仓库,即以配置服务本机工作空间下的文件夹作为仓库。
文件夹以工作空间为相对路径,默认仓库文件夹名为config-repository,可以通过配置设定,下面的子文件夹需要以下结构形式:
准备好文件夹,然后启动上面的节点,配置服务就已经可以正常工作了,接下来我们从其他节点读取配置节点的配置。
#
从指定配置节点读取可以通过命令行参数带入-D ready.config_server=http://localhost:8080,和SpringCloud一样,也可以可以通过bootstrap配置文件指定配置服务的地址,见下面的例子:
启动应用,系统将从指定服务器下载配置及资源文件到默认的本地配置文件夹config下,如果单机运行上面的实例,一个服务端口,一个客户端,其实就相当于从工作空间下的/config-repository/文件夹通过配置服务复制到了/config/文件夹。
#
配置中心自动发现上面通过指定配置中心的方式可以在系统启动前更新配置及资源文件,下面介绍另外一种工作模式。 如果既不传入-D ready.config_server参数,配置文件中也不配置configServerUri,像下面这样:
那么系统将尝试自动发现配置中心,然后拉取相关配置和资源文件。和上面不同的是,这种模式不更新当前运行环境内存中bootstrap和app的配置,只更新动态可变配置项,当然可以通过重启服务来生效。 这种模式适合于配置文件结构不会随意变动,只有部分配置的值会改变,此时将配置文件中相关配置项设计成动态可变配置项,然后通过更新values.yml来更新配置。关于动态可变配置项可以参考配置-动态可变配置项。
#
推荐配置节点拓扑推荐每个集群单独部署2-3台,至少1台,作为协调节点,负责提供配置服务、节点发现、健康检查等工作,这几个节点不挂载业务应用。
#
更多细节以上只列举了部分关于配置中心的重点内容。后续逐步完善更多具体的文档,并对重点内容进行专题描述。