服务发现
consul 簡介
做服務發現的框架常用的有
zookeeper
eureka
etcd
consul
consul是分布式的、高可用、橫向擴展的。consul提供的一些關鍵特性：
service discovery：consul通過DNS或者HTTP接口使服務注冊和服務發現變的很容易，一些外部服務，例如saas提供的也可以一樣注冊。
health checking：健康檢測使consul可以快速的告警在集群中的操作。和服務發現的集成，可以防止服務轉發到故障的服務上面。
key/value storage：一個用來存儲動態配置的系統。提供簡單的HTTP接口，可以在任何地方操作。
multi-datacenter：無需復雜的配置，即可支持任意數量的區域。
架構圖及解析
讓我們把這幅圖分解描述。首先，我們可以看到有兩個數據中心，分別標記為“1”和“2”。Consul擁有對多個數據中心的一流支持，這是比較常見的情況。
在每個數據中心中，我們都有客戶機和服務器。預計將有三到五臺服務器。這在故障情況下的可用性和性能之間取得了平衡，因為隨著添加更多的機器，一致性會逐漸變慢。但是，客戶端的數量沒有限制，可以很容易地擴展到數千或數萬。
Consul 實現多個數據中心都依賴于gossip protocol協議。這樣做有幾個目的:首先，不需要使用服務器的地址來配置客戶端;服務發現是自動完成的。其次，健康檢查故障的工作不是放在服務器上，而是分布式的。這使得故障檢測比單純的心跳模式更具可伸縮性。為節點提供故障檢測;如果無法訪問代理，則節點可能經歷了故障。
每個數據中心中的服務器都是一個筏對等集的一部分。這意味著它們一起工作來選舉單個leader，一個被選中的服務器有額外的職責。領導負責處理所有的查詢和事務。事務還必須作為協商一致協議的一部分復制到所有對等方。由于這個需求，當非leader服務器接收到RPC請求時，它會將其轉發給集群leader。
Consul的使用場景
Consul的應用場景包括服務發現、服務隔離、服務配置：
服務發現場景中consul作為注冊中心，服務地址被注冊到consul中以后，可以使用consul提供的dns、http接口查詢，consul支持health check。
服務隔離場景中consul支持以服務為單位設置訪問策略，能同時支持經典的平臺和新興的平臺，支持tls證書分發，service-to-service加密。
服務配置場景中consul提供key-value數據存儲功能，并且能將變動迅速地通知出去，借助Consul可以實現配置共享，需要讀取配置的服務可以從Consul中讀取到準確的配置信息。
Consul可以幫助系統管理者更清晰的了解復雜系統內部的系統架構，運維人員可以將Consul看成一種監控軟件，也可以看成一種資產（資源）管理系統。
比如：docker實例的注冊與配置共享、coreos實例的注冊與配置共享、vitess集群、SaaS應用的配置共享、Consul與confd服務集成，動態生成nginx和haproxy配置文件或者Consul結合nginx構建高可用可擴展的Web服務。
docker安裝
第一個server啟動
docker run -d --name=consul-server1 --net=host -e CONSUL_BIND_INTERFACE=ens33 -v /consul/config:/consul/config -v /consul/data:/consul/data consul:latest agent -server -node=agent128 -bootstrap-expect=3 -client=0.0.0.0 -ui
剩下兩個Server啟動并加入集群
docker run -d --name=consul-server2 --net=host -e CONSUL_BIND_INTERFACE=ens33 consul agent -server -node=agent129 -client=0.0.0.0 -join 192.168.30.128 docker run -d --name=consul-server3 --net=host -e CONSUL_BIND_INTERFACE=ens33 consul agent -server -node=agent130 -client=0.0.0.0 -join 192.168.30.128
Client啟動并加入集群
docker run -d --name=consul-client1 --net=host -e CONSUL_BIND_INTERFACE=ens33 consul agent -node=agent131 -client=0.0.0.0 -join 192.168.30.128
查看集群：
docker exec consul-server1 consul members Node Address Status Type Build Protocol DC Segment agent128 192.168.30.128:8301 alive server 1.8.3 2 dc1 <all> agent129 192.168.30.129:8301 alive server 1.8.3 2 dc1 <all> agent130 192.168.30.130:8301 alive server 1.8.3 2 dc1 <all> agent131 192.168.30.131:8301 alive client 1.8.3 2 dc1 <default>
訪問ui：
訪問192.168.30.128:8500/ui，
參考：https://www.imooc.com/article/296209/
https://www.imooc.com/article/284030/
https://blog.csdn.net/a312586670/article/details/105337943/
首先Consul支持多數據中心，在上圖中有兩個DataCenter，他們通過Internet互聯，同時請注意為了提高通信效率，只有Server節點才加入跨數據中心的通信。
作者：KaliArch
鏈接：https://www.imooc.com/article/296209/
來源：慕課網
本文首次發布于慕課網 ，轉載請注明出處，謝謝合作
首先Consul支持多數據中心，在上圖中有兩個DataCenter，他們通過Internet互聯，同時請注意為了提高通信效率，只有Server節點才加入跨數據中心的通信。
在單個數據中心中，Consul分為Client和Server兩種節點（所有的節點也被稱為Agent），Server節點保存數據，Client負責健康檢查及轉發數據請求到Server；Server節點有一個Leader和多個Follower，Leader節點會將數據同步到Follower，Server的數量推薦是3個或者5個，在Leader掛掉的時候會啟動選舉機制產生一個新的Leader。
集群內的Consul節點通過gossip協議（流言協議）維護成員關系，也就是說某個節點了解集群內現在還有哪些節點，這些節點是Client還是Server。單個數據中心的流言協議同時使用TCP和UDP通信，并且都使用8301端口。跨數據中心的流言協議也同時使用TCP和UDP通信，端口使用8302。
集群內數據的讀寫請求既可以直接發到Server，也可以通過Client使用RPC轉發到Server，請求最終會到達Leader節點，在允許數據輕微陳舊的情況下，讀請求也可以在普通的Server節點完成，集群內數據的讀寫和復制都是通過TCP的8300端口完成。
作者：KaliArch
鏈接：https://www.imooc.com/article/296209/
來源：慕課網
本文首次發布于慕課網 ，轉載請注明出處，謝謝合作
首先Consul支持多數據中心，在上圖中有兩個DataCenter，他們通過Internet互聯，同時請注意為了提高通信效率，只有Server節點才加入跨數據中心的通信。
在單個數據中心中，Consul分為Client和Server兩種節點（所有的節點也被稱為Agent），Server節點保存數據，Client負責健康檢查及轉發數據請求到Server；Server節點有一個Leader和多個Follower，Leader節點會將數據同步到Follower，Server的數量推薦是3個或者5個，在Leader掛掉的時候會啟動選舉機制產生一個新的Leader。
集群內的Consul節點通過gossip協議（流言協議）維護成員關系，也就是說某個節點了解集群內現在還有哪些節點，這些節點是Client還是Server。單個數據中心的流言協議同時使用TCP和UDP通信，并且都使用8301端口。跨數據中心的流言協議也同時使用TCP和UDP通信，端口使用8302。
集群內數據的讀寫請求既可以直接發到Server，也可以通過Client使用RPC轉發到Server，請求最終會到達Leader節點，在允許數據輕微陳舊的情況下，讀請求也可以在普通的Server節點完成，集群內數據的讀寫和復制都是通過TCP的8300端口完成。
Consul 集群間使用了 Gossip 協議通信和 raft 一致性算法
Gossip —— Gossip protocol 也叫 Epidemic Protocol （流行病協議），實際上它還有很多別名，比如：“流言算法”、“疫情傳播算法”等。 這個協議的作用就像其名字表示的意思一樣，非常容易理解，它的方式其實在我們日常生活中也很常見，比如電腦病毒的傳播，森林大火，細胞擴散等等。
Client —— 一個 Client 是一個轉發所有 RPC 到 server 的代理。這個 client 是相對無狀態的。client 唯一執行的后臺活動是加入 LAN gossip 池。這有一個最低的資源開銷并且僅消耗少量的網絡帶寬。
Server —— 一個 server 是一個有一組擴展功能的代理，這些功能包括參與 Raft 選舉，維護集群狀態，響應 RPC 查詢，與其他數據中心交互 WAN gossip 和轉發查詢給 leader 或者遠程數據中心。
DataCenter —— 雖然數據中心的定義是顯而易見的，但是有一些細微的細節必須考慮。例如，在 EC2 中，多個可用區域被認為組成一個數據中心。我們定義數據中心為一個私有的，低延遲和高帶寬的一個網絡環境。這不包括訪問公共網絡，但是對于我們而言，同一個 EC2 中的多個可用區域可以被認為是一個數據中心的一部分。
Consensus —— 一致性，使用 Consensus 來表明就 leader 選舉和事務的順序達成一致。為了以容錯方式達成一致，一般有超過半數一致則可以認為整體一致。Consul 使用 Raft 實現一致性，進行 leader 選舉，在 consul 中的使用 bootstrap 時，可以進行自選，其他 server 加入進來后 bootstrap 就可以取消。
LAN Gossip —— 它包含所有位于同一個局域網或者數據中心的所有節點。
WAN Gossip —— 它只包含 Server。這些 server 主要分布在不同的數據中心并且通常通過因特網或者廣域網通信。
RPC——遠程過程調用。這是一個允許 client 請求 server 的請求/響應機制。
1.3.2 Consul服務發現原理
1.3.2.1 原理圖
作者：KaliArch
鏈接：https://www.imooc.com/article/296209/
來源：慕課網
本文首次發布于慕課網 ，轉載請注明出處，謝謝合作
架構圖及解析
作者：KaliArch
鏈接：https://www.imooc.com/article/296209/
來源：慕課網
本文首次發布于慕課網 ，轉載請注明出處，謝謝合作
架構圖及解析
作者：KaliArch
鏈接：https://www.imooc.com/article/296209/
來源：慕課網
本文首次發布于慕課網 ，轉載請注明出處，謝謝合作
總結
- 上一篇： java 输出三位数和n位数的每一位的数
- 下一篇： kali2020.2实现开机root权限