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