首先,獲得etcd和zetcd源碼,并編譯成二進制代碼：

go?get?github.com/coreos/etcd/cmd/etcd?
go?get?github.com/coreos/zetcd/cmd/zetcd

其次,運行etcd,將zetcd連接到etcd客戶服務端：

#etcd?uses?localhost:2379?by?default?
etcd?&?
zetcd?-zkaddr?localhost:2181?-endpoints?localhost:2379?&

通過增加訂閱和創建一個key來試用zetd：

go?install?github.com/coreos/zetcd/cmd/zkctl?
zkctl?watch?/?&?
zkctl?create?/abc?"foo"

從概念上講,上述例子即完成在一個單個的etcd實例上增加一層zetcd.
etcd這層到底是做什么的呢?

etcd3中對ZooKeeper的支持

ZooKeeper以目錄方式列出key(getChildren),而etcd則是通過間隔(Range)方式.下圖講解了zetcd如何對etcd下的key進行編碼從而有效地支持以目錄形式列出.所有在etcd中的zetcd key都有一個包括全目錄名的前綴(例如：”/”和“/abc”分別代表深度為0 和1).要列出一個目錄時,zetcd發出一個帶前綴的range請求(例如[“/zk/key/002/abc/”, “/zk/key/002/abc0”)來列出滿足目錄深度和路徑的所有/abc/下的key.深度限制只針對目錄本身；如果zetcd只使用路徑而不使用深度,那么etcd將返回這個目錄下的所有key,zetcd則會丟棄該結果,反之則只返回本目錄下的key.

此外,zetcd可以和一臺授權的ZooKeeper服務器做動態校驗.為了做比較,zetcd可以同時連到etcd和外部ZooKeeper服務器.當客戶端發起請求給該模式下的zetcd時,請求會被同時轉發到zetcd和ZooKeeper服務端.如果兩個服務器響應的數據不一致,zetcd會給此響應標識一個警告.

性能基準

跟etcd性能工具的接口及報告形式類似,zetcd命令行工具zkboom可以用來判斷一個zetcd的性能基準是否滿足要求.其它ZooKeeper性能工具應該也可以用在zetcd；zkboom為用戶提供了便利,我們不妨試試用它來做下創建key的測試：

go?get?github.com/coreos/zetcd/cmd/zkboom?
zkboom?--conns=50?--total=10000?--endpoints=localhost:2181?create

下圖揭示了zetcd客戶端并發數與創建key的平均延遲之間的關系.由于etcd在延遲上比ZooKeeper要有5-35ms的優勢,zetcd有足夠余地處理由于額外負載和網絡跳轉造成的延遲.比起ZooKeeper,zetcd代理始終還是存在20ms左右的差距,但是從處理2500請求的吞吐量數據來看,并沒有出現隊列堵塞.一種對zetcd寫比較慢的解釋是,與讀不一樣,由于數據模型上存在差異,所以在每個ZooKeeper key寫時需要寫多個key.

下圖揭示了zetcd客戶端并發數與key取值的平均延遲之間的關系.由于ZooKeeper的取值延遲比etcd要快那么2ms左右,想要zetcd提供數據的速度快過ZooKeeper的話恐怕還得依賴于etcd本身性能的進一步提升.然而,盡管zetcd需要從etcd請求額外的key來模擬Zookeeper znode的元數據,zetcd的命中延遲在等待etcd key提取數據方面只增加了大概1.5ms.zetcd在key的數據提取操作方面僅需一次往返,因為讀請求會被打包到一個etcd事務中.

未來

zetcd從去年十月開始在開源社區發行,最近剛發布第一個版本：zetcd v0.0.1.盡管是第一個beta發行版,但是已經為未來生產系統提供穩定管理和部署.如果跟etcd配合起來使用,運行zetcd的系統將會一套自驅動的“ZooKeeper”集群,它可以自動后臺升級,備份和TLS管理.如想了解更多,請參閱?https://github.com/coreos/zetcd/.

深入淺出學習etcd

etcd為分布式系統提供可靠、高效的配置管理服務,在Docker、Kubernetes、Mesos等平臺中扮演了越來越重要的角色.作為2013年開始的項目,它還很年輕,官方文檔中缺乏實現上全面、系統的介紹,本課程深入淺出地介紹了etcd的實現,并為運維和二次開發提供了系統的指導和建議.

文章來自微信公眾號：Docker