首页 文章

使用Spring Cloud Config进行属性版本控制

提问于
浏览
5

我可能在这里遗漏了一些东西,但是什么是属性版本控制的好方法?

例如,在具有属性值更改的蓝绿色部署方案中(旧应用程序版本使用旧值,新版本需要新值),如何确保应用程序的两个版本可以成功共存(考虑可能的重新启动和回滚)?

一种选择是为需要应用新值的属性创建新的属性名称 . 当然,这不是一个好的选择,因为我们需要在代码库中跟踪该属性的所有用法并相应地更新其引用 . 从概念的角度来看,它也不是很好 .

另一个选择是为每个版本分配一个分支 . 虽然这对于这种情况可以很好地工作,但我设想一个分支/标记地狱,因为我们扩展到配置repo到多个应用程序,并且它们各自的分支演变成不同的方向 .

分支机构的解决方案是为每个应用程序分配一个配置存储库 . 但是,我相信这在某种意义上会破坏配置服务器的目的,因为它增加了开销 .

还有其他方法吗?

1 回答

  • 6

    Spring Cloud Config的 Environment 资源由三个变量参数化:

    • {application} 在客户端映射到 spring.application.name

    • {profile} 映射到客户端上的 spring.active.profiles

    • {label} 这是标记 versioned 配置文件集的服务器端功能 .

    由于在Blue-Green部署的情况下,您在同一个配置文件中使用相同的应用程序,最好的选择是使用git标签使用Versioned配置文件 .

    基本思想是为不同版本的配置文件创建标签,并告诉应用程序使用 bootstrap.properties 中的 spring.cloud.config.label 来使用与特定标签相关的配置 .

    例如,您可以使用 v1.0v2.0 标记两个不同的提交:

    对旧实例使用 spring.cloud.config.label=v1.0 ,对新实例使用 spring.cloud.config.label=v2.0 .

    当我们扩展到多个应用程序的配置仓库时,它们各自的分支会演变为不同的方向 .

    为了避免这个问题,我建议只在 application-{profile}.properties 配置文件中保存常用和跨应用程序属性 . 更好的方法是每个应用程序都有自己的配置文件,例如 recommender.properties 用于推荐服务, search.properties 用于搜索服务 . 然后,您可以通过定义相应的 spring.application.name 来为每个属性使用特定于配置文件和版本化的属性 . 这样,您就可以在配置文件中实现某种级别的单一责任原则 .

相关问题