Skip to main content

配置服务

和SpringCloud类似,可以对应用的配置和资源文件进行集中管理,支持按项目、项目版本、应用、应用版本、运行环境,对配置和资源文件按版本进行分类管理。 目前本框架提供的配置服务暂时还不支持即时推送,如果配置发生变动,需要重启服务才能获取,后续版本将会支持热更新。

配置服务器#

配置服务可以作为单独的应用启动,也可以和其他应用整合在一起工作,下面是一个独立的配置服务节点:

@EnableCloud
public class ConfigNode extends Application {
public static final String name = "ConfigService";
public static final String version = "1.0.0.000000";
public static final String apiVersion = "v1.0";
// 这里加载配置服务模块
public static void registerModules(List<Class<? extends AppModule>> moduleList) {
moduleList.add(ConfigServerModule.class);
}
// 如果有多个配置服务节点,这里配置节点ID
public void cloudConfig(CloudConfig config){
config.setNodeId("ConfigNode-01");
}
// 这里设置了服务的端口号
@Override
protected void globalConfig(ApplicationConfig config) {
config.getServer().setHttpPort(8080);
}
public static void main(String[] args) {
Ready.For(ConfigNode.class).Work(args);
}
}

由于配置服务工作负载不大,可以和其他服务整合在一起,下面是一个工作节点附加配置服务的例子:

@EnableCloud
public class Node1 extends Application {
public static final String name = "test-01";
public static final String version = "1.0.1.210601";
public static final String apiVersion = "v1.0";
// 挂载配置服务模块
public static void registerModules(List<Class<? extends AppModule>> moduleList) {
moduleList.add(ConfigServerModule.class);
}
public void cloudConfig(CloudConfig config){
config.setNodeId("Node-1");
}
@Override
protected void globalConfig(ApplicationConfig config) {
config.getServer().setHttpPort(8080);
}
public static void main(String[] args) {
Ready.For(Node1.class).Work(args);
}
}

该节点提供业务服务的同时也提供配置服务。综上所述,任何一个应用挂载ConfigServerModule模块,即可提供配置服务。 以上是配置服务零配置启动模式,可以根据需要对配置服务进行增强设定,例如仓库路径设置、增加安全认证等。见下面的例子:

# configuration for dev environment
---
readyCloud:
configServer:
clientId: configClient # 如果希望配置客户端通过账号密码登陆,这里设置账号名
clientSecret: 123456 # 这里设置账号密码
configRepository: /config-repository/

配置资源仓库#

有了配置服务器,接下来需要准备配置资源仓库。SpringCloud搭配Git仓库来管理配置资源是目前应用最为广泛的一种方式,本框架目前暂时不支持Git仓库模式,而是采用了简单的文件夹作为资源仓库,即以配置服务本机工作空间下的文件夹作为仓库。
文件夹以工作空间为相对路径,默认仓库文件夹名为config-repository,可以通过配置设定,下面的子文件夹需要以下结构形式:

* {工作空间}/config-repository/
* |-- config
* |-- {projectName} // 对应项目名
* |-- global
* |-- {projectVersion} // 项目版本号,例如 1.0.0.201118
* |-- {environment} // 环境,例如 dev
* |-- values.yml // 项目全局配置放在这里
* |-- {appName} // 应用名,例如 test-01
* |-- {appVersion} // 应用版本号,例如 1.0.2.201018
* |-- {environment} // 环境,例如 dev
* |-- values.yml // 应用的个性化配置放在这里
* |-- ... 还可以有更多的应用
* |-- cert
* |-- {projectName} // 对应项目名
* |-- global
* |-- {projectVersion} // 项目版本号,例如 1.0.0.201118
* |-- {environment} // 环境,例如 dev
* |-- server.keystore // 项目全局的证书或密钥等重要文件放在这里
* |-- {appName} // 应用名,例如 test-01
* |-- {appVersion} // 应用版本号,例如 1.0.2.201018
* |-- {environment} // 环境,例如 dev
* |-- client.keystore // 应用的个性化的证书或密钥文件放在这里
* |-- ... 还可以有更多的应用
* |-- file
* |-- {projectName} // 对应项目名
* |-- global
* |-- {projectVersion} // 项目版本号,例如 1.0.0.201118
* |-- {environment} // 环境,例如 dev
* |-- info.xml // 项目全局的其他资源文件放在这里
* |-- i18n.properties
* |-- {appName} // 应用名,例如 test-01
* |-- {appVersion} // 应用版本号,例如 1.0.2.201018
* |-- {environment} // 环境,例如 dev
* |-- abc.xml // 应用的个性化需求的其他资源文件放在这里
* |-- abc.properties
* |-- ... 还可以有更多的应用

准备好文件夹,然后启动上面的节点,配置服务就已经可以正常工作了,接下来我们从其他节点读取配置节点的配置。

从指定配置节点读取#

可以通过命令行参数带入-D ready.config_server=http://localhost:8080,和SpringCloud一样,也可以可以通过bootstrap配置文件指定配置服务的地址,见下面的例子:

# configuration for dev environment
---
readyCloud:
configClient:
enabled: true
configServerUri: http://localhost:8080 # 对应启动的配置服务器IP和端口
#clientId: configClient # 如果配置服务器需要账号密码,这里对应指定的账号名
#clientSecret: 123456 # 这里对应指定的密码

启动应用,系统将从指定服务器下载配置及资源文件到默认的本地配置文件夹config下,如果单机运行上面的实例,一个服务端口,一个客户端,其实就相当于从工作空间下的/config-repository/文件夹通过配置服务复制到了/config/文件夹。

配置中心自动发现#

上面通过指定配置中心的方式可以在系统启动前更新配置及资源文件,下面介绍另外一种工作模式。 如果既不传入-D ready.config_server参数,配置文件中也不配置configServerUri,像下面这样:

# configuration for dev environment
---
readyCloud:
configClient:
enabled: true
configServerUri: # 如果为空,则会尝试自动发现配置中心
#clientId: configClient # 如果配置服务器需要账号密码,这里对应指定的账号名
#clientSecret: 123456 # 这里对应指定的密码

那么系统将尝试自动发现配置中心,然后拉取相关配置和资源文件。和上面不同的是,这种模式不更新当前运行环境内存中bootstrap和app的配置,只更新动态可变配置项,当然可以通过重启服务来生效。 这种模式适合于配置文件结构不会随意变动,只有部分配置的值会改变,此时将配置文件中相关配置项设计成动态可变配置项,然后通过更新values.yml来更新配置。关于动态可变配置项可以参考配置-动态可变配置项

推荐配置节点拓扑#

推荐每个集群单独部署2-3台,至少1台,作为协调节点,负责提供配置服务、节点发现、健康检查等工作,这几个节点不挂载业务应用。

更多细节#

以上只列举了部分关于配置中心的重点内容。后续逐步完善更多具体的文档,并对重点内容进行专题描述。