[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時，最好能夠將拿到的配置在業務機器的磁盤上也緩存一份。這樣遠程配置中心不可用時，可以直接用硬盤上的內容來做兜底。當重新連接上配置中心時，再把相應的內容進行更新 - 加入緩存之后務必需要考慮的是數據一致性問題，當個別業務機器因為網絡錯誤而與其它機器配置不一致時，我們也應該能夠從監控系統中知曉。