隨 著CoreOS和Kubernetes等項目在開源社區(qū)日益火熱，它們項目中都用到的etcd組件作為一個高可用強一致性的服務發(fā)現存儲倉庫，漸漸為開發(fā)人員所關注。在云計算時代，如何讓服務快速透明地接入到計算集群中，如何讓共享配置信息快速被集群中的所有機器發(fā)現，更為重要的是，如何構建這樣一套高可用、安全、易于部署以及響應快速的服務集群，已經成為了迫切需要解決的問題。etcd為解決這類問題帶來了福音，本文將從etcd的應用場景開始，深入解讀etcd的實現方式，以供開發(fā)者們更為充分地享用etcd所帶來的便利。

etcd 是一個高可用的 Key/Value 存儲系統(tǒng)，主要用于分享配置和服務發(fā)現。etcd 的靈感來自于 ZooKeeper 和 Doozer，側重于：

• 簡單：支持 curl 方式的用戶 API (HTTP+JSON)
• 安全：可選 SSL client證書認證
• 高速：單實例可達每秒 1000 次寫操作
• 可靠：使用 Raft 實現分布式

Etcd is written in Go and uses the raft consensus algorithm to manage a highly-available replicated log.

經典應用場景

要問etcd是什么？很多人第一反應可能是一個鍵值存儲倉庫，卻沒有重視官方定義的后半句，用于配置共享和服務發(fā)現。

A highly-available key value store for shared configuration and service discovery.

實際上，etcd作為一個受到ZooKeeper與doozer啟發(fā)而催生的項目，除了擁有與之類似的功能外，更專注于以下四點。

• 簡單：基于HTTP+JSON的API讓你用curl就可以輕松使用。
• 安全：可選SSL客戶認證機制。
• 快速：每個實例每秒支持一千次寫操作。
• 可信：使用Raft算法充分實現了分布式。

隨著云計算的不斷發(fā)展，分布式系統(tǒng)中涉及到的問題越來越受到人們重視。受阿里中間件團隊對ZooKeeper典型應用場景一覽一文的啟發(fā)，筆者根據自己的理解也總結了一些etcd的經典使用場景。讓我們來看看etcd這個基于Raft強一致性算法的分布式存儲倉庫能給我們帶來哪些幫助。

值得注意的是，分布式系統(tǒng)中的數據分為控制數據和應用數據。使用etcd的場景默認處理的數據都是控制數據，對于應用數據，只推薦數據量很小，但是更新訪問頻繁的情況。

場景一：服務發(fā)現（Service Discovery）

服務發(fā)現要解決的也是分布式系統(tǒng)中最常見的問題之一，即在同一個分布式集群中的進程或服務，要如何才能找到對方并建立連接。本質上來說，服務發(fā)現就是想要了 解集群中是否有進程在監(jiān)聽udp或tcp端口，并且通過名字就可以查找和連接。要解決服務發(fā)現的問題，需要有下面三大支柱，缺一不可。

• 一個強一致性、高可用的服務存儲目錄。基于Raft算法的etcd天生就是這樣一個強一致性高可用的服務存儲目錄。
• 一種注冊服務和監(jiān)控服務健康狀態(tài)的機制。用戶可以在etcd中注冊服務，并且對注冊的服務設置key TTL，定時保持服務的心跳以達到監(jiān)控健康狀態(tài)的效果。
• 一種查找和連接服務的機制。通過在etcd指定的主題下注冊的服務也能在對應的主題下查找到。為了確保連接，我們可以在每個服務機器上都部署一個Proxy模式的etcd，這樣就可以確保能訪問etcd集群的服務都能互相連接。

圖1 服務發(fā)現示意圖.jpg

下面我們來看服務發(fā)現對應的具體場景。

• 微服務協(xié)同工作架構中，服務動態(tài)添加。隨著Docker容器的流行，多種微服務共同協(xié)作，構成一個相對功能強大的架構的案例越來越多。透明化的動態(tài)添加這些服務的需求也日益強烈。通過服務發(fā)現 機制，在etcd中注冊某個服務名字的目錄，在該目錄下存儲可用的服務節(jié)點的IP。在使用服務的過程中，只要從服務目錄下查找可用的服務節(jié)點去使用即可。

圖2 微服務協(xié)同工作.jpg

• PaaS平臺中應用多實例與實例故障重啟透明化。PaaS平臺中的應用一般都有多個實例，通過域名，不僅可以透明的對這多個實例進行訪問，而且還可以做到負載均衡。但是應用的某個實例隨時都有可能故障重啟，這時就需要動態(tài)的配置域名解析（路由）中的信息。通過etcd的服務發(fā)現功能就可以輕松解決這個動態(tài)配置的問題。

圖3 云平臺多實例透明化.jpg

場景二：消息發(fā)布與訂閱

在分布式系統(tǒng)中，最適用的一種組件間通信方式就是消息發(fā)布與訂閱。即構建一個配置共享中心，數據提供者在這個配置中心發(fā)布消息，而消息使用者則訂閱他們關心的主題，一旦主題有消息發(fā)布，就會實時通知訂閱者。通過這種方式可以做到分布式系統(tǒng)配置的集中式管理與動態(tài)更新。

