etcd應用

etcd組件做爲一個高可用、強一致性的服務發現存儲倉庫，漸漸爲開發人員所關注。在雲計算時代，若是讓服務快速透明地接入到計算集羣中。若是讓共享配置信息快速被集羣中的全部機器發現，更爲重要的是，如何構建這樣一套高可用、安全、易於部署以及響應快速的服務集羣，已經成爲了迫切須要解決的問題。
etcd：A highly-available key value store for shared configuration and service discovery.
實際上，etcd做爲一個受到zk和docker啓發而催生的項目，除了擁有與之相似的功能外，更具備如下4個特色。
（1）簡單：基於HTTP+JSON的API讓你用curl命令就能夠輕鬆使用。
（2）安全：可選SSL客戶認證機制
（3）快速：每一個實例每秒支持一千多寫操做
（4）可信：使用Raft算法充分實現了分佈式

分佈式系統中的數據分爲控制數據和應用數據。使用etcd的場景處理的數據默認爲控制數據，對於應用數據，只推薦處理數據量很小，可是更新訪問頻繁的狀況。

1. 服務發現

服務發現（Service Discovery）要解決的是分佈式系統中最經常使用的問題之一，即在同一個分佈式集羣中的進程或服務如何才能找到對方並創建鏈接。從本質上說，服務發現就是想要了解集羣中是否有進程在監聽udp或tcp端口，而且經過名字就能夠進行查找和鏈接。要解決服務發現的問題，須要有三大支柱：
（1）一個強一致性、高可用的服務存儲目錄。基於Raft算法的etcd天生就是這樣一個強一致性高可用的服務存儲目錄。
（2）一種註冊服務和監控服務健康狀態的機制。用戶能夠在etcd中註冊服務，而且對註冊的服務設置key TTL，定時保持服務的心跳以達到監控健康狀態的效果
（3）一種查找和鏈接服務的機制。經過在etcd指定的主題下注冊的服務也能在對應的主題下查找到。爲了確保鏈接，能夠在每一個服務器上部署一個proxy模式的etcd，這樣就能夠確保能訪問etcd集羣的服務都能互相鏈接。

下面咱們一塊兒看服務發現對應的具體應用場景。
（1）微服務協同工做架構中，服務動態添加。
多種微服務共同協做，構成一個功能相對強大的架構的案例愈來愈多。透明化的動態添加這些服務的需求也日益強烈。經過服務發現機制，在etcd中註冊某個服務名字的目錄，在該目錄下存儲可用的服務節點的IP。在使用服務的過程當中，只要從服務目錄下查找可用的服務節點進行使用便可。
（2）PaaS平臺中應用多實例與實力故障重啓透明化。
PaaS平臺中的應用通常都有多個實例，經過域名，不只能夠透明地對多個實例進行訪問，並且還能夠實現負載均衡。可是應用的某個實例隨時都有可能故障重啓，這時就須要動態地配置域名解析中的信息。經過etcd的服務發現功能就能夠輕鬆解決這個動態配置的問題。

2. 信息發佈與訂閱

在分佈式系統中，最爲適用的組件見通訊方式是消息發佈與訂閱機制。具體而言，即構建一個配置共享中心，數據提供者在這個配置中心發佈信息，而信息使用者則訂閱他們關心的主題，一旦相關主題有信息發佈，就會實時通知訂閱者。經過這種方式能夠實現分佈式系統配置的集中式管理與實時動態更新。
（1）應用中用到的一些信息存放在etcd上進行集中管理。這類場景的使用方式一般是這樣的：應用在啓動的時候主動從etcd獲取一次配置信息，同時，在etcd節點上註冊一個watcher並等待，之後每次配置有更新的時候，etcd都會實時通知訂閱者，以此達到獲取最新配置信息的目的。
（2）分佈式搜索服務中，索引的源信息和服務器集羣的節點狀態信息存放在etcd中，供各個客戶端訂閱使用。使用etcd的key TTL供能夠確保機器狀態是實時更新的。
（3）分佈式日誌收集系統。這個系統的核心工做是收集分佈在不一樣機器上的日誌。收集器一般按照應用（或主題）來分配收集任務單元，所以能夠在etcd上建立一個以應用（或主題）命名的目錄P，並將這個應用相關的全部機器IP，以子目錄的形式存儲在目錄P下，而後設置一個遞歸的etcd Watcher，遞歸式地監控應用目錄下全部信息的變更。這樣就試下了在機器IP（信息）發生變更時，可以實時通知收集器調整任務分配。
（4）系統中信息須要動態自動獲取與人工干預修改信息請求內容的狀況。一般的解決方案是對外暴露接口，來獲取一些運行時的信息或提交修改的請求，而引入etcd以後，只須要將這些信息存放到指定的etcd目錄中，便可經過HTTP接口直接被外部訪問。

