雲原生必備知識： etcd

所屬技術領域：

雲原生

|名詞定義|

etcd is a distributed, consistent key-value store for shared configuration and service discovery, with a focus on being:

Secure: automatic TLS with optional client cert authentication[可選的SSL用戶端證書認證：支援https通路 ]

Fast: benchmarked 10,000 writes/sec[單執行個體每秒 1000 次寫操作]

Reliable: properly distributed using Raft[使用Raft保證一緻性]

etcd是一個分布式、一緻性的鍵值存儲系統，主要用于配置共享和服務發現。[以上内容來自etcd官網]

|發展曆程 |

etcd 誕生于 CoreOS 公司，它最初是用于解決叢集管理系統中 OS 更新的分布式并發控制以及配置檔案的存儲與分發等問題。基于此，etcd 被設計為提供高可用、強一緻的小型 keyvaluekey-value 資料存儲服務。

項目目前隸屬于 CNCF 基金會，被 AWS、Google、Microsoft、Alibaba 等大型網際網路公司廣泛使用。

最初，在 2013 年 6 月份由 CoreOS 公司向 GitHub 中送出了第一個版本的初始代碼。

到了 2014 年的 6 月，社群發生了一件事情，Kubernetes v0.4 版本釋出。這裡有必要介紹一下 Kubernetes 項目，它首先是一個容器管理平台，由谷歌開發并貢獻給社群，因為它集齊了谷歌在容器排程以及叢集管理等領域的多年經驗，從誕生之初就備受矚目。在 Kubernetes v0.4 版本中，它使用了 etcd 0.2 版本作為實驗核心中繼資料的存儲服務，自此 etcd 社群得到了飛速的發展。

很快，在 2015 年 2 月份，etcd 釋出了第一個正式的穩定版本 2.0。在 2.0 版本中，etcd 重新設計了 Raft 一緻性算法，并為使用者提供了一個簡單的樹形資料視圖，在 2.0 版本中 etcd 支援每秒超過 1000 次的寫入性能，滿足了當時絕大多數的應用場景需求。2.0 版本釋出之後，經過不斷的疊代與改進，其原有的資料存儲方案逐漸成為了新時期的性能瓶頸，之後 etcd 啟動了 v3 版本的方案設計。

2017 年 1 月份的時候，etcd 釋出了 3.1 版本，v3 版本方案基本上标志着 etcd 技術上全面成熟。在 v3 版本中 etcd 提供了一套全新的 API，重新實作了更高效的一緻性讀取方法，并且提供了一個 gRPC 的 proxy 用于擴充 etcd 的讀取性能。同時，在 v3 版本的方案中包含了大量的 GC 優化，在性能優化方面取得了長足的進步，在該版本中 etcd 可以支援每秒超過 10000 次的寫入。

2018 年，CNCF 基金會下的衆多項目都使用了 etcd 作為其核心的資料存儲。據不完全統計，使用 etcd 的項目超過了 30 個，在同年 11 月份，etcd 項目自身也成為了 CNCF 旗下的孵化項目。進入 CNCF 基金會後，etcd 擁有了超過 400 個貢獻組，其中包含了來自 AWS、Google、Alibaba 等 8 個公司的 9 個項目維護者。

2019 年，etcd 即将釋出全新的 3.4 版本，該版本由 Google、Alibaba 等公司聯合打造，将進一步改進 etcd 的性能及穩定性，以滿足在超大型公司使用中苛刻的場景要求。

|技術特點|

 簡單：基于HTTP+JSON的API讓你用curl指令就可以輕松使用。

 安全：可選SSL客戶認證機制。

 快速：每個執行個體每秒支援一千次寫操作。

 可信：使用Raft算法充分實作了分布式。 強一緻性

适用場景：

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

在分布式系統中“服務發現”也是比較常見的問題：在同一個叢集環境中不同的應用或服務，如何能夠找到對方并建立連接配接，來完成後續的行為。本質上來說，服務發現就是想要知道叢集中是否有程序在監聽udp或tcp端口，并能通過名字就可以查找和連接配接。而要解決服務發現的問題，需要滿足如下三個方面，缺一不可。