• 應用中用到的一些配置信息放到etcd上進行集中管理。這類場景的使用方式通常是這樣：應用在啟動的時候主動從etcd獲取一次配置信息，同時，在etcd節(jié)點上注冊一個Watcher并等待，以后每次配置有更新的時候，etcd都會實時通知訂閱者，以此達到獲取最新配置信息的目的。
• 分布式搜索服務中，索引的元信息和服務器集群機器的節(jié)點狀態(tài)存放在etcd中，供各個客戶端訂閱使用。使用etcd的key TTL功能可以確保機器狀態(tài)是實時更新的。
• 分布式日志收集系統(tǒng)。 這個系統(tǒng)的核心工作是收集分布在不同機器的日志。收集器通常是按照應用（或主題）來分配收集任務單元，因此可以在etcd上創(chuàng)建一個以應用（主題）命名的 目錄P，并將這個應用（主題相關）的所有機器ip，以子目錄的形式存儲到目錄P上，然后設置一個etcd遞歸的Watcher，遞歸式的監(jiān)控應用（主題） 目錄下所有信息的變動。這樣就實現了機器IP（消息）變動的時候，能夠實時通知到收集器調整任務分配。
• 系統(tǒng)中信息需要動態(tài)自動獲取與人工干預修改信息請求內容的情況。通常是暴露出接口，例如JMX接口，來獲取一些運行時的信息。引入etcd之后，就不用自己實現一套方案了，只要將這些信息存放到指定的etcd目錄中即可，etcd的這些目錄就可以通過HTTP的接口在外部訪問。

圖4 消息發(fā)布與訂閱.jpg

場景三：負載均衡

在場景一中 也提到了負載均衡，本文所指的負載均衡均為軟負載均衡。分布式系統(tǒng)中，為了保證服務的高可用以及數據的一致性，通常都會把數據和服務部署多份，以此達到對 等服務，即使其中的某一個服務失效了，也不影響使用。由此帶來的壞處是數據寫入性能下降，而好處則是數據訪問時的負載均衡。因為每個對等服務節(jié)點上都存有 完整的數據，所以用戶的訪問流量就可以分流到不同的機器上。

etcd本身分布式架構存儲的信息訪問支持負載均衡。 etcd集群化以后，每個etcd的核心節(jié)點都可以處理用戶的請求。所以，把數據量小但是訪問頻繁的消息數據直接存儲到etcd中也是個不錯的選擇，如業(yè) 務系統(tǒng)中常用的二級代碼表（在表中存儲代碼，在etcd中存儲代碼所代表的具體含義，業(yè)務系統(tǒng)調用查表的過程，就需要查找表中代碼的含義）。
利用etcd維護一個負載均衡節(jié)點表。etcd可以監(jiān)控一個集群中多個節(jié)點的狀態(tài)，當有一個請求發(fā)過來后，可以輪詢式的把請求轉發(fā)給存活著的多個狀態(tài)。類似KafkaMQ，通過ZooKeeper來維護生產者和消費者的負載均衡。同樣也可以用etcd來做ZooKeeper的工作。

圖5 負載均衡.jpg

場景四：分布式通知與協(xié)調

這 里說到的分布式通知與協(xié)調，與消息發(fā)布和訂閱有些相似。都用到了etcd中的Watcher機制，通過注冊與異步通知機制，實現分布式環(huán)境下不同系統(tǒng)之間 的通知與協(xié)調，從而對數據變更做到實時處理。實現方式通常是這樣：不同系統(tǒng)都在etcd上對同一個目錄進行注冊，同時設置Watcher觀測該目錄的變化 （如果對子目錄的變化也有需要，可以設置遞歸模式），當某個系統(tǒng)更新了etcd的目錄，那么設置了Watcher的系統(tǒng)就會收到通知，并作出相應處理。

• 通過etcd進行低耦合的心跳檢測。檢測系統(tǒng)和被檢測系統(tǒng)通過etcd上某個目錄關聯(lián)而非直接關聯(lián)起來，這樣可以大大減少系統(tǒng)的耦合性。
• 通過etcd完成系統(tǒng)調度。某系統(tǒng)有控制臺和推送系統(tǒng)兩部分組成，控制臺的職責是控制推送系統(tǒng)進行相應的推送工作。管理人員在控制臺作的一些操作，實際上是修改了etcd上某些目錄節(jié)點的狀態(tài)，而etcd就把這些變化通知給注冊了Watcher的推送系統(tǒng)客戶端，推送系統(tǒng)再作出相應的推送任務。
• 通過etcd完成工作匯報。大部分類似的任務分發(fā)系統(tǒng)，子任務啟動后，到etcd來注冊一個臨時工作目錄，并且定時將自己的進度進行匯報（將進度寫入到這個臨時目錄），這樣任務管理者就能夠實時知道任務進度。

圖6 分布式協(xié)同工作.jpg

場景五：分布式鎖

