[TOC] ## 概述 ## 使用etcd实现配置更新 **配置定义** ``` etcdctl get /configs/remote_config.json { "addr" : "127.0.0.1:1080", "aes_key" : "01B345B7A9ABC00F0123456789ABCDAF", "https" : false, "secret" : "", "private_key_path" : "", "cert_file_path" : "" } ``` 新建 etcd client ``` cfg := client.Config{ Endpoints: []string{"http://127.0.0.1:2379"}, Transport: client.DefaultTransport, HeaderTimeoutPerRequest: time.Second, } ``` 配置获取 ``` resp, err = kapi.Get(context.Background(), "/path/to/your/config", nil) if err != nil { log.Fatal(err) } else { log.Printf("Get is done. Metadata is %q\n", resp) log.Printf("%q key has %q value\n", resp.Node.Key, resp.Node.Value) } ``` 配置更新订阅 ``` kapi := client.NewKeysAPI(c) w := kapi.Watcher("/path/to/your/config", nil) go func() { for { resp, err := w.Next(context.Background()) log.Println(resp, err) log.Println("new values is ", resp.Node.Value) } }() ``` ## 配置膨胀 - 在配置管理过程中，难免出现用户误操作的情况，例如在更新配置时，输入了无法解析的配置。这种情况下我们可以通过配置校验来解决。 - 有时错误的配置可能不是格式上有问题，而是在逻辑上有问题。比如我们写SQL时少select了一个字段，更新配置时，不小心丢掉了json字符串中的一个field而导致程序无法理解新的配置而进入诡异的逻辑。为了快速止损，最快且最有效的办法就是进行版本管理，并支持按版本回滚。 - 在配置进行更新时，我们要为每份配置的新内容赋予一个版本号，并将修改前的内容和版本号记录下来，当发现新配置出问题时，能够及时地回滚回来 - 常见的做法是，使用MySQL来存储配置文件或配置字符串的不同版本内容，在需要回滚时，只要进行简单的查询即可 ## 客户端容错 - 当配置中心本身宕机时，我们也需要一定的容错能力，至少保证在其宕机期间，业务依然可以运转。这要求我们的系统能够在配置中心宕机时，也能拿到需要的配置信息。哪怕这些信息不够新 - 在给业务提供配置读取的SDK时，最好能够将拿到的配置在业务机器的磁盘上也缓存一份。这样远程配置中心不可用时，可以直接用硬盘上的内容来做兜底。当重新连接上配置中心时，再把相应的内容进行更新 - 加入缓存之后务必需要考虑的是数据一致性问题，当个别业务机器因为网络错误而与其它机器配置不一致时，我们也应该能够从监控系统中知晓。