Consul初探-在深交以前先認識

Consul 是什麼?

Consul 官方站點:https://www.consul.io/nginx

首先,官方介紹是:Consul 是一種服務網格的解決方案,在 Consul 中,提供了服務發現、配置、分段等控制管理平臺,Consul 中的每項功能均可以單獨使用,也能夠一塊兒使用來構建完整的服務網格;在 Consul 內部,有一個簡單的代理服務,因此在安裝 Consul 後,立刻就能夠開始使用 Consul ;固然,Consul 也支持集成第三方代理,好比 Envoy。服務器

以上,是官方的介紹,我第一次看的時候也是很是的懵逼,由於這裏面涉及了太多的專業詞彙,下面就說說本身的理解。架構

Consul 是一個服務組件,在用戶下載 Consul 的安裝包後,能夠當即運行它,或者經過其它託管程序運行它,Consul 只有一個程序包,無需另行安裝;當運行 Consul 的時候,須要爲其指定一些必須的參數,以供 Consul 在運行時使用;
好比參數 -data-dir 表示指定 Consul 存放數據的目錄。分佈式

服務註冊

Consul 內部偵聽 8500 端口,提供給 Consul 的客戶端註冊服務,好比張三開發了一個購物車程序,該購物車程序包含了「加入購物車」、「清空購物車」 兩個接口,張三在開發購物車程序的時候,使用了 Consul 的客戶端包組件,在程序運行起來之後,購物車程序就自動的鏈接到 Consul 的 8500 端口,註冊了一個服務,該服務被命名爲「購物車程序」,此時,Consul 並不知道 「購物車程序」有多少個接口,Consul 只知道 「購物車程序」的服務地址、端口。學習

服務發現

在「購物車程序」註冊到 Consul 後,Consul 也僅僅知道有這麼一個服務註冊進來了,而且還配置了健康檢查, Consul 會定時的去鏈接 「購物車程序」,確保其還處於可提供服務的狀態,任何人(程序)均可以經過 Consul 的外部地址訪問 Consul 內部的已註冊的服務列表,從而得到真實的服務地址,而後調用該真實地址,得到結果。url

集羣

Consul 是一個分佈式的解決方案,能夠部署多個 Consul 實例,確保數據中心的持續穩定,在 Consul 集羣中,內部採用投票的方式選舉出 leader,而後纔開始運行整個集羣,只有正確選舉出 leader 後,集羣纔開始工做,當一個服務註冊到 Consul 後,集羣將該服務進行同步,確保 Consul 集羣內的每一個節點都存儲了該服務的信息;而後,Consul 集羣將對該服務進行健康檢查和投票,超過半數經過,即認爲該服務爲正常(或者異常);一旦被投票認定爲異常的服務,該服務將不會被外部發現(不可訪問),在此過程當中,Consul 將持續的對該異常的服務進行檢查,一旦服務恢復,Consul 即刻將其加入正常服務。代理

服務器和客戶端

Consul 支持兩種運行的方式,即 server 和 client 模式,當一個 Consul 節點以 server 模式運行的時候,就表示該 Consul 節點會存儲服務和配置等相關信息,而且參與到健康檢查、leader 選舉等服務器事務中,與之相反的是,client 模式不會存儲服務信息。server

數據中心

每一個 Consul 節點都須要加入一個命名的數據中心(DataCenter),一個節點上,能夠運行多個數據中心,數據中心的做用在於應用隔離,至關於服務分組blog

鍵值存儲

在 Consul 內部,提供了簡單的數據存儲,也就是 key/value 系統,kv 系統很是強大,它的做用包括容許節點動態修改配置、執行 leader 選舉、服務發現、集成健康檢查、或者其它你想要存儲到 Consul 中的內容接口

Consul 的架構

好了,如今能夠來看一下官方的這張架構圖了

上圖有兩個數據中心,這兩個數據中心內部的數據是不會同步的,他們是獨立運行的,包括其內部的健康檢查、leader 選舉等等都是獨立的,結合上面的介紹,應該能夠很容易的讀懂這張圖。

Consul 能作什麼?

經過上面的介紹,咱們瞭解到了 Consul 其實就是一個分佈式的服務管理平臺,Consul 自己不具有網關的能力,因此,在通常的業務系統中,若是要應用 Consul ,一般的作法是在 Consul 的 server 節點上安裝一個 nginx,在 Consul 的服務註冊完成後,生成 nginx 的配置文件並從新加載它;此時,Consul 看上去好像是經過 nginx 具備了網關的能力,實際上,他們直接毫無關係;Consul 生成的 nginx 配置文件和咱們手寫的 nginx 配置文件沒有太多的不一樣,都是同樣的,其實就是把手寫 nginx 這種體力活給自動化了。

若是不想這麼麻煩的話怎麼辦呢?這就引入了服務網關的概念,以 .NETCore 爲例子,目前比較火熱的就是 ocelot+consul 的搭配,經過在服務中嵌入 ocelot 和 consul 的客戶端,自動的完成服務註冊到(Consul)和服務發現(ocelot讀取Consul中的服務);當用戶訪問某個 url 的時候,ocelot 將會根據路由將用戶請求轉發到從 Consul 拉取到的真正的服務中;對於 ocelot ,篇幅較長,這裏不做展開。

結束語

開篇純理論了,下一篇再上點實戰的幹活,就當學習記錄吧

相關文章
相關標籤/搜索