一、Consul 是什么？

Consul有多個組件，但總體而言，它是基礎(chǔ)架構(gòu)中的一款服務(wù)發(fā)現(xiàn)和配置的工具。 它提供了幾個關(guān)鍵功能：

• 服務(wù)發(fā)現(xiàn)：Consul client 可以提供服務(wù)，例如api或mysql，也可以使用Consul client來發(fā)現(xiàn)指定服務(wù)的提供者。 使用DNS或HTTP，應(yīng)用程序可以輕松找到他們所依賴的服務(wù)。
• 健康檢查：Consul client 可以提供任何數(shù)量的健康檢查，或者與給定的服務(wù)（“Web服務(wù)器是否返回200 OK”），或與本地節(jié)點(diǎn)（“內(nèi)存利用率是否低于90％”）相關(guān)聯(lián)。 可以使用此信息來監(jiān)控集群運(yùn)行狀況，服務(wù)發(fā)現(xiàn)組件使用此信息將流量從有問題的主機(jī)中移除出去。
• KV Store：應(yīng)用程序可以使用Consul的分層鍵/值存儲，包括動態(tài)配置，功能標(biāo)記，協(xié)調(diào)，leader選舉等等。 簡單的HTTP API使其易于使用。
• 多數(shù)據(jù)中心：Consul支持多個數(shù)據(jù)中心。 這意味著Consul的用戶不必?fù)?dān)心構(gòu)建額外的抽象層以擴(kuò)展到多個區(qū)域。
  　　Consul旨在對DevOps社區(qū)和應(yīng)用程序開發(fā)人員友好，使其成為現(xiàn)代化，彈性基礎(chǔ)架構(gòu)的完美選擇。

二、Consul 基本架構(gòu)

Consul 是一個分布式，高可用的系統(tǒng)。 為了快速了解Consul的工作原理，本節(jié)只介紹基礎(chǔ)知識，不會介紹詳細(xì)的細(xì)節(jié)。
　　向Consul提供服務(wù)的每個節(jié)點(diǎn)都運(yùn)行一個Consul代理。 發(fā)現(xiàn)其他服務(wù)或獲取/設(shè)置鍵/值數(shù)據(jù)不需要運(yùn)行代理。 代理負(fù)責(zé)健康檢查節(jié)點(diǎn)上的服務(wù)以及節(jié)點(diǎn)本身。
　　代理與一個或多個Consul服務(wù)器通信。Consul 服務(wù)器是數(shù)據(jù)存儲和復(fù)制的地方。 服務(wù)器自己選出一個 leader。 雖然Consul可以在一臺服務(wù)器上運(yùn)行，但推薦使用3到5臺來避免數(shù)據(jù)丟失的情況。 每個數(shù)據(jù)中心都建議使用一組Consul服務(wù)器。
　　需要發(fā)現(xiàn)其他服務(wù)或節(jié)點(diǎn)的基礎(chǔ)架構(gòu)組件可以查詢?nèi)魏蜟onsul服務(wù)器或任何Consul代理。 代理自動將查詢轉(zhuǎn)發(fā)到服務(wù)器。
　　每個數(shù)據(jù)中心都運(yùn)行Consul服務(wù)器集群。 當(dāng)跨數(shù)據(jù)中心服務(wù)發(fā)現(xiàn)或配置請求時(shí)，本地Consul服務(wù)器將請求轉(zhuǎn)發(fā)到遠(yuǎn)程數(shù)據(jù)中心并返回結(jié)果。

三、Consul VS. 其它軟件

Consul解決的問題是多種多樣的，但是每個單獨(dú)的特征已經(jīng)被許多不同的系統(tǒng)解決了。 盡管沒有單一的系統(tǒng)提供Consul的所有功能，但還有其他的選擇可以解決這些問題。

1、Consul vs. ZooKeeper, doozerd, etcd

