ETCD簡介

隨着CoreOS和Kubernetes等項目在開源社區日益火熱，它們項目中都用到的etcd組件做爲一個高可用、強一致性的服務發現存儲倉庫，漸漸爲開發人員所關注。

etcd是一個高可用的鍵值存儲系統，主要用於共享鍵值倉庫和服務發現。etcd是由CoreOS開發並維護的，靈感來自於 ZooKeeper 和 Doozer，它使用Go語言編寫，並經過Raft一致性算法處理日誌複製以保證強一致性。Raft是一個新的一致性算法，適用於分佈式系統的日誌複製，Raft經過選舉的方式來實現一致性。Google的容器集羣管理系統Kubernetes、開源PaaS平臺Cloud Foundry和CoreOS的Fleet都普遍使用了etcd。在分佈式系統中，如何管理節點間的狀態一直是一個難題，etcd像是專門爲集羣環境的服務發現和註冊而設計，它提供了數據TTL失效、數據改變監視、多值、目錄監聽、分佈式鎖原子操做等功能，能夠方便的跟蹤並管理集羣節點的狀態。

特性總結以下：

1.簡單: 支持curl方式的用戶API（HTTP+JSON）
2.安全: 可選的SSL客戶端證書認證
3.快速: 單實例每秒 1000 次寫操做
4.可靠: 使用Raft保證一致性

接下來介紹etcd應用的一些主要場合

場景一：服務發現

服務發現（Service Discovery）要解決的是分佈式系統中最多見的問題之一，即在同一個分佈式集羣中的進程或服務如何才能找到對方並創建鏈接。從本質上說，服務發現就是想要了解集羣中是否有進程在監聽udp或tcp端口，而且經過名字就能夠進行查找和鏈接。要解決服務發現的問題，須要有下面三大支柱，缺一不可。

1.一個強一致性、高可用的服務存儲目錄。基於Raft算法的etcd天生就是這樣一個強一致性高可用的服務存儲目錄。

2.一種註冊服務和監控服務健康狀態的機制。用戶能夠在etcd中註冊服務，而且對註冊的服務設置key TTL，定時保持服務的心跳以達到監控健康狀態的效果。

3.一種查找和鏈接服務的機制。經過在etcd指定的主題下注冊的服務也能在對應的主題下查找到。爲了確保鏈接，咱們能夠在每一個服務機器上都部署一個proxy模式的etcd，這樣就能夠確保能訪問etcd集羣的服務都能互相鏈接。

下面咱們來看一下服務發現對應的具體應用場景。

微服務協同工做架構中，服務動態添加。隨着Docker容器的流行，多種微服務共同協做，構成一個功能相對強大的架構的案例愈來愈多。透明化的動態添加這些服務的需求也日益強烈。經過服務發現機制，在etcd中註冊某個服務名字的目錄，在該目錄下存儲可用的服務節點的IP。在使用服務的過程當中，只要從服務目錄下查找可用的服務節點進行使用便可。 微服務協同工做如圖2所示。

場景二：消息發佈與訂閱

在分佈式系統中，最爲適用的組件間通訊方式是消息發佈與訂閱機制。具體而言，即構建一個配置共享中心，數據提供者在這個配置中心發佈消息，而消息使用者則訂閱他們關心的主題，一旦相關主題有消息發佈，就會實時通知訂閱者。經過這種方式能夠實現分佈式系統配置的集中式管理與實時動態更新。

應用中用到的一些配置信息存放在etcd上進行集中管理。這類場景的使用方式一般是這樣的：應用在啓動的時候主動從etcd獲取一次配置信息，同時，在etcd節點上註冊一個Watcher並等待，之後每次配置有更新的時候，etcd都會實時通知訂閱者，以此達到獲取最新配置信息的目的。

分佈式搜索服務中，索引的元信息和服務器集羣機器的節點狀態信息存放在etcd中，供各個客戶端訂閱使用。使用etcd的key TTL功能能夠確保機器狀態是實時更新的。

分佈式日誌收集系統。這個系統的核心工做是收集分佈在不一樣機器上的日誌。收集器一般按照應用（或主題）來分配收集任務單元，所以能夠在etcd上建立一個以應用（或主題）命名的目錄P，並將這個應用（或主題）相關的全部機器ip，以子目錄的形式存儲在目錄P下，而後設置一個遞歸的etcd Watcher，遞歸式地監控應用（或主題）目錄下全部信息的變更。這樣就實現了在機器IP（消息）發生變更時，可以實時通知收集器調整任務分配。