3. 負載均衡

本節的負載均衡指軟負載均衡。在分佈式系統中，爲了保證服務的高可用以及數據的一致性，一般都會把數據和服務部署多份，以此達到對等服務，即便其中的某一個服務失效了，也不影響使用。這樣的實現雖然會致使必定程度上數據寫入性能的降低，可是卻能實現數據訪問時的負載均衡。由於每一個對等服務節點上都存有完整的數據，因此用戶的訪問流量就能夠分流到不一樣的機器上。
（1）etcd自己分佈式架構存儲的信息訪問支持負載均衡。etcd集羣化之後，每一個etcd的核心節點均可以處理用戶的請求。因此，把數據量小可是訪問頻繁的消息數據直接存儲到etcd中也是個不錯的選擇。
（2）利用etcd維護一個負載均衡節點表。etcd能夠監控一個集羣中多個節點的狀態，當有一個請求發過來後，能夠輪詢式地把請求轉發給存活着的多個節點。

4. 分佈式通知與協調

與消息發佈和訂閱有些類似。二者都使用了etcd的watcher機制，經過註冊於異步通知截止，實現分佈式環境下不一樣系統之間的通知與協調，從而對數據變動進行實時處理。實現方式一般爲：不一樣系統都在etcd上對同一個目錄進行註冊，同時設置watcher監控該目錄的變化，當某個系統更新了etcd的目錄，那麼設置了watcher的系統就會收到通知，並做出相應處理。
（1）經過etcd記性低耦合的心跳檢測。檢測系統和被檢測系統經過etcd上某個目錄關聯而非直接關聯起來，這樣能夠大大減小系統的耦合性。
（2）經過etcd完成系統調度。某系統有控制檯和推送系統兩部分組成，控制檯的職責是控制推送系統進行相應的推送工做。管理人員在控制檯作的一些操做，實際上只須要修改etcd上某些目錄節點的狀態，而etcd就會自動把這些變化通知給註冊了watcher的推送客戶端，推送系統再作出相應的推送任務。
（3）經過etcd完成工做彙報。大部分相似的任務分發系統，子任務啓動後，到etcd來註冊一個臨時工做目錄，而且定時將本身的精度進行彙報（將精度寫入到這個臨時目錄），這樣任務管理者就可以實時知道任務進度。

5. 分佈式鎖

由於etcd使用Raft算法保持了數據的強一致性，某次操做存儲到集羣中的值必然是全局一致的，因此很容易實現分佈式鎖。鎖服務有兩種使用方式，一是保持獨佔，二是控制時序。
（1）保持獨佔，即全部試圖獲取鎖的用戶最終只有一個能夠獲得。etcd爲此提供了一套實現分佈式鎖原子操做CAS的API。經過設置prevExist值，能夠保證在多個節點同時建立某個目錄時，只有一個成功，而該用戶便可認爲是得到了鎖。
（2）控制時序，即全部試圖獲取鎖的用戶都會進入等待隊列，得到鎖的順序是全局惟一的，同時決定了隊列執行順序。etcd爲此也提供了一套API。

6. 分佈式隊列