[[424540]]

etcd選型對(duì)比

前言

對(duì)比 Consul, ZooKeeper。選型etcd有那些好處呢？

基本架構(gòu)和原理

etcd

ETCD是一個(gè)分布式、可靠的key-value存儲(chǔ)的分布式系統(tǒng)，用于存儲(chǔ)分布式系統(tǒng)中的關(guān)鍵數(shù)據(jù)；當(dāng)然，它不僅僅用于存儲(chǔ)，還提供配置共享及服務(wù)發(fā)現(xiàn)；基于Go語(yǔ)言實(shí)現(xiàn) 。

etcd的特點(diǎn)

• 完全復(fù)制：集群中的每個(gè)節(jié)點(diǎn)都可以使用完整的存檔

• 高可用性：Etcd可用于避免硬件的單點(diǎn)故障或網(wǎng)絡(luò)問(wèn)題

• 一致性：每次讀取都會(huì)返回跨多主機(jī)的最新寫(xiě)入

• 簡(jiǎn)單：包括一個(gè)定義良好、面向用戶(hù)的API（gRPC）

• 安全：實(shí)現(xiàn)了帶有可選的客戶(hù)端證書(shū)身份驗(yàn)證的自動(dòng)化TLS

• 可靠：使用Raft算法實(shí)現(xiàn)了強(qiáng)一致、高可用的服務(wù)存儲(chǔ)目錄

etcd 是基于 raft 算法實(shí)現(xiàn)的，具體的實(shí)現(xiàn)可參見(jiàn) etcd實(shí)現(xiàn)raft源碼解讀

Consul

先放一張 consul 的架構(gòu)圖

consul 使用的是 Gossip 協(xié)議

Gossip 中文名稱(chēng)叫流言協(xié)議，它是一種消息傳播協(xié)議。它的核心思想其實(shí)源自我們生活中的八卦、閑聊。我們?cè)谌粘Ｉ钪兴吹降膭疟⑵鋵?shí)源于兩類(lèi)，一類(lèi)是權(quán)威機(jī)構(gòu)如國(guó)家新聞媒體發(fā)布的消息，另一類(lèi)則是大家通過(guò)微信等社交聊天軟件相互八卦，一傳十，十傳百的結(jié)果。

Gossip 協(xié)議的基本工作原理與我們八卦類(lèi)似，在 Gossip 協(xié)議中，如下圖所示，各個(gè)節(jié)點(diǎn)會(huì)周期性地選擇一定數(shù)量節(jié)點(diǎn)，然后將消息同步給這些節(jié)點(diǎn)。收到消息后的節(jié)點(diǎn)同樣做出類(lèi)似的動(dòng)作，隨機(jī)的選擇節(jié)點(diǎn)，繼續(xù)擴(kuò)散給其他節(jié)點(diǎn)。

Gossip 協(xié)議的基本工作原理與我們八卦類(lèi)似，在 Gossip 協(xié)議中，如下圖所示，各個(gè)節(jié)點(diǎn)會(huì)周期性地選擇一定數(shù)量節(jié)點(diǎn)，然后將消息同步給這些節(jié)點(diǎn)。收到消息后的節(jié)點(diǎn)同樣做出類(lèi)似的動(dòng)作，隨機(jī)的選擇節(jié)點(diǎn)，繼續(xù)擴(kuò)散給其他節(jié)點(diǎn)。

最終經(jīng)過(guò)一定次數(shù)的擴(kuò)散、傳播，整個(gè)集群的各個(gè)節(jié)點(diǎn)都能感知到此消息，各個(gè)節(jié)點(diǎn)的數(shù)據(jù)趨于一致。Gossip 協(xié)議被廣泛應(yīng)用在多個(gè)知名項(xiàng)目中，比如 Redis Cluster 集群版，Apache Cassandra，AWS Dynamo。

Consul 天然支持多數(shù)據(jù)中心，但是多數(shù)據(jù)中心內(nèi)的服務(wù)數(shù)據(jù)并不會(huì)跨數(shù)據(jù)中心同步，各個(gè)數(shù)據(jù)中心的 Server 集群是獨(dú)立的,Consul 提供了 Prepared Query 功能，它支持根據(jù)一定的策略返回多數(shù)據(jù)中心下的最佳的服務(wù)實(shí)例地址，使你的服務(wù)具備跨數(shù)據(jù)中心容災(zāi)。

這里來(lái)看下 Prepared Query 查詢(xún)的過(guò)程：

