我可能在这里遗漏了一些东西,但是什么是属性版本控制的好方法?
例如,在属性值更改的蓝绿色部署方案中(旧应用版本消耗旧值,新版本需要新值),您如何确保应用的两个版本都能成功共存(考虑潜在的重启和回滚)?
一种选择是为需要应用新值的属性创建新的属性名称。当然,这不是一个好的选择,因为我们需要在代码库中跟踪该属性的所有用法并相应地更新其引用。从概念的角度来看,它也不是很好。
另一个选择是为每个版本分配一个分支。虽然这可以很好地适用于这种情况,但我设想了一个分支/标记地狱,因为我们扩展到配置仓库到多个应用程序,它们各自的分支发展到不同的方向。
分支机构地狱的解决方案是为每个应用程序分配一个配置存储库。但是,我认为这在某种意义上会破坏配置服务器的目的,因为它增加了开销。
还有其他方法吗?
答案 0 :(得分:8)
Spring Cloud Config的Environment
资源由三个变量参数化:
{application}
映射到客户端的spring.application.name
{profile}
映射到客户端上的spring.active.profiles
{label}
这是标记版本化集的服务器端功能
配置文件。由于蓝绿色部署,您在同一个配置文件中使用相同的应用程序,最好的选择是使用git 标签<使用 Versioned 配置文件/ em>的。
基本思路是为不同版本的配置文件创建标记,并告诉您的应用使用spring.cloud.config.label
中的bootstrap.properties
使用与特定标记相关的配置。
例如,您可以使用v1.0
和v2.0
标记两个不同的提交:
对旧实例使用spring.cloud.config.label=v1.0
,对新实例使用spring.cloud.config.label=v2.0
。
因为我们扩展到配置repo到多个应用程序及其各自的应用程序 树枝演变成不同的方向。
为了避免这个问题,我建议只在application-{profile}.properties
配置文件中保存常用和跨应用程序属性。更好的方法是每个应用程序都有自己的配置文件,例如recommender.properties
用于推荐服务,search.properties
用于搜索服务。然后,您可以通过定义相应的spring.application.name
为每个属性使用配置文件特定和版本化属性。这样,您就可以在配置文件中实现某种级别的单一责任原则。