共计 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 区分
| Name | Branch | Profile |
|---|---|---|
| foo-shanghai.yaml | stg | shanghai |
| foo-beijing.yaml | stg | beijing |
| foo-shanghai.yaml | prd | shanghai |
| foo-beijing.yaml | Prd | beijing |
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 区分
| Name | Branch | Profile |
|---|---|---|
| foo-stg-shanghai.yaml | master | stg-shanghai |
| foo-stg-beijing.yaml | master | stg-beijing |
| foo-prd-shanghai.yaml | master | prd-shanghai |
| foo-prd-beijing.yaml | master | prd-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 的能力。