比如當(dāng)你的 API 網(wǎng)關(guān)收到用戶(hù)請(qǐng)求查詢(xún) A 服務(wù)，API 網(wǎng)關(guān)服務(wù)優(yōu)先從緩存中查找 A 服務(wù)對(duì)應(yīng)的最佳實(shí)例。若無(wú)緩存則向 Consul 發(fā)起一個(gè) Prepared Query 請(qǐng)求查詢(xún) A 服務(wù)實(shí)例，Consul 收到請(qǐng)求后，優(yōu)先返回本數(shù)據(jù)中心下的服務(wù)實(shí)例。如果本數(shù)據(jù)中心沒(méi)有或異常則根據(jù)數(shù)據(jù)中心間 RTT 由近到遠(yuǎn)查詢(xún)其它數(shù)據(jù)中心數(shù)據(jù)，最終網(wǎng)關(guān)可將用戶(hù)請(qǐng)求轉(zhuǎn)發(fā)給最佳的數(shù)據(jù)中心下的實(shí)例地址。

Consul 支持以下三種模式的讀請(qǐng)求：

• 默認(rèn)（default）。默認(rèn)是此模式，絕大部分場(chǎng)景下它能保證數(shù)據(jù)的強(qiáng)一致性。但在老的 Leader 出現(xiàn)網(wǎng)絡(luò)分區(qū)被隔離、新的 Leader 被選舉出來(lái)的一個(gè)極小時(shí)間窗口內(nèi)，可能會(huì)導(dǎo)致 stale read。這是因?yàn)?Consul 為了提高讀性能，使用的是基于 Lease 機(jī)制來(lái)維持 Leader 身份，避免了與其他節(jié)點(diǎn)進(jìn)行交互確認(rèn)的開(kāi)銷(xiāo)。

• 強(qiáng)一致性（consistent）。強(qiáng)一致性讀與 etcd 默認(rèn)線性讀模式一樣，每次請(qǐng)求需要集群多數(shù)節(jié)點(diǎn)確認(rèn) Leader 身份，因此相比 default 模式讀，性能會(huì)有所下降。

• 弱一致性（stale)。任何節(jié)點(diǎn)都可以讀，無(wú)論它是否 Leader?？赡茏x取到陳舊的數(shù)據(jù)，類(lèi)似 etcd 的串行讀。這種讀模式不要求集群有 Leader，因此當(dāng)集群不可用時(shí)，只要有節(jié)點(diǎn)存活，它依然可以響應(yīng)讀請(qǐng)求。

ZooKeeper

ZooKeeper 是一個(gè)典型的分布式數(shù)據(jù)一致性解決方案，分布式應(yīng)用程序可以基于 ZooKeeper 實(shí)現(xiàn)諸如數(shù)據(jù)發(fā)布/訂閱、負(fù)載均衡、命名服務(wù)、分布式協(xié)調(diào)/通知、集群管理、Master 選舉、分布式鎖和分布式隊(duì)列等功能。

ZooKeeper 的有點(diǎn)：

• 順序一致性： 從同一客戶(hù)端發(fā)起的事務(wù)請(qǐng)求，最終將會(huì)嚴(yán)格地按照順序被應(yīng)用到 ZooKeeper 中去。

• 原子性： 所有事務(wù)請(qǐng)求的處理結(jié)果在整個(gè)集群中所有機(jī)器上的應(yīng)用情況是一致的，也就是說(shuō)，要么整個(gè)集群中所有的機(jī)器都成功應(yīng)用了某一個(gè)事務(wù)，要么都沒(méi)有應(yīng)用。

• 單一系統(tǒng)映像 ： 無(wú)論客戶(hù)端連到哪一個(gè) ZooKeeper 服務(wù)器上，其看到的服務(wù)端數(shù)據(jù)模型都是一致的。

• 可靠性： 一旦一次更改請(qǐng)求被應(yīng)用，更改的結(jié)果就會(huì)被持久化，直到被下一次更改覆蓋。

再來(lái)看下 ZooKeeper 的架構(gòu)圖，圖片摘自 etcd實(shí)戰(zhàn)課

ZooKeeper 集群中的所有機(jī)器通過(guò)一個(gè) Leader 選舉過(guò)程來(lái)選定一臺(tái)稱(chēng)為 “Leader” 的機(jī)器，Leader 既可以為客戶(hù)端提供寫(xiě)服務(wù)又能提供讀服務(wù)。

