前言

成都創(chuàng)新互聯(lián)公司是網(wǎng)站建設(shè)專家,致力于互聯(lián)網(wǎng)品牌建設(shè)與網(wǎng)絡(luò)營銷，專業(yè)領(lǐng)域包括網(wǎng)站建設(shè)、成都做網(wǎng)站、電商網(wǎng)站制作開發(fā)、成都微信小程序、微信營銷、系統(tǒng)平臺開發(fā)，與其他網(wǎng)站設(shè)計及系統(tǒng)開發(fā)公司不同，我們的整合解決方案結(jié)合了恒基網(wǎng)絡(luò)品牌建設(shè)經(jīng)驗和互聯(lián)網(wǎng)整合營銷的理念，并將策略和執(zhí)行緊密結(jié)合，且不斷評估并優(yōu)化我們的方案，為客戶提供全方位的互聯(lián)網(wǎng)品牌整合方案！

隨著kubernetes項目的日益火熱，該項目中用到的etcd組件作為一個高可用強一致性的服務(wù)發(fā)現(xiàn)存儲倉庫，漸漸的被開發(fā)人員所關(guān)注。

在云計算時代，如何讓服務(wù)快速、透明的接入到計算集群中，如何讓共享配置信息快速被集群中的所有節(jié)點發(fā)現(xiàn)，如何構(gòu)建一套高可用、安全、易于部署以及快速響應(yīng)的服務(wù)集群成為了需要解決的問題。

Etcd為解決這類問題帶來便捷。

官方地址： https://coreos.com/etcd/

項目地址： https://github.com/coreos/etcd

Etcd是什么

Etcd是一個高可用的鍵值存儲系統(tǒng)，主要用于共享配置和服務(wù)發(fā)現(xiàn)，它通過Raft一致性算法處理日志復(fù)制以保證強一致性，我們可以理解它為一個高可用強一致性的服務(wù)發(fā)現(xiàn)存儲倉庫。

在kubernetes集群中，etcd主要用于配置共享和服務(wù)發(fā)現(xiàn)

Etcd主要解決的是分布式系統(tǒng)中數(shù)據(jù)一致性的問題，而分布式系統(tǒng)中的數(shù)據(jù)分為控制數(shù)據(jù)和應(yīng)用數(shù)據(jù)，etcd處理的數(shù)據(jù)類型為控制數(shù)據(jù)，對于很少量的應(yīng)用數(shù)據(jù)也可以進(jìn)行處理。

Etcd和Zookeeper的比較

Zookeeper有如下缺點

1. 1.復(fù)雜。ZooKeeper的部署維護(hù)復(fù)雜，管理員需要掌握一系列的知識和技能；而Paxos強一致性算法也是素來以復(fù)雜難懂而聞名于世（ETCD使用[Raft]協(xié)議， ZK使用ZAB，類PAXOS協(xié)議）；另外，ZooKeeper的使用也比較復(fù)雜，需要安裝客戶端，官方只提供了Java和C兩種語言的接口。

2. 2.Java編寫。這里不是對Java有偏見，而是Java本身就偏向于重型應(yīng)用，它會引入大量的依賴。而運維人員則普遍希望保持強一致、高可用的機器集群盡可能簡單，維護(hù)起來也不易出錯。

3. 3.發(fā)展緩慢。Apache基金會項目特有的“Apache Way”在開源界飽受爭議，其中一大原因就是由于基金會龐大的結(jié)構(gòu)以及松散的管理導(dǎo)致項目發(fā)展緩慢。

相較之下，Etcd

      1.簡單。使用Go語言編寫部署簡單；使用HTTP作為接口使用簡單；使用Raft算法保證強一致性讓用戶易于理解。

1. 2.數(shù)據(jù)持久化。etcd默認(rèn)數(shù)據(jù)一更新就進(jìn)行持久化。

2. 3.安全。etcd支持SSL客戶端安全認(rèn)證。

Etcd的架構(gòu)與術(shù)語

流程分析

