配置中心设计调研

1. 真正可用于生产的配置中心会不可避免地需要考虑版本化，变更审计等问题。
2. 配置中心的配置要有依赖继承关系，要分环境或场景。公共配置应该可以统一设置，在获取某个微服务配置时配置中心会自动合并要求环境及场景下的公共配置、服务自身配置。
3. 配置中心要求可以动态地刷新并应用新的服务配置，这需要服务自身提供相应的支持，比如配置刷新。一般会在服务中加入配置中心的SDK，SDK收到配置后通知服务分批次进行更新。
4. 配置中心需要做到弱依赖，即脱离配置中心各服务依然可以运行，最常规的做法是服务在启动时想配置中心获取配置并缓存到本地，配置中心推送配置或服务定时主动拉取最新的配置并更新缓存，在配置中心或对应的网络故障时各服务可以正常运行。

配置中心的设计核心有： - 集中化管理与配置切片：所有配置可以按照一定维度切片，常见的按作用域分为全局级与服务级，按环境分为生产、预发、测试、开发等，按场景分各类特殊的活动 - 版本化与变更审计：所有配置变更要保留历史版本、记录操作人员以便回滚与审计，最简单的是使用git方式 - 动态刷新：配置可以按一定策略动态刷新，在有服务依赖的情况下，先刷新被依赖的服务，在有多实例的情况下实现依次或灰度刷新，仅在上一次刷新成功后再手动或自动地刷新其它实例。 - 高可用：配置中心自身需要足够健壮，并且配置中心最好也可以当成一个普通服务注册到注册中心形成统一的整体。 - 弱依赖：各服务在运行期间不应强依赖配置中心，做好配置获取及缓存策略，在配置中心或网络故障时使用缓存配置，在正常后刷新本地缓存 - Push/Pull配置更新的方式有Push/Pull两种，push对配置变更的感知实时性高，但同时对配置中心的要求也更高 - SDK支持：配置中心要有对应的SDK以实现配置的刷新、缓存，确保即便配置中心宕机或网络不通时不会影响服务本身的运行。