系統中信息須要動態自動獲取與人工干預修改信息請求內容的狀況。一般的解決方案是對外暴露接口，例如JMX接口，來獲取一些運行時的信息或提交修改的請求。而引入etcd以後，只須要將這些信息存放到指定的etcd目錄中，便可經過HTTP接口直接被外部訪問。

場景三：負載均衡

在場景一中也提到了負載均衡，本文說起的負載均衡均指軟負載均衡。在分佈式系統中，爲了保證服務的高可用以及數據的一致性，一般都會把數據和服務部署多份，以此達到對等服務，即便其中的某一個服務失效了，也不影響使用。這樣的實現雖然會致使必定程度上數據寫入性能的降低，可是卻能實現數據訪問時的負載均衡。由於每一個對等服務節點上都存有完整的數據，因此用戶的訪問流量就能夠分流到不一樣的機器上。

etcd自己分佈式架構存儲的信息訪問支持負載均衡。etcd集羣化之後，每一個etcd的核心節點均可以處理用戶的請求。因此，把數據量小可是訪問頻繁的消息數據直接存儲到etcd中也是個不錯的選擇，如業務系統中經常使用的二級代碼表。二級代碼表的工做過程通常是這樣，在表中存儲代碼，在etcd中存儲代碼所表明的具體含義，業務系統調用查表的過程，就須要查找表中代碼的含義。因此若是把二級代碼表中的小量數據存儲到etcd中，不只方便修改，也易於大量訪問。

利用etcd維護一個負載均衡節點表。etcd能夠監控一個集羣中多個節點的狀態，當有一個請求發過來後，能夠輪詢式地把請求轉發給存活着的多個節點。相似KafkaMQ，經過Zookeeper來維護生產者和消費者的負載均衡。一樣也能夠用etcd來作Zookeeper的工做。

場景四：分佈式鎖/分佈式隊列

由於etcd使用Raft算法保持了數據的強一致性，某次操做存儲到集羣中的值必然是全局一致的，因此很容易實現分佈式鎖。鎖服務有兩種使用方式，一是保持獨佔，二是控制時序。

保持獨佔，即全部試圖獲取鎖的用戶最終只有一個能夠獲得。etcd爲此提供了一套實現分佈式鎖原子操做CAS（CompareAndSwap）的API。經過設置prevExist值，能夠保證在多個節點同時建立某個目錄時，只有一個成功，而該用戶便可認爲是得到了鎖。

控制時序，即全部試圖獲取鎖的用戶都會進入等待隊列，得到鎖的順序是全局惟一的，同時決定了隊列執行順序。etcd爲此也提供了一套API（自動建立有序鍵），對一個目錄建值時指定爲POST動做，這樣etcd會自動在目錄下生成一個當前最大的值爲鍵，存儲這個新的值（客戶端編號）。同時還可使用API按順序列出全部當前目錄下的鍵值。此時這些鍵的值就是客戶端的時序，而這些鍵中存儲的值能夠是表明客戶端的編號。

爲何使用etcd而非zookeeper

etcd實現的這些功能，Zookeeper都能實現。那麼爲何要用etcd而非直接使用Zookeeper呢？

相較之下，Zookeeper有以下缺點：

1.複雜。Zookeeper的部署維護複雜，管理員須要掌握一系列的知識和技能；而Paxos強一致性算法也是素來以複雜難懂而聞名於世；另外，Zookeeper的使用也比較複雜，須要安裝客戶端，官方只提供了java和C兩種語言的接口。
2.Java編寫。這裏不是對Java有偏見，而是Java自己就偏向於重型應用，它會引入大量的依賴。而運維人員則廣泛但願機器集羣儘量簡單，維護起來也不易出錯。

3.發展緩慢。Apache基金會項目特有的「Apache Way」在開源界飽受爭議，其中一大緣由就是因爲基金會龐大的結構以及鬆散的管理致使項目發展緩慢。

而etcd做爲一個後起之秀，其優勢也很明顯：

1.簡單。使用Go語言編寫部署簡單；使用HTTP做爲接口使用簡單；使用Raft算法保證強一致性讓用戶易於理解。2.數據持久化。etcd默認數據一更新就進行持久化。3.安全。etcd支持SSL客戶端安全認證。