Consul
Consul是一個支持多數據中心分布式高可用的服務發現和配置共享的服務軟件，由HashiCrop公司用Go語言開發，基於Mozilla Public License 2.0的協議進行開源。Consul支持健康檢查，並允許http和dns協議調用APi存儲鍵值對。
命令行超級好用的虛擬機管理軟件被感染他也是HashiCrop公司開發的產品。一致性協議采用Raft算法，用來保證服務的高可用性，使用gossip協議管理成員和廣播消息，並支持acl訪問控制。
下載安裝
官網下載：https://www.consul.io/downloads.html
下載一個對應的版本，得到一個zip壓縮包。
在你想要安裝的位置解壓就行，只有一個 consul.exe 文件（我的解壓位置是：D:\consul）
記得設置環境變量（在 path 中新增一條）
運行dos窗口，cmd 命令窗口啟動：輸入：consul agent -dev
consul 自帶 UI 界面，打開網址：http://localhost:8500 ，可以看到服務界面。
Consul 優勢
1. 使用 Raft 算法來保證一致性, 比復雜的 Paxos 算法更直接. 相比較而言, zookeeper 2.采用的是 Paxos, 而 etcd 使用的則是 Raft.
3. 支持多數據中心，內外網的服務采用不同的端口進行監聽。 多數據中心集群可以避免單數據中心的單點故障,而其部署則需要考慮網 絡延遲, 分片等情況等. zookeeper 和 etcd 均不提供多數據中心功能的支持.
4. 支持健康檢查. etcd 不提供此功能.
5. 支持 http 和 dns 協議接口. zookeeper 的集成較為復雜, etcd 只支持 http 協議.
6. 官方提供web管理界面, etcd 無此功能.
綜合比較, Consul 作為服務注冊和配置管理的新星, 比較值得關注和研究.
一、Consul是什么？
Consul有多個組件，但總體而言，它是基礎架構中的一款服務發現和配置的工具，他提供了幾個關鍵功能：
- 服務發現：Consul client可以提供服務，例如api或mysql，也可以使用Consul client來發現指定服務的提供者。使用DNS或HTTp，應用程序可以輕松找到他們所以來的服務。
- 健康檢查：Consul client可以提供任何數量的健康檢查，或者與給定的服務（Web服務器是否返回200 OK），或與本地節點（“內存利用率是否低於90%”）相關聯。可以使用次信息來監控集群運行狀況，服務器發現組件使用此信息將流量從有問題的主機中移除出去。
- KV Store：應用程序可以使用Consul 的分層鍵/值存儲，包括動態配置，功能標記，協調，leader選舉等等。簡單的HTTP API可以讓它易於使用。
- 多數據中心：Consul支持多個數據中心。這就意味着Consul用戶不必擔心構建額外的抽象層以擴展到多個區域。
Consul旨在對DevOps社區和應用程序開發人員友好，使其成為現代化，彈性基礎架構的完美選擇。
二、Consul 基本架構
Consul 是一個分布式，高可用的系統。
向Consul提供服務的每個節點都運行一個Consul代理。 發現其他服務或獲取/設置鍵/值數據不需要運行代理。 代理負責健康檢查節點上的服務以及節點本身。
代理與一個或多個Consul服務器通信。Consul 服務器是數據存儲和復制的地方。 服務器自己選出一個 leader。 雖然Consul可以在一台服務器上運行，但推薦使用3到5台來避免數據丟失的情況。 每個數據中心都建議使用一組Consul服務器。
需要發現其他服務或節點的基礎架構組件可以查詢任何Consul服務器或任何Consul代理。 代理自動將查詢轉發到服務器。
每個數據中心都運行Consul服務器集群。 當跨數據中心服務發現或配置請求時，本地Consul服務器將請求轉發到遠程數據中心並返回結果。
三、Consul 與 “其它軟件” 相比較
Consul解決的問題是多種多樣的，但是每個單獨的特征已經被許多不同的系統解決了。 盡管沒有單一的系統提供Consul的所有功能，但還有其他的選擇可以來解決這些問題。
1、Consul 與 ZooKeeper, doozerd, etcd
ZooKeeper，doozerd和etcd在他們的架構中都是相似的。 所有這三個服務器節點都需要一定數量的節點才能運行（通常是簡單多數）。 它們是高度一致的，並且公開了可以通過應用程序中的客戶端庫來構建復雜的分布式系統的各種基元。
Consul 還使用單個數據中心內的服務器節點。 在每個數據中心，Consul服務器都需要一個仲裁來操作並提供強大的一致性。 不過，Consul擁有對多個數據中心的本地支持，以及連接服務器節點和客戶端的功能豐富的系統。
所有這些系統在提供“鍵/值”存儲時都具有大致相同的語義：讀取具有強烈的一致性，為了在網絡分區的情況下保持一致性，犧牲了可用性。 但是，當這些系統用於高級案例時，這些差異會變得更加明顯。
這些系統提供的語義對於構建服務發現系統是有吸引力的，但重要的是要強調必須構建這些功能。 ZooKeeper等軟件僅提供原始K / V存儲，並要求應用程序開發人員構建自己的系統以提供服務發現。 相比之下，Consul為服務發現提供了一個可用的框架，並且消除了猜測工作和開發工作。 客戶端只需注冊服務，然后使用DNS或HTTP接口執行發現。 其他系統需要一個自己定制的解決方案。
ZooKeeper提供臨時節點，這些節點是客戶端斷開連接時刪除的K / V條目。 這些比心跳系統更復雜，但仍然存在固有的可擴展性問題，並增加了客戶端的復雜性。 所有客戶端必須保持與ZooKeeper服務器的活動連接並執行保持活動。 另外，這需要“厚厚的客戶端”，這些客戶端很難編寫，經常導致調試難題。
Consul 使用非常不同的體系結構進行健康檢查。 Consul客戶端不是只有服務器節點，而是在集群中的每個節點上運行。 這些客戶端是gossip pool的一部分，可以提供多種功能，包括分布式健康檢查。 gossip協議實現了一個高效的故障檢測器，可以擴展到任何規模的集群，而不用將任務集中在任何選定的服務器組上。 客戶端還可以在本地運行更豐富的運行狀況檢查，而ZooKeeper臨時節點對活躍性進行非常原始的檢查。 通過Consul，客戶端可以檢查Web服務器是否返回200的狀態碼，內存使用情況，有足夠的磁盤空間等。和ZooKeeper一樣，Consul客戶端公開一個簡單的HTTP接口，避免將系統的復雜性暴露給客戶端。
Consul為服務發現，運行狀況檢查，K / V存儲和多個數據中心提供一流的支持。 為了支持比簡單K / V存儲更多的功能，所有這些其他系統都需要額外的工具和庫。 通過使用客戶端節點，Consul提供了一個簡單的API，只需要客戶端。 另外，完全可以通過使用配置文件和DNS接口完全避免使用API，以獲得完整的服務發現解決方案，而完全沒有任何開發。
2、Consul 與 Chef, Puppet等
使用Chef，Puppet和其他配置管理工具的人來構建服務發現機制並不罕見。 這通常通過查詢全局狀態來在定期收斂運行期間在每個節點上構建配置文件來完成。
不幸的是，這種方法有一些陷阱。 配置信息是靜態的，不能比收斂運行更頻繁地更新。 一般這是在幾分鍾或幾小時的間隔。 另外，沒有機制將系統狀態結合到配置中：不健康的節點可能進一步接收流量，進一步加劇問題。 使用這種方法還可以支持多個數據中心，因為中央服務器組必須管理所有數據中心。
Consul專門設計為服務發現工具。 因此，它對集群的狀態更具有動態性和響應性。 節點可以注冊和注銷他們提供的服務，使得依賴的應用程序和服務能夠快速發現所有提供者。 通過使用集成的健康檢查，Consul可以將流量從不健康的節點發送出去，從而使系統和服務能夠正常恢復。 可以通過配置管理工具提供的靜態配置可以移動到動態鍵/值存儲中。 這允許應用程序配置更新，而不會收斂緩慢。 最后，由於每個數據中心獨立運行，支持多個數據中心與單個數據中心沒有區別。
也就是說，Consul並不是配置管理工具的替代品。 這些工具對於設置應用程序（包括Consul本身）至關重要。 靜態配置最好由現有工具管理，而動態狀態和發現則由Consul更好地管理。 配置管理和集群管理的分離也有一些有利的副作用：Chef和Puppet在沒有全局狀態的情況下變得更簡單，服務或配置更改不再需要定期運行，並且由於配置管理運行 不需要全局狀態。
3、Consul與 Nagios, Sensu
Nagios和Sensu都是用於監控的工具。 當問題發生時，它們用於快速通知操作員。
Nagios使用一組配置為在遠程主機上執行檢查的中央服務器。 這種設計使Nagios難以規模化，因為大型船隊迅速達到垂直尺度的限制，Nagios不容易水平縮放。 Nagios在現代DevOps和配置管理工具中也非常難以使用，因為在添加或刪除遠程服務器時必須更新本地配置。
Sensu有一個更現代化的設計，依靠當地的代理商運行支票，並推動結果AMQP經紀人。 許多服務器從代理獲取並處理健康檢查的結果。 這個模型比Nagios更具可擴展性，因為它允許更多的水平縮放和服務器和代理之間的較弱耦合。 但是，中央經紀人已經具有擴展限制，並且是系統中的單一故障點。
Consul提供與Nagios和Sensu相同的健康檢查能力，對現代DevOps友好，並避免了其他系統固有的擴展問題。 Consul在本地運行所有檢查，如Sensu，避免給中央服務器造成負擔。 檢查狀態由Consul服務器維護，這是容錯的，沒有單點故障。 最后，Consul可以擴展到更多的檢查，因為它依賴於邊緣觸發的更新。 這意味着更新僅在檢查從“通過”轉換為“失敗”或反之亦然時才被觸發。
在一個大型的船隊里，大部分的支票都是通過的，連失敗的少數人都是執着的。 通過僅捕獲更改，Consul減少了運行狀況檢查所使用的網絡和計算資源的數量，從而使系統具有更高的可擴展性。
一個精明的讀者可能會注意到，如果一個Consul代理死亡，那么沒有邊緣觸發更新將會發生。 從其他節點的角度來看，所有的檢查都會顯示為穩定狀態。 不過，Consul也是這樣的。 客戶端和服務器之間使用的gossip協議集成了一個分布式故障檢測器。 這意味着如果一個Consul代理失敗，將會檢測到失敗，並且因此所有由該節點運行的檢查都可以被假定為失敗。 這個故障檢測器將工作分配到整個集群中，而最重要的是使邊緣觸發結構能夠工作。
4、Consul 與 Eureka
Eureka是一個服務發現工具。 該體系結構主要是客戶機/服務器，每個數據中心有一套Eureka服務器，通常每個可用性區域一個。 通常Eureka的客戶端使用嵌入式SDK來注冊和發現服務。 對於不是本地集成的客戶端，使用Ribbon等來透明地發現通過Eureka的服務。
Eureka提供了一個弱一致的服務觀點，使用盡力而為復制。 當客戶端向服務器注冊時，該服務器將嘗試復制到其他服務器，但不提供保證。 服務注冊有一個短的生存時間（TTL），要求客戶端向服務器發送心跳。 不健康的服務或節點將停止心跳，使他們超時並從注冊表中刪除。 發現請求可以路由到任何服務，由於盡力而為的復制，服務可能會陳舊或丟失數據。 這個簡化的模型允許簡單的集群管理和高可擴展性。
Consul提供了一套超級功能，包括更豐富的健康檢查，key/value存儲以及多數據中心意識。 Consul在每個數據中心都需要一組服務器，每個客戶端都有一個代理，類似於使用像Ribbon這樣的。 Consul代理允許大多數應用程序成為Consul不知道的，通過配置文件執行服務注冊，並通過DNS或負載平衡器sidecars發現。
Consul提供強大的一致性保證，因為服務器使用Raft協議復制狀態。 Consul支持豐富的健康檢查，包括TCP，HTTP，Nagios / Sensu兼容腳本或基於Eureka的TTL。 客戶端節點參與基於gossip的健康檢查，該檢查分配健康檢查的工作，而不像集中式心跳一樣成為可擴展性挑戰。 發現請求被路由到當選的Consul leader，這使得他們在默認情況下是非常一致的。 允許陳舊讀取的客戶端使得任何服務器能夠處理他們的請求，從而允許像Eureka這樣的線性可伸縮性。
Consul強烈的一致性意味着它可以作為領導選舉和集群協調的鎖定服務。 Eureka不提供類似的保證，並且通常需要運行ZooKeeper來獲得需要執行協調或具有更強一致性需求的服務。
Consul提供了支持面向服務的體系結構所需的工具包。 這包括服務發現，還包括豐富的健康檢查，鎖定，key/value，多數據中心聯合，事件系統和ACL。 Consul和consul-template和envconsul等工具的生態系統都盡量減少集成所需的應用程序更改，以避免需要通過SDK進行本地集成。 Eureka是一個更大的Netflix OSS套件的一部分，該套件預計應用程序相對均勻且緊密集成。 因此，Eureka只解決了一小部分問題，希望ZooKeeper等其他工具可以一起使用。