通常一個用戶的請求發(fā)送過來，會經(jīng)過HTTP Server轉(zhuǎn)發(fā)給Store進(jìn)行具體的事務(wù)處理，如果涉及到節(jié)點的修改，則需要交給Raft模塊進(jìn)行狀態(tài)的變更，日志的記錄。

然后再同步給別的etcd節(jié)點確認(rèn)數(shù)據(jù)提交，最后進(jìn)行數(shù)據(jù)提交，再次同步。

工作原理

Etcd使用Raft協(xié)議來維護(hù)集群內(nèi)各個節(jié)點狀態(tài)的一致性。簡單說，ETCD集群是一個分布式系統(tǒng)，由多個節(jié)點相互通信構(gòu)成整體對外服務(wù)，每個節(jié)點都存儲了完整的數(shù)據(jù)，并且通過Raft協(xié)議保證每個節(jié)點維護(hù)的數(shù)據(jù)是一致的。

Etcd主要分為四個部分

1. HTTP Server： 用于處理用戶發(fā)送的API請求以及其他etcd節(jié)點的同步與心跳信息請求

2. Store:  用于處理 etcd 支持的各類功能的事務(wù)，包括數(shù)據(jù)索引、節(jié)點狀態(tài)變更、監(jiān)控與反饋、事件處理與執(zhí)行等等，是 etcd 對用戶提供的大多數(shù) API 功能的具體實現(xiàn)。

3. Raft： Raft 強一致性算法的具體實現(xiàn)，是 etcd 的核心。

4. WAL：Write Ahead Log（預(yù)寫式日志/日志先行），是 etcd 的數(shù)據(jù)存儲方式，也是一種實現(xiàn)事務(wù)日志的標(biāo)準(zhǔn)方法。etcd通過 WAL 進(jìn)行持久化存儲，所有的數(shù)據(jù)提交前都會事先記錄日志。Snapshot 是為了防止數(shù)據(jù)過多而進(jìn)行的狀態(tài)快照；Entry 表示存儲的具體日志內(nèi)容。

服務(wù)發(fā)現(xiàn)

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

1.一個強一致性、高可用的服務(wù)存儲目錄?；?Raft 算法的 etcd 天生就是這樣一個強一致性高可用的服務(wù)存儲目錄。

2.一種注冊服務(wù)和監(jiān)控服務(wù)健康狀態(tài)的機制。用戶可以在 etcd 中注冊服務(wù)，并且對注冊的服務(wù)設(shè)置key TTL，定時保持服務(wù)的心跳以達(dá)到監(jiān)控健康狀態(tài)的效果。

3.一種查找和連接服務(wù)的機制。通過在 etcd 指定的主題下注冊的服務(wù)也能在對應(yīng)的主題下查找到。為了確保連接，我們可以在每個服務(wù)機器上都部署一個 Proxy 模式的 etcd，這樣就可以確保能訪問 etcd 集群的服務(wù)都能互相連接。
例如隨著 Docker 容器的流行，多種微服務(wù)共同協(xié)作，構(gòu)成一個相對功能強大的架構(gòu)的案例越來越多。透明化的動態(tài)添加這些服務(wù)的需求也日益強烈。通過服務(wù)發(fā)現(xiàn)機制，在 etcd 中注冊某個服務(wù)名字的目錄，在該目錄下存儲可用的服務(wù)節(jié)點的 IP。在使用服務(wù)的過程中，只要從服務(wù)目錄下查找可用的服務(wù)節(jié)點去使用即可。

Etcd集群中的術(shù)語

• Raft: etcd所采用的保證分布式系統(tǒng)強一致的算法

• Node: 一個Raft狀態(tài)機實例

• Member: 一個etcd實例,管理一個Node，可以為客戶端請求提供服務(wù)

• Cluster: 多個Member構(gòu)成的可以協(xié)同工作的etcd集群

• Peer: 同一個集群中，其他Member的稱呼

• Client: 向etcd集群發(fā)送HTTP請求的客戶端