ZooKeeper，doozerd和etcd在他們的架構(gòu)中都是相似的。 所有這三個服務(wù)器節(jié)點(diǎn)都需要一定數(shù)量的節(jié)點(diǎn)才能運(yùn)行（通常是簡單多數(shù)）。 它們是高度一致的，并且公開了可以通過應(yīng)用程序中的客戶端庫來構(gòu)建復(fù)雜的分布式系統(tǒng)的各種基元。
　　Consul 還使用單個數(shù)據(jù)中心內(nèi)的服務(wù)器節(jié)點(diǎn)。 在每個數(shù)據(jù)中心，Consul服務(wù)器都需要一個仲裁來操作并提供強(qiáng)大的一致性。 不過，Consul擁有對多個數(shù)據(jù)中心的本地支持，以及連接服務(wù)器節(jié)點(diǎn)和客戶端的功能豐富的系統(tǒng)。
　　所有這些系統(tǒng)在提供鍵/值存儲時(shí)都具有大致相同的語義：讀取具有強(qiáng)烈的一致性，為了在網(wǎng)絡(luò)分區(qū)的情況下保持一致性，犧牲了可用性。 但是，當(dāng)這些系統(tǒng)用于高級案例時(shí)，這些差異會變得更加明顯。
　　這些系統(tǒng)提供的語義對于構(gòu)建服務(wù)發(fā)現(xiàn)系統(tǒng)是有吸引力的，但重要的是要強(qiáng)調(diào)必須構(gòu)建這些功能。 ZooKeeper等軟件僅提供原始K / V存儲，并要求應(yīng)用程序開發(fā)人員構(gòu)建自己的系統(tǒng)以提供服務(wù)發(fā)現(xiàn)。 相比之下，Consul為服務(wù)發(fā)現(xiàn)提供了一個可用的框架，并且消除了猜測工作和開發(fā)工作。 客戶端只需注冊服務(wù)，然后使用DNS或HTTP接口執(zhí)行發(fā)現(xiàn)。 其他系統(tǒng)需要一個自己定制的解決方案。
　　一個引人注目的服務(wù)發(fā)現(xiàn)框架必須包含健康檢查和失敗的可能性。 知道如果節(jié)點(diǎn)A失敗或服務(wù)崩潰，則節(jié)點(diǎn)A提供Foo服務(wù)是沒有用的。 原生系統(tǒng)使用心跳檢測，定期更新和TTL。 這些方案需要與節(jié)點(diǎn)數(shù)量成線性關(guān)系，并將需求放在固定數(shù)量的服務(wù)器上。 此外，故障檢測窗口至少與TTL一樣長。
　　ZooKeeper提供臨時(shí)節(jié)點(diǎn)，這些節(jié)點(diǎn)是客戶端斷開連接時(shí)刪除的K / V條目。 這些比心跳系統(tǒng)更復(fù)雜，但仍然存在固有的可擴(kuò)展性問題，并增加了客戶端的復(fù)雜性。 所有客戶端必須保持與ZooKeeper服務(wù)器的活動連接并執(zhí)行保持活動。 另外，這需要“厚厚的客戶端”，這些客戶端很難編寫，經(jīng)常導(dǎo)致調(diào)試難題。
　　Consul 使用非常不同的體系結(jié)構(gòu)進(jìn)行健康檢查。 Consul客戶端不是只有服務(wù)器節(jié)點(diǎn)，而是在集群中的每個節(jié)點(diǎn)上運(yùn)行。 這些客戶端是gossip pool的一部分，可以提供多種功能，包括分布式健康檢查。 gossip協(xié)議實(shí)現(xiàn)了一個高效的故障檢測器，可以擴(kuò)展到任何規(guī)模的集群，而不用將任務(wù)集中在任何選定的服務(wù)器組上。 客戶端還可以在本地運(yùn)行更豐富的運(yùn)行狀況檢查，而ZooKeeper臨時(shí)節(jié)點(diǎn)對活躍性進(jìn)行非常原始的檢查。 通過Consul，客戶端可以檢查Web服務(wù)器是否返回200的狀態(tài)碼，內(nèi)存使用情況，有足夠的磁盤空間等。和ZooKeeper一樣，Consul客戶端公開一個簡單的HTTP接口，避免將系統(tǒng)的復(fù)雜性暴露給客戶端。
　　Consul為服務(wù)發(fā)現(xiàn)，運(yùn)行狀況檢查，K / V存儲和多個數(shù)據(jù)中心提供一流的支持。 為了支持比簡單K / V存儲更多的功能，所有這些其他系統(tǒng)都需要額外的工具和庫。 通過使用客戶端節(jié)點(diǎn)，Consul提供了一個簡單的API，只需要瘦客戶端。 另外，完全可以通過使用配置文件和DNS接口完全避免使用API，以獲得完整的服務(wù)發(fā)現(xiàn)解決方案，而完全沒有任何開發(fā)。

2、Consul vs. Chef, Puppet等

