概念

在单体应用中，我们常常将一些配置数据放在配置文件中进行集中统一管理，避免硬编码造成频繁发布。比如，数据库，redis，线程池，等等。常见的windows中的ini文件，linux系统中的conf，springboot工程中的application.properties。但是在分布式系统中，经常遇到的场景是多个系统共享同一份数据，这种情况下再通过文件配置处理，显得繁琐易错。为了便于管理引入集中式的处理系统-----配置中心
配置中心可以被认为是一个个的键值对。

组织方式
按环境：
像阿里的configserver，分为日常环境，预发环境，生成环境，灰度环境等。
按依赖
系统内部的，如文件上传大小，接口重发次数等。外部的中间件如redis，mysql。
按层次
基础层，中间件层，应用层

配置中心的出现解决的是配置信息的组织管理问题。
那么简单点的一个redis能不能做分布式的配置中心呢？

关注点

• 数据的从属管理
• 变更管理
• 生效时机

设计思路

前面提到了配置中心管理的其实是一个个的键值对，那么什么情况下的数据应该放在配置中心，什么放在服务发现，什么放在应用中呢？
耗子叔有提到这一点：

我们的配置参数中，如果有外部服务依赖的配置，强烈建议不要放在配置中心里，而要放在服务发现系统中。因为一方面这在语义上更清楚一些，另外，这样会减少因为运行不同环境而导致配置不同的差异性（如测试环境和生产环境的不同）。
s
对于不同运行环境中配置的差异来说，比如在开发环境和测试环境下，日志级别是 Debug 级，对于生产环境则是 Warning 或 Error 级，因为环境的不一样，会导致我们需要不同的配置项的值。这点需要考虑到。
还有，我们的配置需要有一个整体的版本管理，每次变动都能将版本差异记录下来。当然，如果可能，最好能和软件的版本号做关联。

自然的我们会想到要实现一个配置中心，可以使用的技术包括，配置存储（版本关联，如git，svn），发布订阅模式，push/pull模式。

产品

springcloud config

文档：springcloud
springcloud生态圈中的config提供了一套简单配置的配置中心方案，分为server端和client端。

特点：
Spring Cloud Config Server features:

• 基于HTTP的资源api配置（键值对，yml）
• 加解密
• 容易通过注解嵌入springboot系统 @EnableConfigServer

Config Client features (for Spring applications):

• 可以通过远程属性配置源绑定到配置中心和初始化spring环境
• 加解密
  https://docs.spring.io/spring-cloud-config/docs/3.0.0-SNAPSHOT/reference/html/

阿里巴巴 nacos
待续

demo