• WAL: 預(yù)寫日志，是etcd用于持久化存儲的日志格式

• Snapshot: etcd防止WAL文件過多而設(shè)置的快照，存儲etcd數(shù)據(jù)狀態(tài)

• Proxy: etcd的一種模式，可以為etcd提供反向代理服務(wù)

• Leader: Raft算法中通過競選而產(chǎn)生的處理所有數(shù)據(jù)提交的節(jié)點

• Follower: Raft算法中競選失敗的節(jié)點，作為從屬節(jié)點，為算法提供強一致性保證

• Candidate: Follower超過一定時間接收不到Leader節(jié)點的心跳的時候，會轉(zhuǎn)變?yōu)镃andidate(候選者)開始Leader競選

• Term: 某個節(jié)點稱為Leader到下一次競選開始的時間周期,稱為Term(任界，任期)

• Index: 數(shù)據(jù)項編號, Raft中通過Term和Index來定位數(shù)據(jù)

Raft算法

Raft 是一種為了管理復(fù)制日志的一致性算法。它提供了和 Paxos 算法相同的功能和性能，但是它的算法結(jié)構(gòu)和 Paxos 不同，使得 Raft 算法更加容易理解并且更容易構(gòu)建實際的系統(tǒng)。一致性算法允許一組機器像一個整體一樣工作，即使其中一些機器出現(xiàn)故障也能夠繼續(xù)工作下去。正因為如此，一致性算法在構(gòu)建可信賴的大規(guī)模軟件系統(tǒng)中扮演著重要的角色。

Raft算法分為三部分

Leader選舉、日志復(fù)制和安全性

Raft算法特性：

1.強領(lǐng)導(dǎo)者: 和其他一致性算法相比，Raft 使用一種更強的領(lǐng)導(dǎo)能力形式。比如，日志條目只從領(lǐng)導(dǎo)者發(fā)送給其他的服務(wù)器。這種方式簡化了對復(fù)制日志的管理并且使得 Raft 算法更加易于理解。

2.領(lǐng)導(dǎo)選舉： Raft 算法使用一個隨機計時器來選舉領(lǐng)導(dǎo)者。這種方式只是在任何一致性算法都必須實現(xiàn)的心跳機制上增加了一點機制。在解決沖突的時候會更加簡單快捷。

3.成員關(guān)系調(diào)整： Raft 使用一種共同一致的方法來處理集群成員變換的問題，在這種方法下，處于調(diào)整過程中的兩種不同的配置集群中大多數(shù)機器會有重疊，這就使得集群在成員變換的時候依然可以繼續(xù)工作。

Leader選舉

Raft 狀態(tài)機

Raft集群中的每個節(jié)點都處于一種基于角色的狀態(tài)機中。具體來說，Raft定義了節(jié)點的三種角色： Follower、Candidate和Leader。

1.Leader(領(lǐng)導(dǎo)者): Leader節(jié)點在集群中有且僅能有一個，它負(fù)責(zé)向所有的Follower節(jié)點同步日志數(shù)據(jù)

2.Follower(跟隨者): Follower節(jié)點從Leader節(jié)點獲取日志，提供數(shù)據(jù)查詢功能，并將所有修改請求轉(zhuǎn)發(fā)給Leader節(jié)點

3.Candidate(候選者): 當(dāng)集群中的Leader節(jié)點不存在或者失聯(lián)之后，其他Follower節(jié)點轉(zhuǎn)換為Candidate，然后開始新的Leader節(jié)點選舉

這三種角色狀態(tài)之間的轉(zhuǎn)換，如下圖：

 一個 Raft 集群包含若干個服務(wù)器節(jié)點；通常是 5 個，這允許整個系統(tǒng)容忍 2 個節(jié)點的失效。在任何時刻，每一個服務(wù)器節(jié)點都處于這三個狀態(tài)之一：領(lǐng)導(dǎo)人、跟隨者或者候選人。在通常情況下，系統(tǒng)中只有一個領(lǐng)導(dǎo)人并且其他的節(jié)點全部都是跟隨者。跟隨者都是被動的：他們不會發(fā)送任何請求，只是簡單的響應(yīng)來自領(lǐng)導(dǎo)者或者候選人的請求。領(lǐng)導(dǎo)人處理所有的客戶端請求（如果一個客戶端和跟隨者聯(lián)系，那么跟隨者會把請求重定向給領(lǐng)導(dǎo)人）

