Spring Cloud Config采用Git存储时两种常用的配置策略

由于Spring Cloud Config默认采用了Git存储，相信很多团队在使用Spring Cloud的配置中心时也会采用这样的策略。即便大家都使用了Git存储，可能还有各种不同的配置方式，本文就来介绍一下两种常用的配置策略。

第一种：多个项目公用一个Git仓库，用不同的目录区分项目

主要的配置项如下：

spring.cloud.config.server.git.uri=https://github.com/dyc87112/config-repo.git
spring.cloud.config.server.git.search-paths=/{application}

这种模式下不同的项目会对应到https://github.com/dyc87112/config-repo.git仓库下的不同目录，如果项目中spring.application.name=user-service，那么它的配置仓库会定位到https://github.com/dyc87112/config-repo.git仓库下的/user-service目录。配置文件按application-{profile}.properties的格式存储，{profile}代表环境名。

优缺点分析：因为只使用一个Git库存储，所以当配置是由专人统一维护的时候比较方便。但是如果要做DevOps的话，权限控制上将变的非常的弱。

第二种：多个项目使用多个不同Git仓库

主要的配置项如下：

spring.cloud.config.server.git.uri=https://github.com/dyc87112/{application}.git

这种模式下不同的项目会对应的不同的Git仓库，如果项目中spring.application.name=user-service，那么它的配置仓库会定位到https://github.com/dyc87112/user-service.git仓库下的配置。配置文件按application-{profile}.properties的格式存储，{profile}代表环境名。

优缺点分析：由于一个项目就有一个对应的存储配置的Git仓库，所以这种模式对于DevOps的应用支持较好，如果使用Gitlab作为Git服务端的话，还有不错的界面和权限管理来方便项目所属者使用和维护。如果团队不是DevOps模式管理的话，专人管理就会遇到有N多Git仓库要维护的困境。

本文的主要介绍内容就到这里，不知道您采用了哪种配置存储策略呢？如果有更好的方案欢迎留言分享！最后，正式向大家介绍一下最近紧锣密鼓开发和测试中的配置中心开源项目。该项目基于Spring Cloud Config构建，旨在实现一套方便大家对配置管理的可视化工具，增强Spring Cloud Config的易用性，该项目即适用于目前已经在使用spring cloud config的用户，也适用于正在选型配置中心的用户，小哥哥小姐姐们可以戳下面的链接了解一下，如果觉得不错，欢迎转发、Star支持！

• Github: https://github.com/dyc87112/spring-cloud-config-admin
• Gitee：https://gitee.com/didispace/spring-cloud-config-admin

P.S. 主要维护在Github，Gitee定期同步。