7月1日，為慶祝我黨生日，ETCD隆重發布了3.0版本。Botposter.com也在第一時間對集群進行了升級。本文是升級過程的記錄與總結（文中假設讀者已經使用或測試過ETCD V2，如有不妥請見諒）。
Botposet.com是一款與HubSpot類似的營銷自動化SAAS產品，全部使用golang開發。
說明
在Botposter.com中，ETCD主要用於以下兩個職責：
- master選舉
- 集群信息保存
早期曾使用ETCD的TTL來實現master心跳檢測，由於性能原因在Botposter.com上個月的重構中取消了這種用法。這也恰好簡化了升級難度，因為ETCD v3對TTL有重大改動。
准備
資料准備
遷移工作的主要參考以下兩篇資料：
https://github.com/coreos/etcd/blob/master/Documentation/op-guide/v2-migration.md
https://github.com/coreos/etcd/blob/master/Documentation/upgrades/upgrade_3_0.md
測試環境
開始升級前需要搭建測試環境，過程非常簡單，這一點ETCD做得非常好，V3版本與V2版本無論從安裝方式和配置參數完全一致。
安裝參考鏈接：https://github.com/coreos/etcd/releases
配置參考鏈接：https://github.com/coreos/etcd/blob/master/Documentation/op-guide/clustering.md
配置好測試環境后，使用etcdctl測試ETCD V3是否可以正常使用。這里需要注意，一定不要忘記在環境變量中加入ETCDCTL_API=3。否則在操作V3時，無論使用SET,GET都沒有任何數據返回，也沒有錯誤返回。建議ETCD V3可以提供錯誤提示。我在這里耽誤了一些時間，因為想當然的以為，使用ETCD V3和ETCDCTL V3是默認匹配的。
ETCDCTL的文檔鏈接：https://github.com/coreos/etcd/blob/master/etcdctl/README.md#migrate-options
注意：我在第一次使用etcdctl member list命令(所有的命令都會出錯，此處以member list舉例)的時候，返回下面錯誤代碼：
grpc: addrConn.resetTransport failed to create client transport: connection error: desc = "transport: dial tcp 127.0.0.1:22379: getsockopt: connection refused"; Reconnecting to {"127.0.0.1:22379" <nil>}
單獨運行etcdctl命令，會返回etcdctl的使用幫助，其中有一行：
--endpoints=[127.0.0.1:2379,127.0.0.1:22379,127.0.0.1:32379] gRPC endpoints
原來默認gRPC的endpoints有三個，解決這個問題的已知辦法有兩個：
一是在etcdctl命令行中加入--endpoints參數
etcdctl --endpoints=127.0.0.1:2379 member list
二是在etcd啟動參數中增加其它端口
-listen-client-urls http://127.0.0.1:2379,http://127.0.0.1:22379,http://127.0.0.1:32379
在Botposter.com中暫時使用第二種方法。因為遷移時間有限，沒有繼續查看是否可以修改gRPC的默認--endpoints。
API V2與V3區別
- 事務：ETCD V3提供了多鍵條件事務（multi-key conditional transactions），應用各種需要使用事務代替原來的Compare-And-Swap操作。
- 平鍵空間（Flat key space）：ETCD V3不再使用目錄結構，只保留鍵。例如："/a/b/c/"是一個鍵，而不是目錄。V3中提供了前綴查詢，來獲取符合前綴條件的所有鍵值，這變向實現了V2中查詢一個目錄下所有子目錄和節點的功能。
- 簡潔的響應：像DELETE這類操作成功后將不再返回操作前的值。如果希望獲得刪除前的值，可以使用事務，來實現一個原子操作，先獲取鍵值，然后再刪除。
- 租約：租約代替了V2中的TTL實現，TTL綁定到一個租約上，鍵再附加到這個租約上。當TTL過期時，租約將被銷毀，同時附加到這個租約上的鍵也被刪除。
與Botposter.com有關的改動只有平鍵空間，因為系統中使用ETCD目錄結構保存了master，node和task的全部信息。
從官方文檔的表述看，事務和租約值得測試並用於優化V2的用法。
客戶端代碼升級
平鍵空間
將原代碼中包含以下代碼的部分都修改為
&client.GetOptions{Recursive: true}
都修改為
clientv3.WithPrefix()
數據類型
在V2版本中，resp.Node.ModifiedIndex的數據類型為uint64，V3中revision為int64。
因為在Botposter.com使用了resp.Node.ModifiedIndex作為全局序列標識，所以，需要將原系統中的數據類型修改為int64。
Compare-And-Swap
在V2的一種典型用法就是Compare-And-Swap，在Botposter.com中也使用這種方法實現了分布式鎖，實現方法是在SET操作時增加下面的操作：
&client.SetOptions{PrevExist: "false"})
即，只有當前key不存在時，才能寫入成功。
在V3中，改為由事務實現。具體代碼如下：
kvc := clientv3.NewKV(&cli)
r, _ := kvc.Txn(context.Background()).
If(clientv3.Compare(clientv3.CreateRevision(key), "=", 0)).
Then(clientv3.OpPut(key, v)).
Commit()
Txn的具體用法參考：https://godoc.org/github.com/coreos/etcd/clientv3#example-KV--Txn
Node
在V2中，get操作response回來的value保存在response.node.value，如果是一個directory，返回的結果集保存在response.node.nodes中。
V3做了大幅修改，因為V3中不再有directory，所有的key都是flat key，所以，所有get操作的返回值都保存在GetResponse.Kvs（數據類型是[]*mvccpb.KeyValue）中。而且V2中，keynotfound等錯誤在V3中都不再保留，V3中，當查詢的key不存在時，GetResponse.Count為0，len(GetResponse.Kvs)也為0，Get操作返回的error為nil。
所以在V2中的代碼如
response.Node.Value
需要改為
GetResponse.Kvs[0].Value
另外值得注意的是，V3中的key和value的返回值都是[]byte類型，這可以減少很多string與[]byte的數據類型轉換操作。
ETCD升級
ETCD升級很簡單，先按照安裝參考鏈接：https://github.com/coreos/etcd/releases ，下載並解壓文件。
因為Bostposter.com集群有自動恢復機制，所以使用離線升級的方式，在所有服務器運行腳本：
service etcd stop
cp etcd /usr/local/bin
service etcd start
ETCD的所有啟動參數都不需要修改，升級時間不超過1秒。
ETCD升級后，升級集群服務的代碼，只有在升級流程容器時需要重啟2000多個流程，全部恢復時間大概在1分鍾左右。
至此，升級工作全部完成。對系統功能和集群都做了測試，沒有出現任何問題。
感受
下面說說升級到ETCD V3后的感受，時間有限沒有做精確測試，沒有數據支撐略顯不夠嚴謹。
首先，V3服務器端的內存比V2占用得更高，至少高50%。尤其是壓力增大時，內存占用飆升得很快，壓力減小后幾分鍾內存會釋放出來。
其次，Client使用后一定要Close，因為在V2時，Botposter.com中使用了sync.pool來保存Client。當升級到V3后，操作頻繁時池化的Client會占用非常多的內存，因為沒有做具體測試，還不清楚一個Client占用多少內存。目前的解決辦法是Client不再池化，而且使用后立即Close。
第三，V3的API更加合理，直接的結果是代碼量減少了，異常處理也變得更簡單。
第四，從升級后的整體表現看，V3的性能比V2要很多。
整體來說，在有條件的情況下，我建議升級至ETCD V3。時間倉促，如有筆誤請大家及時指出，謝謝。
內容為作者原創，未經允許請勿轉載，謝謝合作。
關於作者：
Jesse，目前在Joygenio工作，從事golang語言開發與架構設計。
正在開發維護的產品：www.botposter.com