ETCD-應用場景

時間 2019-11-08

標籤 etcd 應用場景简体版

原文原文鏈接

場景一：服務發現（Service Discovery）html

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

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

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

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

下面咱們來看服務發現對應的具體場景：負載均衡

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

PaaS平臺中應用多實例與實例故障重啓透明化。PaaS平臺中的應用通常都有多個實例，經過域名，不只能夠透明的對這多個實例進行訪問，並且還能夠作到負載均衡。可是應用的某個實例隨時都有可能故障重啓，這時就須要動態的配置域名解析（路由）中的信息。經過etcd的服務發現功能就能夠輕鬆解決這個動態配置的問題tcp

場景二：消息發佈與訂閱分佈式

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

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

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

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

•系統中信息須要動態自動獲取與人工干預修改信息請求內容的狀況。一般是暴露出接口，例如JMX接口，來獲取一些運行時的信息。引入etcd以後，就不用本身實現一套方案了，只要將這些信息存放到指定的etcd目錄中便可，etcd的這些目錄就能夠經過HTTP的接口在外部訪問。

場景三：負載均衡

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

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

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

場景四：分佈式通知與協調

這裏說到的分佈式通知與協調，與消息發佈和訂閱有些類似。都用到了etcd中的Watcher機制，經過註冊與異步通知機制，實現分佈式環境下不一樣系統之間的通知與協調，從而對數據變動作到實時處理。實現方式一般是這樣：不一樣系統都在etcd上對同一個目錄進行註冊，同時設置Watcher觀測該目錄的變化（若是對子目錄的變化也有須要，能夠設置遞歸模式），當某個系統更新了etcd的目錄，那麼設置了Watcher的系統就會收到通知，並做出相應處理。

•經過etcd進行低耦合的心跳檢測。檢測系統和被檢測系統經過etcd上某個目錄關聯而非直接關聯起來，這樣能夠大大減小系統的耦合性。

•經過etcd完成系統調度。某系統有控制檯和推送系統兩部分組成，控制檯的職責是控制推送系統進行相應的推送工做。管理人員在控制檯做的一些操做，其實是修改了etcd上某些目錄節點的狀態，而etcd就把這些變化通知給註冊了Watcher的推送系統客戶端，推送系統再做出相應的推送任務。

•經過etcd完成工做彙報。大部分相似的任務分發系統，子任務啓動後，到etcd來註冊一個臨時工做目錄，而且定時將本身的進度進行彙報（將進度寫入到這個臨時目錄），這樣任務管理者就可以實時知道任務進度。

場景五：分佈式鎖

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

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

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

場景六：分佈式隊列

分佈式隊列的常規用法與場景五中所描述的分佈式鎖的控制時序用法相似，即建立一個先進先出的隊列，保證順序。

另外一種比較有意思的實現是在保證隊列達到某個條件時再統一按順序執行。這種方法的實現能夠在/queue這個目錄中另外創建一個/queue/condition節點。

•condition能夠表示隊列大小。好比一個大的任務須要不少小任務就緒的狀況下才能執行，每次有一個小任務就緒，就給這個condition數字加1，直到達到大任務規定的數字，再開始執行隊列裏的一系列小任務，最終執行大任務。

•condition能夠表示某個任務在不在隊列。這個任務能夠是全部排序任務的首個執行程序，也能夠是拓撲結構中沒有依賴的點。一般，必須執行這些任務後才能執行隊列中的其餘任務。

•condition還能夠表示其它的一類開始執行任務的通知。能夠由控制程序指定，當condition出現變化時，開始執行隊列任務。

場景七：集羣監控與Leader競選

經過etcd來進行監控實現起來很是簡單而且實時性強。

前面幾個場景已經提到Watcher機制，當某個節點消失或有變更時，Watcher會第一時間發現並告知用戶。

節點能夠設置TTL key，好比每隔30s發送一次心跳使表明該機器存活的節點繼續存在，不然節點消失。

這樣就能夠第一時間檢測到各節點的健康狀態，以完成集羣的監控要求。

另外，使用分佈式鎖，能夠完成Leader競選。這種場景一般是一些長時間CPU計算或者使用IO操做的機器，只須要競選出的Leader計算或處理一次，就能夠把結果複製給其餘的Follower。從而避免重複勞動，節省計算資源。