1. 一個強一緻性、高可用的服務存儲目錄： 基于Raft算法的etcd天生就是這樣一個強一緻性高可用的服務存儲目錄【安全的記錄叢集中的應用或服務的資訊(位址、端口等)】。
2. 一種注冊服務和監控服務健康狀态的機制：使用者可以在etcd中注冊服務，并且對注冊的服務設定key TTL，定時保持服務的心跳以達到監控健康狀态的效果。【能夠完成新的應用或服務的注冊添加進來，同樣也能對現有的服務是否可用進行監控】

3. 一種查找和連接配接服務的機制： 通過在etcd指定的主題下注冊的服務也能在對應的主題下查找到。為了確定連接配接，我們可以在每個服務機器上都部署一個Proxy模式的etcd，這樣就可以確定能通路etcd叢集的服務都能互相連接配接。【已有的服務當被使用能夠被找到并能連接配接】

   來看服務發現對應的具體場景：

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

微服務協同工作

• PaaS平台中應用多執行個體與執行個體故障重新開機透明化。PaaS平台中的應用一般都有多個執行個體，通過域名，不僅可以透明的對這多個執行個體進行通路，而且還可以做到負載均衡。但是應用的某個執行個體随時都有可能故障重新開機，這時就需要動态的配置域名解析（路由）中的資訊。通過etcd的服務發現功能就可以輕松解決這個動态配置的問題。

場景二：消息釋出與訂閱

在分布式系統中，最适用的一種元件間通信方式就是消息釋出與訂閱。即建構一個配置共享中心，資料提供者在這個配置中心釋出消息，而消息使用者則訂閱他們關心的主題，一旦主題有消息釋出，就會實時通知訂閱者。通過這種方式可以做到分布式系統配置的集中式管理與動态更新。

• 應用中用到的一些配置資訊放到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來進行監控實作起來非常簡單并且實時性強。

1. 前面幾個場景已經提到Watcher機制，當某個節點消失或有變動時，Watcher會第一時間發現并告知使用者。

2. 節點可以設定TTL key，比如每隔30s發送一次心跳使代表該機器存活的節點繼續存在，否則節點消失。

   這樣就可以第一時間檢測到各節點的健康狀态，以完成叢集的監控要求。

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

這個的經典場景是搜尋系統中建立全量索引。如果每個機器都進行一遍索引的建立，不但耗時而且建立索引的一緻性不能保證。通過在etcd的CAS機制同時建立一個節點，建立成功的機器作為Leader，進行索引計算，然後把計算結果分發到其它節點。

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

etcd實作的這些功能，ZooKeeper都能實作。那麼為什麼要用etcd而非直接使用ZooKeeper呢？

相較之下，ZooKeeper有如下缺點：

1. 複雜。ZooKeeper的部署維護複雜，管理者需要掌握一系列的知識和技能；而Paxos強一緻性算法也是素來以複雜難懂而聞名于世；另外，ZooKeeper的使用也比較複雜，需要安裝用戶端，官方隻提供了Java和C兩種語言的接口。
2. Java編寫。這裡不是對Java有偏見，而是Java本身就偏向于重型應用，它會引入大量的依賴。而運維人員則普遍希望保持強一緻、高可用的機器叢集盡可能簡單，維護起來也不易出錯。

3. 發展緩慢。Apache基金會項目特有的“Apache Way”在開源界飽受争議，其中一大原因就是由于基金會龐大的結構以及松散的管理導緻項目發展緩慢。

   而etcd作為一個後起之秀，其優點也很明顯。

4. 簡單。使用Go語言編寫部署簡單；使用HTTP作為接口使用簡單；使用Raft算法保證強一緻性讓使用者易于了解。
5. 資料持久化。etcd預設資料一更新就進行持久化。

6. 安全。etcd支援SSL用戶端安全認證。

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

資料來源：

名詞定義：CSDN社群

發展曆程：

https://www.cnblogs.com/zhaowei121/p/12049853.html

技術特點：阿裡雲官網

https://www.jianshu.com/p/372e76a27cc3