Botposter.com集群ETCD2.3.7升級至3.0實例分析

本篇文章為大家展示了Botposter.com集群ETCD2.3.7升級至3.0實例分析，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

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。

上述內容就是Botposter.com集群ETCD2.3.7升級至3.0實例分析，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業資訊頻道。