在節(jié)點初始啟動的時候，所有節(jié)點的Raft狀態(tài)機都會處于Follower狀態(tài)。當(dāng)Follower在一定的時間周期內(nèi)沒有收到來自Leader節(jié)點的心跳數(shù)據(jù)包的時候，節(jié)點會將自己的狀態(tài)切換為Candidate，并向集群中其他Follower節(jié)點發(fā)送投票請求，F(xiàn)ollower都會將自己的票投給收到的第一個投票請求節(jié)點。當(dāng)Candidate收到來自集群中超過半數(shù)節(jié)點的投票后，會成為新的Leader節(jié)點。

Leader節(jié)點將接受并保存用戶發(fā)送的數(shù)據(jù)，并向其他的Follower節(jié)點同步日志。

Follower只響應(yīng)來自其他服務(wù)器的請求。如果Follower接收不到消息，那么他就會變成候選人并發(fā)起一次選舉。獲得集群中大多數(shù)選票的候選人將成為Leader。在一個任期(Term)內(nèi),領(lǐng)導(dǎo)人一直都會是領(lǐng)導(dǎo)人直到自己宕機了。

Leader節(jié)點依靠定時向所有Follower發(fā)送心跳數(shù)據(jù)來保持地位。當(dāng)急群眾的Leader節(jié)點出現(xiàn)故障的時候，F(xiàn)ollower會重新選舉新的節(jié)點，保證整個集群正常運行。 

每次成功的選舉，新的Leader的Term（任期）值都會比之前的Leader增加1。當(dāng)集群中由于網(wǎng)絡(luò)或者其他原因出現(xiàn)分裂后又重新合并的時候，集群中可能會出現(xiàn)多于一個的Leader節(jié)點，此時，Term值更高的節(jié)點才會成為真正的Leader。

Raft算法中的Term（任期）

關(guān)于Term，如下圖：

Raft會把時間分割成任意長度的任期。并且任期用連續(xù)的整數(shù)來標(biāo)記。每一段任期都是從一次選舉開始，一個或者多個候選人嘗試成為領(lǐng)導(dǎo)者。如果一個候選人贏得選舉，然后他就會在接下來的任期中充當(dāng)Leader的職責(zé)。在某些情況下，一次選舉會造成選票瓜分，這樣，這一個任期將沒有Leader。如果沒有Leader，那么新的一輪選舉就馬上開始，也就是新的任期就會開始。Raft保證了在一個Term任期內(nèi)，有且只有一個Leader。

日志復(fù)制

所謂日志復(fù)制，是指主節(jié)點將每次操作形成日志條目，并持久化到本地磁盤，然后通過網(wǎng)絡(luò)IO發(fā)送給其他節(jié)點。

一旦一個領(lǐng)導(dǎo)人被選舉出來，他就開始為客戶端提供服務(wù)。客戶端的每一個請求都包含一條被復(fù)制狀態(tài)機執(zhí)行的指令。領(lǐng)導(dǎo)人把這條指令作為一條新的日志條目附加到日志中去，然后并行的發(fā)起附加條目 RPCs 給其他的服務(wù)器，讓他們復(fù)制這條日志條目。

