怎么用好Spring-Config

66次阅读

共计 2155 个字符,预计需要花费 6 分钟才能阅读完成。

转载自本人博客
原文地址:https://www.deanwangpro.com/2…

配置其实分为结构和内容两个方面,结构对应的是代码,比如 1.0.0 新开发的代码上有一个功能开关 ${feature.switchA},但 master 上还没有,这就是结构的变化。另一方面是内容,1.0.0 的开发分支有两个测试环境,连着不同的数据库,那么对应的${mysql.url} 的内容肯定不同。

内容的类别上也可以分为三种:业务配置,功能开关,服务配置。

Spring Cloud 的配置中心是 Spring Config,经过两年的使用,发现了其中不少的问题,有些是使用问题,有些是 Spring Config 本身的管理能力导致的问题。

Spring Config 首推基于 git 的管理方式,提供了两个管理维度,一个是 label(即 branch),一个是 profile。当服务 foo 在一套代码下要安装多套环境,比如预发布环境有 2 套,一套在 shanghai 机房,一套在 beijing 机房。那么比较自然的管理维度就是利用 profile,foo-shanghai.yaml 以及 foo-beijing.yaml。当生产环境也依然需要 2 台时,怎么处理呢?这时候就会有两种做法,一种利用增加 label 维度做区分,一种依然只用 profile。

<!–more–>

方法一:用 label + profile 区分

NameBranchProfile
foo-shanghai.yamlstgshanghai
foo-beijing.yamlstgbeijing
foo-shanghai.yamlprdshanghai
foo-beijing.yamlPrdbeijing

branch 其实表示的是结构,即对应不同的代码,而 profile 对应的是内容。

这种方式有什么问题?一般应用都是只有 profile 来区分环境,比如 logback 要分环境区分配置也是通过 <springProfile> 来指定。一旦采用两个维度来确定唯一的配置,那么所有项目都需要有 label 这个变量。

试想如果 foo 这个应用在线上有个 bug 需要 fix,势必会增加一个 hotfix 的 branch 在配置中心,同时还需要增加相应的 profile,对应 foo 的 label 变量设置为 hotfix,profile设置为 beijing 或者 shanghai。

再考虑另一种情况,foo 在 prd 的代码需要放到 stg 进行验证如何处理?foo 的代码版本肯定是 prd 的(因为 stg 的配置结构也许已经变了),但 profile 需要用 stg 的环境。这时实际上只能在配置中心的 prd 分支上新建一个新的 profile 来临时满足这种需求。

方法二:只使用 profile 区分

NameBranchProfile
foo-stg-shanghai.yamlmasterstg-shanghai
foo-stg-beijing.yamlmasterstg-beijing
foo-prd-shanghai.yamlmasterprd-shanghai
foo-prd-beijing.yamlmasterprd-beijing

这种方式可以降低管理维度,即放弃 label 的维度,只有 profile 的维度。同样的问题,如果 foo 这个应用在线上有个 bug 需要 fix,那么需要新增两个 profile,hotfix-beijing 和 hotfix-shanghai。虽然维度降低了,但是管理上却有些麻烦。因为 master 的这个分支无法保护起来,如果有开发人员直接修改了 prd-XXX 的环境就会导致线上问题。

同样的,foo 在 prd 的代码需要放到 stg 进行验证如何处理?foo 的代码版本肯定是 prd 的(因为 stg 的配置结构也许已经变了),但 profile 需要用 stg 的环境。这时实际上只能再配置中心新建一个 profile,比如 stg-oldshanghai,来满足这种需求。

然而我们知道,增加新的 profile 其实还是挺麻烦的事情,如果代码中有直接比较 profile 的逻辑,那么往往容易出现问题。

有没有不临时增加 profile 的办法呢?其实仔细思考一下,在 stg 环境验证 prd 的服务,真正的逻辑是什么?是希望用 stg 环境的配置内容,以及 stg 某个历史版本(与 prd 匹配的)的配置结构。所以纵向维度我们需要的其实是 version,profile 都是 stg-shanghai,而 version 一个是 1.0.0,一个是 latest。

方法三:综合一下

好了,现在我们来综合一下两种方式,可以使用 git 的分支作为 version,profile 依然还是按照方法二来区分。毕竟频繁增加环境的可能性不高。但是如果要同时维护一个 profile 两个分支,其实还是要来回切换的,比较麻烦,这也是 Spring Config 为人诟病的管理功能弱。好在 Spring Cloud 也支持 mysql,用 mysql 同时管理多个 label 的内容还是方便不少,只是 git 自带的“后悔药”(history)功能没有了。所以说还是有利有弊。

小结

如果想要更完善的配置管理工具,建议还是使用 Apollo。要想用好 Spring Cloud,必须可以忍受它比较弱的管理能力,并且做好前期规划,结合项目特点来使用 label 和 profile 的能力。

正文完
 0