zetcd：脫離ZooKeeper運行ZooKeeper應用程序

作者 | Anthony Romano

翻譯 | 雁驚寒

譯者註：zetcd是一款架在ZooKeeper與etcd之間的代理程序，它可以將ZooKeeper客戶端的請求消息轉換成etcd要求的格式，並轉發給etcd，然後將響應消息轉換後返回給客戶端。本文介紹了zetcd的使用方法、工作原理以及性能評測。以下是譯文。

分布式系統需要依賴分布式一致性來協調工作。通常情況下，提供分布式一致性擔保信息的系統會接收到按順序投遞過來的消息，這樣就不會產生腦裂衝突（split-brain conflicts，譯者註：本來一個大腦的兩個半球是互相配合的，但是現在分裂變成了兩個獨立的大腦，並且都認為對方已死。此時，雙方都會去嘗試接管集群資源，這樣就可能會造成衝突，產生嚴重的後果）。這類系統的用途是顯而易見的。像chubby、ZooKeeper、etcd、consul這些項目，儘管它們的原理和協議各不相同，但它們都側重於為分布式一致性提供類似的基本鍵值原語。為了讓etcd成為分布式系統中最具吸引力的項目，etcd團隊開發了一款新的代理伺服器程序：zetcd，使用這款軟體，etcd集群無需修改即可處理ZooKeeper客戶端的請求。

ZooKeeper是這方面第一個流行起來的開源軟體，它是很多分布式系統的首選後端軟體。這些系統理論上也可以搭配etcd一起運行，但是由於歷史原因，實際上根本實現不了。etcd集群不支持ZooKeeper，因為etcd的數據模型和客戶端協議與ZooKeeper應用程序不兼容。ZooKeeper應用程序也不是原生的支持etcd；如果系統已經在穩定運行了，那麼沒有必要去為了適應新的後端軟體而讓系統更加複雜。幸運的是，etcd的第三版API相當的牛逼，它可以通過一個普通的代理來模擬ZooKeeper客戶端的數據模型，這就是zetcd，一個由etcd團隊開發的新的開源項目。今天，zetcd發布了第一個測試版，v0.0.1版，這為在生產系統中管理和部署zetcd打下了基礎。

zetcd代理位於etcd集群的前端，它提供了一個模擬ZooKeeper客戶端的埠，讓原版的ZooKeeper應用程序可以運行在etcd上。其基本原理是，zetcd將ZooKeeper客戶端的請求轉換為適合於etcd數據模型和API要求的消息，將發送給etcd，然後將etcd的響應消息轉換後返回給客戶端。該代理的性能可以與ZooKeeper相媲美，利用etcd的特性和工具可以簡化ZooKeeper集群管理。下文將展示zetcd的使用方法和工作原理，並分享一些性能評測數據。

zetcd入門

讓zetcd運行起來需要三樣東西：一個Go編譯器、一個能夠獲取源代碼的互聯網連接，以及一個可以運行etcd的系統。下面的示例展示了如何用源代碼編譯生成zetcd，並對它運行ZooKeeper命令。當我們需要部署正式環境的時候，我們並不建議從開發分支來獲取源代碼並編譯etcd和zetcd，但是如果只是試用一下的話，這是最簡單的方法。

首先，獲取源代碼並編譯etcd和zetcd的二進位文件：

接下來，運行etcd，並將zetcd連接到etcd的客戶端接入點：

試用zetcd，啟動查看並創建一個key：

這個例子展示了在一個獨立的etcd實例上部署了一個zetcd代理層：

一個簡單的zetcd伺服器拓撲

那麼這個zetcd代理層是做什麼的呢？

ZooKeeper接入etcd3

在底層，zetcd將ZooKeeper的數據模型轉換為適合的etcd API的數據。對於key的查找，zetcd將ZooKeeper的分級目錄轉換為etcd的普通二進位keyspace。對於元數據的管理，zetcd利用事務內存安全地和原子地將ZooKeeper znode信息更新到etcd後端。

ZooKeeper是按目錄列出所有的key（getChildren），而etcd是按區間（Range）列出所有的key。下圖說明了zetcd是如何在etcd中對key進行編碼以便可以快速地列出目錄中的key。所有zetcd的key都有一個包括目錄深度的前綴（例如，「/」和「/abc/」分別具有0和1的深度）。要列出一個目錄，zetcd會給出前綴範圍，這個前綴以目錄的深度和路徑來匹配相應的key（例如，前綴範圍[「/zk/key/002/abc/」，「/zk/key/002/abc0」]用於列出/abc/）。這裡的目錄深度是為了限制目錄本身被當作key。如果zetcd將路徑當作是沒有深度的前綴，那麼目錄下的所有key，而不是只有其直接子節點，會由etcd返回並被代理拋棄。

etcd內部的ZooKeeper的key層次結構

