微服务架构统一配置管理(配置中心)

在单体应用中，配置管理可能不是什么大的事情，通常会以配置文件的方式。常见的方法比如将配置放在CI服务器上通过打包脚本打入应用包中，或者直接放到运行应用的服务器的特定目录下，或者存储到数据库中。这种方式在传统的单体应用中简单有效，但是也会有些比较棘手的问题：

配置变化频繁时，需要频繁的打包部署应用
不同环境的配置需要分开管理（比如测试环境与生产环境）
而在分布式微服务架构中，服务数量剧增，如果还是手动去实现配置信息的修改或数据的迁移等，效率是很低的，而且手动操作配置也极有可能出现错误的情况：

复杂的业务对应大量的配置项
对集群部署的应用配置进行修改时需要一次修改每个节点上的应用配置
这种背景下，中心化的配置服务即配置中心应运而生。配置中心就是一种统一管理各种应用配置的基础服务组件，一般来说，配置中心会有下面的特性（不仅限如此）：

提供配置管理中心, 支持在线管理配置信息
配置自动发布到应用
配置支持版本控制
支持不同环境隔离部署
需保证高性能、高可用
配置中心可以把业务开发者从复杂以及繁琐的配置中解脱出来，只需专注于业务代码本身，从而能够显著提升开发以及运维效率。同时将配置和发布包解藕也进一步提升发布的成功率，并为运维的细力度管控、应急处理等提供强有力的支持。

我们的需求
能够按需动态加载配置
可以从多个源加载配置：内存，文件，环境变量，分布式配置中心等
多个配置源可以合并并覆盖
可以监听配置变更
配置可以版本化管理，并可以使用指定版本
可以以金丝雀的方式发布配置
我们的配置中心
基于以上需求，我们使用一个比较简单的架构实现了第一个版本的配置中心。

我们提供一个比较简单（jianlou）的界面来操作服务的配置，并使用Etcd来存储并下发的配置数据。在服务框架中，我们使用一个配置中心的库来获取和监听配置。该库支持从内存，本地文件以及Etcd等多个源加载配置数据，也就是说我们的库支持传统的静态配置，也支持动态配置。
使用配置中心
假设我们有一个示例配置：

{
    "hosts": {
        "database": {
            "address": "127.0.0.1”,
            "port": 3306
        },
        "cache": {
            "address": "127.0.0.2”,
            "port": 6379
        }
    }
}

我们使用以下方式（配置源为本地文件以及Etcd）来加载配置：

config.Load(
    file.NewSource(file.WithPath(`/path/to/config.json`)),
    etcd.NewSource(
        etcd.WithAddress(`http://127.0.0.1:2379`),
        etcd.WithPrefix(`ServerName`),
    ),
)

读取配置：

type Host struct {
    Address string `json:"address"`
    Port    int    `json:"port"`
}
var hostDatabase Host
config.Get(`hosts`, `database`).Scan(&hostDatabase);
// hostDatabase: {127.0.0.1, 3306}
监听配置项变更：

w, err := cm.conf.Watch(`hosts`, `database`)
if err != nil {
    log.Errorf(`conf watch error: %v`, err)
    return
}
for {
    v, _ := w.Next()
    var newHost Host
    v.Scan(&host)
    // newHost: {127.0.0.3, 3306}
}

若管理员在管理界面变更database的address为127.0.0.3，则将触发上面的代码，获得更新之后的address。

总结
我们现在使用的配置中心，基本上能满足像我们这样的小型创业公司配置变更发布的运维需求，但是还有很多可以改进的地方，比如上面提到的版本化管理配置，灰度发布配置等，使用配置中心的可用性更好，当然管理界面上也需要优化为更加友好的展现形式。