除了 Leader 外，F(xiàn)ollower 和 Observer 都只能提供讀服務(wù)。Follower 和 Observer 唯一的區(qū)別在于 Observer 機(jī)器不參與 Leader 的選舉過(guò)程，也不參與寫(xiě)操作的“過(guò)半寫(xiě)成功”策略，因此 Observer 機(jī)器可以在不影響寫(xiě)性能的情況下提升集群的讀性能。

ZooKeeper 使用的是 Zab 協(xié)議

ZAB（ZooKeeper Atomic Broadcast 原子廣播） 協(xié)議是為分布式協(xié)調(diào)服務(wù) ZooKeeper 專(zhuān)門(mén)設(shè)計(jì)的一種支持崩潰恢復(fù)的原子廣播協(xié)議。 在 ZooKeeper 中，主要依賴(lài) ZAB 協(xié)議來(lái)實(shí)現(xiàn)分布式數(shù)據(jù)一致性，基于該協(xié)議，ZooKeeper 實(shí)現(xiàn)了一種主備模式的系統(tǒng)架構(gòu)來(lái)保持集群中各個(gè)副本之間的數(shù)據(jù)一致性。

Zab 協(xié)議可以分為以下階段：

• Phase 0，Leader 選舉（Leader Election)。一個(gè)節(jié)點(diǎn)只要求獲得半數(shù)以上投票，就可以當(dāng)選為準(zhǔn) Leader；

• Phase 1，發(fā)現(xiàn)（Discovery）。準(zhǔn) Leader 收集其他節(jié)點(diǎn)的數(shù)據(jù)信息，并將最新的數(shù)據(jù)復(fù)制到自身；

• Phase 2，同步（Synchronization）。準(zhǔn) Leader 將自身最新數(shù)據(jù)復(fù)制給其他落后的節(jié)點(diǎn)，并告知其他節(jié)點(diǎn)自己正式當(dāng)選為 Leader；

• Phase 3，廣播（Broadcast）。Leader 正式對(duì)外服務(wù)，處理客戶(hù)端寫(xiě)請(qǐng)求，對(duì)消息進(jìn)行廣播。當(dāng)收到一個(gè)寫(xiě)請(qǐng)求后，它會(huì)生成 Proposal 廣播給各個(gè) Follower 節(jié)點(diǎn)，一半以上 Follower 節(jié)點(diǎn)應(yīng)答之后，Leader 再發(fā)送 Commit 命令給各個(gè) Follower，告知它們提交相關(guān)提案；

關(guān)于 ZAB 中的兩種模式：崩潰恢復(fù)和消息廣播

崩潰恢復(fù)

當(dāng)整個(gè)服務(wù)框架在啟動(dòng)過(guò)程中，或是當(dāng) Leader 服務(wù)器出現(xiàn)網(wǎng)絡(luò)中斷、崩潰退出與重啟等異常情況時(shí)，ZAB 協(xié)議就會(huì)進(jìn)人恢復(fù)模式并選舉產(chǎn)生新的Leader服務(wù)器。

當(dāng)選出 leader ,并且完成了上面 Phase 2 的同步過(guò)程，就退出崩潰恢復(fù)模式

消息廣播

當(dāng)準(zhǔn) Leader 將自身最新數(shù)據(jù)復(fù)制給其他落后的節(jié)點(diǎn)，并告知其他節(jié)點(diǎn)自己正式當(dāng)選為 Leader。這時(shí)候就可以進(jìn)入廣播模式，當(dāng)有客戶(hù)端進(jìn)行數(shù)據(jù)寫(xiě)入操作的時(shí)候，就可以通過(guò)廣播模式通知所有的 follower 了。

當(dāng)集群中已經(jīng)有過(guò)半的Follower服務(wù)器完成了和Leader服務(wù)器的狀態(tài)同步，那么整個(gè)服務(wù)框架就可以進(jìn)人消息廣播模式了。

選型對(duì)比

• 1、并發(fā)原語(yǔ)：etcd 和 ZooKeeper 并未提供原生的分布式鎖、Leader 選舉支持，只提供了核心的基本數(shù)據(jù)讀寫(xiě)、并發(fā)控制 API，由應(yīng)用上層去封裝，consul 就簡(jiǎn)單多了，提供了原生的支持，通過(guò)簡(jiǎn)單點(diǎn)命令就能使用；

• 2、服務(wù)發(fā)現(xiàn)：etcd 和 ZooKeeper 并未提供原生的服務(wù)發(fā)現(xiàn)支持，Consul 在服務(wù)發(fā)現(xiàn)方面做了很多解放用戶(hù)雙手的工作，提供了服務(wù)發(fā)現(xiàn)的框架，幫助你的業(yè)務(wù)快速接入，并提供了 HTTP 和 DNS 兩種獲取服務(wù)方式；