每個ZooKeeper的key都在ZNode中攜帶了包含其修改記錄、版本、許可權的元數據。雖然etcd也包含了每個key的元數據，但卻比ZNode中的簡單：沒有子版本，因為沒有目錄；沒有ACL，因為etcd使用基於角色的身份驗證方式；沒有時間戳，因為實時時鐘在etcd的作用範圍之外。這個額外的元數據映射到一組描述了完整的ZNode的key上（見上圖）。如果要調整元數據，zetcd會利用軟體事務內存原子地更新key的子集，這樣就能保持ZNodes的一致性，而不需要昂貴的加鎖解鎖開銷。

此外，zetcd可以對真實的ZooKeeper伺服器動態驗證它的行為。作為比較，zetcd同時連接到etcd和外部ZooKeeper伺服器。當客戶端在此模式下向zetcd發出請求時，請求會同時分發到zetcd和ZooKeeper伺服器。如果兩個伺服器的響應在語義上不一致，那麼zetcd會通過交叉檢查警告對響應進行標記。

微量性能評測

因為數據轉換和網路上的損耗，很有可能就把zetcd的模擬當作是不切實際的做法。儘管單純的ZooKeeper或etcd集群都有一些額外的成本，但是當etcd已安裝並且可以使用，而一些應用程序只支持ZooKeeper調度的時候，zetcd的優勢就體現出來了。例如，早期的用戶報告聲稱，在zetcd中使用etcd的TLS加密流量比加密一個類似的經典的ZooKeeper配置來得更簡單。在這種情況下，相對於簡單地擁有一個可靠的使用ZooKeeper協議的集群來說，性能反而顯得不那麼重要了。

使用zetcd的命令行工具zkboom進行評測可以用來判斷zetcd的性能是否達標。它的評測界面和報告與etcd的評測工具類似。其他的ZooKeeper評測工具也可以用於zetcd；為方便起見，zetcd提供了zkboom這個工具。我們來試一下運行zkboom來測試key的創建：

zetcd可以為小型的工作負載提供足夠的性能。延遲評測表明，使用簡單的雙節點配置，zetcd的模擬可用於中等的請求速率。該配置包含兩台通過千兆交換機連接的現代Linux機器，其中一台機器使用機械磁碟RAID運行代理伺服器軟體，另一台機器用於生成客戶端請求。使用zkboom來測量在一開始為空的key存儲空間中創建和讀取128個位元組的鍵值對的延遲，客戶端請求速率限制為每秒2500個請求，並逐步增加並發客戶端的數量。我們拿ZooKeeper 3.4.10版和etcd的開發分支作比較。

下圖展示了隨著並發客戶端數量的增加，zetcd的平均key創建延遲的變化情況。在本次評測中，由於etcd在延遲上相對於ZooKeeper有5ms到35ms左右的優勢，因此zetcd就有了一些可用於適應網路損耗和數據處理的餘量。zetcd代理比ZooKeeper遜色了大概20ms左右，但從吞吐量來看，並沒有產生積壓，因為它仍然保持了每秒2500個請求的速率。zetcd寫入速度慢的一種解釋是，它從etcd讀取key的同時，由於數據模型的差異，要為每個新的ZooKeeper的key同時往etcd寫入多個key。

隨著並發客戶端數量的增加，平均key創建延遲的變化情況（越低越好）

下圖顯示了隨著並發客戶端數量的增加，平均key獲取延遲的變化情況。ZooKeeper的獲取延遲比etcd稍低，差距大約為2ms左右，所以zetcd需要進一步的優化才有可能比ZooKeeper更快。為了模擬ZooKeeper znode元數據，儘管需要從etcd獲取額外的key，但是zetcd延遲命中只比etcd獲取key增加了大約1.5ms左右。這是因為zetcd獲取key的操作只需要一次往返，所有的讀取請求都被加入到單個etcd事務中。

隨著並發客戶端數量的增加，平均key獲取延遲的變化情況（越低越好）

向v0.0.1及以上版本發展

到目前為止，zetcd的前途是光明的。它的性能是合格的，可以輕鬆支撐每秒超過一千次的操作，並且延遲也是在可接受的範圍之內。它的模擬已經足夠接近ZooKeeper，可以替代Mesos，Kafka和Drill。但是在性能調優方面仍有一定的提升空間。同時，使用更多的ZooKeeper應用程序進行測試能夠加快zetcd對ZooKeeper伺服器的替代。

zetcd自去年10月份開始出現在開源社區上，並剛剛推出了第一個版本：zetcd v0.0.1。作為發布的第一個beta版本，zetcd為將來在生產系統中進行管理和部署做好了準備。當與etcd Operator配合使用時，這些運行zetcd的系統將成為具有自動後端升級、備份和TLS管理功能的自驅動「ZooKeeper」集群。要了解更多信息、提問或提出改進意見，請訪問zetcd GitHub，網址：https://github.com/coreos/zetcd/。

點擊展開全文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！