使用Chef，Puppet和其他配置管理工具的人來構(gòu)建服務(wù)發(fā)現(xiàn)機(jī)制并不罕見。 這通常通過查詢?nèi)譅顟B(tài)來在定期收斂運(yùn)行期間在每個節(jié)點(diǎn)上構(gòu)建配置文件來完成。
　　不幸的是，這種方法有一些陷阱。 配置信息是靜態(tài)的，不能比收斂運(yùn)行更頻繁地更新。 一般這是在幾分鐘或幾小時(shí)的間隔。 另外，沒有機(jī)制將系統(tǒng)狀態(tài)結(jié)合到配置中：不健康的節(jié)點(diǎn)可能進(jìn)一步接收流量，進(jìn)一步加劇問題。 使用這種方法還可以支持多個數(shù)據(jù)中心，因?yàn)橹醒敕?wù)器組必須管理所有數(shù)據(jù)中心。
　　Consul專門設(shè)計(jì)為服務(wù)發(fā)現(xiàn)工具。 因此，它對集群的狀態(tài)更具有動態(tài)性和響應(yīng)性。 節(jié)點(diǎn)可以注冊和注銷他們提供的服務(wù)，使得依賴的應(yīng)用程序和服務(wù)能夠快速發(fā)現(xiàn)所有提供者。 通過使用集成的健康檢查，Consul可以將流量從不健康的節(jié)點(diǎn)發(fā)送出去，從而使系統(tǒng)和服務(wù)能夠正常恢復(fù)。 可以通過配置管理工具提供的靜態(tài)配置可以移動到動態(tài)鍵/值存儲中。 這允許應(yīng)用程序配置更新，而不會收斂緩慢。 最后，由于每個數(shù)據(jù)中心獨(dú)立運(yùn)行，支持多個數(shù)據(jù)中心與單個數(shù)據(jù)中心沒有區(qū)別。
　　也就是說，Consul并不是配置管理工具的替代品。 這些工具對于設(shè)置應(yīng)用程序（包括Consul本身）至關(guān)重要。 靜態(tài)配置最好由現(xiàn)有工具管理，而動態(tài)狀態(tài)和發(fā)現(xiàn)則由Consul更好地管理。 配置管理和集群管理的分離也有一些有利的副作用：Chef和Puppet在沒有全局狀態(tài)的情況下變得更簡單，服務(wù)或配置更改不再需要定期運(yùn)行，并且由于配置管理運(yùn)行 不需要全局狀態(tài)。

3、Consul vs. Nagios, Sensu

Nagios和Sensu都是用于監(jiān)控的工具。 當(dāng)問題發(fā)生時(shí)，它們用于快速通知操作員。
　　Nagios使用一組配置為在遠(yuǎn)程主機(jī)上執(zhí)行檢查的中央服務(wù)器。 這種設(shè)計(jì)使Nagios難以規(guī)?；?yàn)榇笮痛?duì)迅速達(dá)到垂直尺度的限制，Nagios不容易水平縮放。 Nagios在現(xiàn)代DevOps和配置管理工具中也非常難以使用，因?yàn)樵谔砑踊騽h除遠(yuǎn)程服務(wù)器時(shí)必須更新本地配置。
　　Sensu有一個更現(xiàn)代化的設(shè)計(jì)，依靠當(dāng)?shù)氐拇砩踢\(yùn)行支票，并推動結(jié)果AMQP經(jīng)紀(jì)人。 許多服務(wù)器從代理獲取并處理健康檢查的結(jié)果。 這個模型比Nagios更具可擴(kuò)展性，因?yàn)樗试S更多的水平縮放和服務(wù)器和代理之間的較弱耦合。 但是，中央經(jīng)紀(jì)人已經(jīng)具有擴(kuò)展限制，并且是系統(tǒng)中的單一故障點(diǎn)。
　　Consul提供與Nagios和Sensu相同的健康檢查能力，對現(xiàn)代DevOps友好，并避免了其他系統(tǒng)固有的擴(kuò)展問題。 Consul在本地運(yùn)行所有檢查，如Sensu，避免給中央服務(wù)器造成負(fù)擔(dān)。 檢查狀態(tài)由Consul服務(wù)器維護(hù)，這是容錯的，沒有單點(diǎn)故障。 最后，Consul可以擴(kuò)展到更多的檢查，因?yàn)樗蕾囉谶吘売|發(fā)的更新。 這意味著更新僅在檢查從“通過”轉(zhuǎn)換為“失敗”或反之亦然時(shí)才被觸發(fā)。
　　在一個大型的船隊(duì)里，大部分的支票都是通過的，連失敗的少數(shù)人都是執(zhí)著的。 通過僅捕獲更改，Consul減少了運(yùn)行狀況檢查所使用的網(wǎng)絡(luò)和計(jì)算資源的數(shù)量，從而使系統(tǒng)具有更高的可擴(kuò)展性。
　　一個精明的讀者可能會注意到，如果一個Consul代理死亡，那么沒有邊緣觸發(fā)更新將會發(fā)生。 從其他節(jié)點(diǎn)的角度來看，所有的檢查都會顯示為穩(wěn)定狀態(tài)。 不過，Consul也是這樣的。 客戶端和服務(wù)器之間使用的gossip協(xié)議集成了一個分布式故障檢測器。 這意味著如果一個Consul代理失敗，將會檢測到失敗，并且因此所有由該節(jié)點(diǎn)運(yùn)行的檢查都可以被假定為失敗。 這個故障檢測器將工作分配到整個集群中，而最重要的是使邊緣觸發(fā)結(jié)構(gòu)能夠工作。

