“spring cloud”的配置中心工具“spring cloud config”提供了分布式系统配置文件集中管理解决方案。该工具功能强大，实现也很简单。网上可以搜索到很多开发教程和用例。本文并不是分享“spring cloud config”的开发方法，而是想聊一聊它的使用。
任何一个工具不管多么强大和便利，如果用的不好，也达不到期望的效果。拿到“spring cloud config”后，我期望基于这个工具构建的配置文件管理系统能够实现：
- 微服务中各个实例的配置项都集中在配置中心。运维人员无需逐一链接到各个分布式节点，能够在配置中心完成微服务实例所有配置项的修改。
- 配置项信息源要单一。同一个配置项不会出现在两个源中。以免两个源中同一个配置项数值不一致，导致业务逻辑混乱。
通常在网上看到的“spring cloud config”实例中，“config client”的本地配置文件“bootstrap.properties”如下：
文件中微服务端口号“8001”和实例名称“booking-server”配置项其实是有可能改动的。例如增减微服务实例、端口号已占用、新增微服务类型等场景。所以将它们放到本地配置文件中无法满足第一个需求。此外为了满足第二个需求，需要将配置项按照使用范围进行分类，分别放入不同的配置文件中：
1） 所有微服务实例共享的配置项，例如common.properties
2） 同类微服务实例共享的配置项，例如booking-common.properties
3） 特定微服务实例独享的配置项，例如booking-server-a.properties、booking-server-b.properties
这就要求微服务实例能够加载多个远端的配置文件。而上面这种配置方式是使用微服务名称“booking-server”映射到配置中心的“booking-server-dev.properties”配置文件。限制了加载的配置文件数量和名称。无法满足第二个需求。
现在以booking微服务dev版本为例，修改上面的配置文件：
- 微服务端口号“server.port”是实例独享的配置项，将“server.port”放入“booking-server-a.properties”配置文件中。
- 微服务名称“spring.application.name”是booking类服务各个实例共享的配置项，将“spring.application.name”放入“booking-common.properties”配置文件中。
- 服务注册中心地址配置项“eureka.client.serviceUrl.deaultZone”只能保留在本地配置文件中。
- 配置中心微服务名称“spring.cloud.config.discovery.service-id”只能保留在本地配置文件中。
- 将微服务booking与其他微服务共享的配置项放入“common.properties”配置文件中。
- 使用“spring.cloud.config.name”配置项同时加载“common.properties”、“booking-common.properties”和“booking-server-a.properties”配置文件。
修改后的配置文件如下：
common-dev.properties配置文件：
booking-common-dev.properties配置文件：
booking-server-a-dev.properties配置文件：
"booking-server-a"本地“bootstrap.properties”配置文件：
现在“booking”微服务实例a的本地配置文件已经得到精简，只保留了必要的配置项。这些配置项是必须的，用来指示“config client”如何找到“config server”以及应该加载那些配置文件。此外配置项“spring.cloud.config.name”和“spring.cloud.config.profile”配置项可以放到启动微服务的命令行中。这样可以编译一个通用jar包，通过不同命令行参数启动为不同的微服务实例。
再次精简的本地“bootstrap.properties”配置文件：
启动“booking”微服务a的命令：
java -jar .ooking-server.jar --spring.cloud.config.name=common,booking-common,booking-server-a --spring.cloud.config.profile=dev
本文讲的东西是比较简单的。主要是分享一下使用“spring cloud config”的一种思路。