因為etcd使用Raft算法保持了數據的強一致性，某次操作存儲到集群中的值必然是全局一致的，所以很容易實現分布式鎖。鎖服務有兩種使用方式，一是保持獨占，二是控制時序。

• 保持獨占即所有獲取鎖的用戶最終只有一個可以得到。etcd為此提供了一套實現分布式鎖原子操作CAS（CompareAndSwap）的API。通過設置prevExist值，可以保證在多個節(jié)點同時去創(chuàng)建某個目錄時，只有一個成功。而創(chuàng)建成功的用戶就可以認為是獲得了鎖。
• 控制時序，即所有想要獲得鎖的用戶都會被安排執(zhí)行，但是獲得鎖的順序也是全局唯一的，同時決定了執(zhí)行順序。etcd為此也提供了一套API（自動創(chuàng)建有序鍵），對一個目錄建值時指定為POST動作，這樣etcd會自動在目錄下生成一個當前最大的值為鍵，存儲這個新的值（客戶端編號）。同時還可以使用API按順序列出所有當前目錄下的鍵值。此時這些鍵的值就是客戶端的時序，而這些鍵中存儲的值可以是代表客戶端的編號。

圖7 分布式鎖.jpg

場景六：分布式隊列

分布式隊列的常規(guī)用法與場景五中所描述的分布式鎖的控制時序用法類似，即創(chuàng)建一個先進先出的隊列，保證順序。

另一種比較有意思的實現是在保證隊列達到某個條件時再統(tǒng)一按順序執(zhí)行。這種方法的實現可以在/queue這個目錄中另外建立一個/queue/condition節(jié)點。

• condition可以表示隊列大小。比如一個大的任務需要很多小任務就緒的情況下才能執(zhí)行，每次有一個小任務就緒，就給這個condition數字加1，直到達到大任務規(guī)定的數字，再開始執(zhí)行隊列里的一系列小任務，最終執(zhí)行大任務。
• condition可以表示某個任務在不在隊列。這個任務可以是所有排序任務的首個執(zhí)行程序，也可以是拓撲結構中沒有依賴的點。通常，必須執(zhí)行這些任務后才能執(zhí)行隊列中的其他任務。
• condition還可以表示其它的一類開始執(zhí)行任務的通知。可以由控制程序指定，當condition出現變化時，開始執(zhí)行隊列任務。

圖8 分布式隊列.jpg

場景七：集群監(jiān)控與Leader競選

通過etcd來進行監(jiān)控實現起來非常簡單并且實時性強。

1. 前面幾個場景已經提到Watcher機制，當某個節(jié)點消失或有變動時，Watcher會第一時間發(fā)現并告知用戶。
2. 節(jié)點可以設置TTL key，比如每隔30s發(fā)送一次心跳使代表該機器存活的節(jié)點繼續(xù)存在，否則節(jié)點消失。

這樣就可以第一時間檢測到各節(jié)點的健康狀態(tài)，以完成集群的監(jiān)控要求。

另外，使用分布式鎖，可以完成Leader競選。這種場景通常是一些長時間CPU計算或者使用IO操作的機器，只需要競選出的Leader計算或處理一次，就可以把結果復制給其他的Follower。從而避免重復勞動，節(jié)省計算資源。

這個的經典場景是搜索系統(tǒng)中建立全量索引。如果每個機器都進行一遍索引的建立，不但耗時而且建立索引的一致性不能保證。通過在etcd的CAS機制同時創(chuàng)建一個節(jié)點，創(chuàng)建成功的機器作為Leader，進行索引計算，然后把計算結果分發(fā)到其它節(jié)點。

圖9 Leader競選.jpg

場景八：為什么用etcd而不用ZooKeeper？

閱讀了“ZooKeeper典型應用場景一覽”一文的讀者可能會發(fā)現，etcd實現的這些功能，ZooKeeper都能實現。那么為什么要用etcd而非直接使用ZooKeeper呢？
相較之下，ZooKeeper有如下缺點：

• 復雜。ZooKeeper的部署維護復雜，管理員需要掌握一系列的知識和技能；而Paxos強一致性算法也是素來以復雜難懂而聞名于世；另外，ZooKeeper的使用也比較復雜，需要安裝客戶端，官方只提供了Java和C兩種語言的接口。
• Java編寫。這里不是對Java有偏見，而是Java本身就偏向于重型應用，它會引入大量的依賴。而運維人員則普遍希望保持強一致、高可用的機器集群盡可能簡單，維護起來也不易出錯。
• 發(fā)展緩慢。Apache基金會項目特有的“Apache Way”在開源界飽受爭議，其中一大原因就是由于基金會龐大的結構以及松散的管理導致項目發(fā)展緩慢。

而etcd作為一個后起之秀，其優(yōu)點也很明顯。

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

最 后，etcd作為一個年輕的項目，真正告訴迭代和開發(fā)中，這既是一個優(yōu)點，也是一個缺點。優(yōu)點是它的未來具有無限的可能性，缺點是無法得到大項目長時間使 用的檢驗。然而，目前CoreOS、Kubernetes和CloudFoundry等知名項目均在生產環(huán)境中使用了etcd，所以總的來說，etcd值 得你去嘗試。