• 3、健康檢查：consul 的健康檢查機(jī)制，是一種基于 client、Gossip 協(xié)議、分布式的健康檢查機(jī)制，具備低延時(shí)、可擴(kuò)展的特點(diǎn)。業(yè)務(wù)可通過(guò) Consul 的健康檢查機(jī)制，實(shí)現(xiàn) HTTP 接口返回碼、內(nèi)存乃至磁盤(pán)空間的檢測(cè)，相比 etcd、ZooKeeper 它們提供的健康檢查機(jī)制和能力就非常有限了；

etcd 提供了 Lease 機(jī)制來(lái)實(shí)現(xiàn)活性檢測(cè)。它是一種中心化的健康檢查，依賴(lài)用戶(hù)不斷地發(fā)送心跳續(xù)租、更新 TTL

ZooKeeper 使用的是一種名為臨時(shí)節(jié)點(diǎn)的狀態(tài)來(lái)實(shí)現(xiàn)健康檢查。當(dāng) client 與 ZooKeeper 節(jié)點(diǎn)連接斷掉時(shí)，ZooKeeper 就會(huì)刪除此臨時(shí)節(jié)點(diǎn)的 key-value 數(shù)據(jù)。它比基于心跳機(jī)制更復(fù)雜，也給 client 帶去了更多的復(fù)雜性，所有 client 必須維持與 ZooKeeper server 的活躍連接并保持存活。

• 4、watch 特性：相比于 etcd , Consul 存儲(chǔ)引擎是基于Radix Tree實(shí)現(xiàn)的，因此它不支持范圍查詢(xún)和監(jiān)聽(tīng)，只支持前綴查詢(xún)和監(jiān)聽(tīng)，而 etcd 都支持, ZooKeeper 的 Watch 特性有更多的局限性，它是個(gè)一次性觸發(fā)器;

• 5、線性讀。etcd 和 Consul 都支持線性讀，而 ZooKeeper 并不具備。

• 6、權(quán)限機(jī)制比較。etcd 實(shí)現(xiàn)了 RBAC 的權(quán)限校驗(yàn)，而 ZooKeeper 和 Consul 實(shí)現(xiàn)的 ACL。

• 7、事務(wù)比較。etcd 和 Consul 都提供了簡(jiǎn)易的事務(wù)能力，支持對(duì)字段進(jìn)行比較，而 ZooKeeper 只提供了版本號(hào)檢查能力，功能較弱。

• 8、多數(shù)據(jù)中心。在多數(shù)據(jù)中心支持上，只有 Consul 是天然支持的，雖然它本身不支持?jǐn)?shù)據(jù)自動(dòng)跨數(shù)據(jù)中心同步，但是它提供的服務(wù)發(fā)現(xiàn)機(jī)制、Prepared Query功能，賦予了業(yè)務(wù)在一個(gè)可用區(qū)后端實(shí)例故障時(shí)，可將請(qǐng)求轉(zhuǎn)發(fā)到最近的數(shù)據(jù)中心實(shí)例。而 etcd 和 ZooKeeper 并不支持。

總結(jié)

總的看下來(lái)，consul 提供了原生的分布式鎖、健康檢查、服務(wù)發(fā)現(xiàn)機(jī)制支持，讓業(yè)務(wù)可以更省心，同時(shí)也對(duì)多數(shù)據(jù)中心進(jìn)行了支持；

當(dāng)然 etcd 和 ZooKeeper 也都有相應(yīng)的庫(kù)，也能很好的進(jìn)行支持，但是這兩者不支持多數(shù)據(jù)中心；

ZooKeeper 在 Java 業(yè)務(wù)中選型使用的較多，etcd 因?yàn)槭?go 語(yǔ)言開(kāi)發(fā)的，所以如果本身就是 go 的技術(shù)棧，使用這個(gè)也是個(gè)不錯(cuò)的選擇，Consul 在國(guó)外應(yīng)用比較多，中文文檔及實(shí)踐案例相比 etcd 較少；

參考

【服務(wù)發(fā)現(xiàn)框架選型: Consul、Zookeeper還是etcd ？】https://www.cnblogs.com/sunsky303/p/11127324.html

【23 | 選型：etcd/ZooKeeper/Consul等我們?cè)撊绾芜x擇？】https://time.geekbang.org/column/article/351898

【服務(wù)發(fā)現(xiàn)比較】https://developer.aliyun.com/article/759139

【ZooKeeper講解】https://juejin.cn/post/6844903677367418893