4、Consul vs. Eureka

Eureka是一個服務(wù)發(fā)現(xiàn)工具。 該體系結(jié)構(gòu)主要是客戶機(jī)/服務(wù)器，每個數(shù)據(jù)中心有一套Eureka服務(wù)器，通常每個可用性區(qū)域一個。 通常Eureka的客戶端使用嵌入式SDK來注冊和發(fā)現(xiàn)服務(wù)。 對于不是本地集成的客戶端，使用Ribbon等來透明地發(fā)現(xiàn)通過Eureka的服務(wù)。
　　Eureka提供了一個弱一致的服務(wù)觀點(diǎn)，使用盡力而為復(fù)制。 當(dāng)客戶端向服務(wù)器注冊時(shí)，該服務(wù)器將嘗試復(fù)制到其他服務(wù)器，但不提供保證。 服務(wù)注冊有一個短的生存時(shí)間（TTL），要求客戶端向服務(wù)器發(fā)送心跳。 不健康的服務(wù)或節(jié)點(diǎn)將停止心跳，使他們超時(shí)并從注冊表中刪除。 發(fā)現(xiàn)請求可以路由到任何服務(wù)，由于盡力而為的復(fù)制，服務(wù)可能會陳舊或丟失數(shù)據(jù)。 這個簡化的模型允許簡單的集群管理和高可擴(kuò)展性。
　　Consul提供了一套超級功能，包括更豐富的健康檢查，key/value存儲以及多數(shù)據(jù)中心意識。 Consul在每個數(shù)據(jù)中心都需要一組服務(wù)器，每個客戶端都有一個代理，類似于使用像Ribbon這樣的。 Consul代理允許大多數(shù)應(yīng)用程序成為Consul不知道的，通過配置文件執(zhí)行服務(wù)注冊，并通過DNS或負(fù)載平衡器sidecars發(fā)現(xiàn)。
　　Consul提供強(qiáng)大的一致性保證，因?yàn)榉?wù)器使用Raft協(xié)議復(fù)制狀態(tài)。 Consul支持豐富的健康檢查，包括TCP，HTTP，Nagios / Sensu兼容腳本或基于Eureka的TTL。 客戶端節(jié)點(diǎn)參與基于gossip的健康檢查，該檢查分配健康檢查的工作，而不像集中式心跳一樣成為可擴(kuò)展性挑戰(zhàn)。 發(fā)現(xiàn)請求被路由到當(dāng)選的Consul leader，這使得他們在默認(rèn)情況下是非常一致的。 允許陳舊讀取的客戶端使得任何服務(wù)器能夠處理他們的請求，從而允許像Eureka這樣的線性可伸縮性。
　　Consul強(qiáng)烈的一致性意味著它可以作為領(lǐng)導(dǎo)選舉和集群協(xié)調(diào)的鎖定服務(wù)。 Eureka不提供類似的保證，并且通常需要運(yùn)行ZooKeeper來獲得需要執(zhí)行協(xié)調(diào)或具有更強(qiáng)一致性需求的服務(wù)。
　　Consul提供了支持面向服務(wù)的體系結(jié)構(gòu)所需的工具包。 這包括服務(wù)發(fā)現(xiàn)，還包括豐富的健康檢查，鎖定，key/value，多數(shù)據(jù)中心聯(lián)合，事件系統(tǒng)和ACL。 Consul和consul-template和envconsul等工具的生態(tài)系統(tǒng)都盡量減少集成所需的應(yīng)用程序更改，以避免需要通過SDK進(jìn)行本地集成。 Eureka是一個更大的Netflix OSS套件的一部分，該套件預(yù)計(jì)應(yīng)用程序相對均勻且緊密集成。 因此，Eureka只解決了一小部分問題，希望ZooKeeper等其他工具可以一起使用。