Raft 算法保證所有已提交的日志條目都是持久化的并且最終會被所有可用的狀態(tài)機執(zhí)行。當(dāng)主節(jié)點收到包括自己在內(nèi)超過半數(shù)節(jié)點成功返回，那么認(rèn)為該日志是可提交的(committed），并將日志輸入到狀態(tài)機，將結(jié)果返回給客戶端。

在正常的操作中，領(lǐng)導(dǎo)人和跟隨者的日志保持一致性，所以附加日志 RPC 的一致性檢查從來不會失敗。然而，領(lǐng)導(dǎo)人崩潰的情況會使得日志處于不一致的狀態(tài)（老的領(lǐng)導(dǎo)人可能還沒有完全復(fù)制所有的日志條目）。這種不一致問題會在一系列的領(lǐng)導(dǎo)人和跟隨者崩潰的情況下加劇。跟隨者的日志可能和新的領(lǐng)導(dǎo)人不同的方式。跟隨者可能會丟失一些在新的領(lǐng)導(dǎo)人中有的日志條目，他也可能擁有一些領(lǐng)導(dǎo)人沒有的日志條目，或者兩者都發(fā)生。丟失或者多出日志條目可能會持續(xù)多個任期。這就引出了另一個部分，就是安全性

安全性

截止此刻，選主以及日志復(fù)制并不能保證節(jié)點間數(shù)據(jù)一致。試想，當(dāng)一個某個節(jié)點掛掉了，一段時間后再次重啟，并當(dāng)選為主節(jié)點。而在其掛掉這段時間內(nèi)，集群若有超過半數(shù)節(jié)點存活，集群會正常工作，那么會有日志提交。這些提交的日志無法傳遞給掛掉的節(jié)點。當(dāng)掛掉的節(jié)點再次當(dāng)選主節(jié)點，它將缺失部分已提交的日志。在這樣場景下，按Raft協(xié)議，它將自己日志復(fù)制給其他節(jié)點，會將集群已經(jīng)提交的日志給覆蓋掉。這顯然是錯誤的

其他協(xié)議解決這個問題的辦法是，新當(dāng)選的主節(jié)點會詢問其他節(jié)點，和自己數(shù)據(jù)對比，確定出集群已提交數(shù)據(jù)，然后將缺失的數(shù)據(jù)同步過來。這個方案有明顯缺陷，增加了集群恢復(fù)服務(wù)的時間（集群在選舉階段不可服務(wù)），并且增加了協(xié)議的復(fù)雜度。Raft解決的辦法是，在選主邏輯中，對能夠成為主的節(jié)點加以限制，確保選出的節(jié)點已定包含了集群已經(jīng)提交的所有日志。如果新選出的主節(jié)點已經(jīng)包含了集群所有提交的日志，那就不需要從和其他節(jié)點比對數(shù)據(jù)了。簡化了流程，縮短了集群恢復(fù)服務(wù)的時間。

這里存在一個問題，加以這樣限制之后，還能否選出主呢？答案是：只要仍然有超過半數(shù)節(jié)點存活，這樣的主一定能夠選出。因為已經(jīng)提交的日志必然被集群中超過半數(shù)節(jié)點持久化，顯然前一個主節(jié)點提交的最后一條日志也被集群中大部分節(jié)點持久化。當(dāng)主節(jié)點掛掉后，集群中仍有大部分節(jié)點存活，那這存活的節(jié)點中一定存在一個節(jié)點包含了已經(jīng)提交的日志了。

Etcd的代理節(jié)點（proxy）

Etcd針對Raft的角色模型進(jìn)行了擴(kuò)展，增加了Proxy角色。proxy模式的本職就是啟一個HTTP代理服務(wù)器，把客戶發(fā)到這個服務(wù)器的請求轉(zhuǎn)發(fā)給別的 etcd 節(jié)點。

作為Proxy角色的節(jié)點不會參與Leader的選舉，只是將所有接收到的用戶查詢和修改請求轉(zhuǎn)發(fā)到任意一個Follower或者Leader節(jié)點上。

Proxy節(jié)點可以在啟動Etcd的時候通過"--proxy on"參數(shù)指定。在使用了"節(jié)點自發(fā)現(xiàn)"服務(wù)的集群中，可以設(shè)置一個固定的"參選節(jié)點數(shù)目"，超過這個數(shù)目的成員自動轉(zhuǎn)換為Proxy節(jié)點。

一旦節(jié)點成為Proxy之后，便不再參與所有Leader選舉和Raft狀態(tài)變化。除非將這個節(jié)點重啟并指定為成員的Follower節(jié)點

etcd 作為一個反向代理把客戶的請求轉(zhuǎn)發(fā)給可用的 etcd 集群。這樣，你就可以在每一臺機器都部署一個 Proxy 模式的 etcd 作為本地服務(wù)，如果這些 etcd Proxy 都能正常運行，那么你的服務(wù)發(fā)現(xiàn)必然是穩(wěn)定可靠的。

完整的Etcd角色狀態(tài)轉(zhuǎn)換過程如下圖：

kubernetes項目中，Etcd用來做什么，為什么選擇它

etcd在kubernetes集群是用來存放數(shù)據(jù)并通知變動的。

Kubernetes中沒有用到數(shù)據(jù)庫，它把關(guān)鍵數(shù)據(jù)都存放在etcd中，這使kubernetes的整體結(jié)構(gòu)變得非常簡單。

在kubernetes中，數(shù)據(jù)是隨時發(fā)生變化的，比如說用戶提交了新任務(wù)、增加了新的Node、Node宕機了、容器死掉了等等，都會觸發(fā)狀態(tài)數(shù)據(jù)的變更。狀態(tài)數(shù)據(jù)變更之后呢，Master上的kube-scheduler和kube-controller-manager，就會重新安排工作，它們的工作安排結(jié)果也是數(shù)據(jù)。這些變化，都需要及時地通知給每一個組件。etcd有一個特別好用的特性，可以調(diào)用它的api監(jiān)聽其中的數(shù)據(jù)，一旦數(shù)據(jù)發(fā)生變化了，就會收到通知。有了這個特性之后，kubernetes中的每個組件只需要監(jiān)聽etcd中數(shù)據(jù)，就可以知道自己應(yīng)該做什么。kube-scheduler和kube-controller-manager呢，也只需要把最新的工作安排寫入到etcd中就可以了，不用自己費心去逐個通知了

試想一下，如果沒有etcd，那么要怎樣做？這里的本質(zhì)是：數(shù)據(jù)的傳遞有兩種方式，一種是消息的方式，比如說NodeA有了新的任務(wù)，Master直接給NodeA發(fā)一個消息，中間不經(jīng)過任何人；一種是輪詢的方式，大家都把數(shù)據(jù)寫到同一個地方，每個人自覺地盯著看，及時發(fā)現(xiàn)變化。前者演化出rabbitmq這樣的消息隊列系統(tǒng)，后者演化出一些有訂閱功能的分布式系統(tǒng)。

第一種方式的問題是，所有要通信的組件之間都要建立長連接，并且要處理各種異常情況，比例如連接斷開、數(shù)據(jù)發(fā)送失敗等。不過有了消息隊列(message queue)這樣的中間件之后，問題就簡單多了，組件都和mq建立連接即可，將各種異常情況都在mq中處理。

那么為什么kubernetes沒有選用mq而是選用etcd呢？mq和etcd是本質(zhì)上完全不同的系統(tǒng)，mq的作用消息傳遞，不儲存數(shù)據(jù)（消息積壓不算儲存，因為沒有查詢的功能），etcd是個分布式存儲（它的設(shè)計目標(biāo)是分布式鎖，順帶有了存儲功能），是一個帶有訂閱功能的key-value存儲。如果使用mq，那么還需要引入數(shù)據(jù)庫，在數(shù)據(jù)庫中存放狀態(tài)數(shù)據(jù)。

選擇etcd還有一個好處，etcd使用raft協(xié)議實現(xiàn)一致性，它是一個分布式鎖，可以用來做選舉。如果在kubernetes中部署了多個kube-schdeuler，那么同一時刻只能有一個kube-scheduler在工作，否則各自安排各自的工作，就亂套了。怎樣保證只有一個kube-schduler在工作呢？那就是前文說到的通過etcd選舉出一個leader。