背景
筆者所在的公司正在進行微服務改造，這其中服務治理組件是必不可少的組件之一，在一番討論之后，最終決定放棄 Zookeeper 而采用 Consul 作為服務治理框架基礎組件，主要原因是 Consul 自帶健康檢查，通過該功能可以比較方便的監控應用的運行狀態，從而更好的運維整個系統，但在實際實施程序中筆者發現，目前網路上所能看到的很多資料，沒有比較清晰的解釋 Consul 的運行方式，特別是當用戶對于 Zookeeper 主動通知的方式比較熟悉之后，對于 Consul 這種每次都通過 HTTP 呼叫獲取服務資訊的方式還是存在很多疑惑的，比如：這樣的方式在呼叫鏈中，不是會導致 HTTP 呼叫鏈增加一倍嗎？
多資料中心
關于Consul，首先介紹最常見的一副圖：
該圖表示 Consul 支持的一個重要的功能———多資料中心，這也是很多服務注冊發現工具所不具備的，通過上述圖中我們可以解讀出如下一些資訊：
- Cosnul 分為 Server 和 Client，多資料中心的實作主要依靠兩個資料中心的 Server 進行通信，并且每個資料中心有各自的主節點，也就是各自選舉，
- Client 與 Server 之間通過8300埠，TCP協議進行RPC互動，
- Client 與其他實體之間通過 8301 以 TCP/UDP 協議進行 LAN GOSSIP 互動
上圖解釋了 Consul 集群各個 Server 之間的關系，那么 Server 和 Client 之間的關系又是怎樣呢？在理解這個問題之前，要先理解一個概念——反熵，
反熵
1. 概念
如果用一句話來概括那大概就是：分而治之，Server 將服務的管轄權（健康檢查，服務注冊等功能）層層下放給 Client，而 Client 在需要時（例如健康檢查失敗，新的服務注冊等）將所管轄范圍內的服務資訊進行轉發或上報，
關于反熵更加詳細的內容，可以參考園子里 波斯碼 所寫的文章——Consul的反熵，此文對于反熵的解釋非常到位, 感興趣的同學可以進一步閱讀，
這個特點也決定了 Consul 服務的注冊和健康檢查方式：所有操作都是通過 Consul Client 來實作的，如下圖所示：
根據上圖所示有個重要的概念：
1. 如果我們通過 Client 獲取 Agent 上的服務時，則只能回傳當前這個 Consul Client 中所注冊的所有服務
2. 而如果我們通過 Client 獲取 Catalog 上的服務時，則可以獲取到所有注冊服務，
事實上即使我們需要獲取 Catalog 中的資訊時，也不是直接與 Consul Server 互動，而是通過當前服務器 Consul Client 轉發請求獲取，同時取決于反熵概念，如果我們把每臺服務器看作管理轄區的最小單位，那么則需要在每臺機器上部署 Consul Client，用它來管理這臺服器上所有的服務，
2. 問題
如果按照上述資訊實施部署，那么我們來看下假如 APP1 呼叫 APP2 時，具體的呼叫順序時怎樣的：
如上圖所示，這樣的部署其實會帶來一些問題：
- 每臺機器上都需要部署 Consul Client
- 服務請求鏈路成倍增加了
問題1： 部署成本增加，實際上是一次性作業，況且假如你是容器化部署的話，那這個問題基本可以忽略，
問題2： 呼叫鏈路增加的確會帶來很多問題，主要是在呼叫 APP2 之前增加了 ① ② 兩步，其中步驟 ① 為本機 HTTP 呼叫，步驟 ② 為 Consul集群內部的 RPC 呼叫，經過筆者實際測驗這個呼叫耗時在毫秒級，除非對于性能要求很高的情況下，普通的呼叫鏈路請求是可以容忍的，而筆者所在公司的方案目前也是基于此方案，如果不能容忍，那只能犧牲部分一致性，在本地進行快取，并設定合理的同步周期，
上述問題筆者認為是 Consul 反熵機制所帶來的缺陷：只有通過主動請求 Consul Server 才能獲取所有服務的資訊，而又缺少比較好的通知機制，導致應用程式無法快取服務資訊， 而相比較于 Zookeeper，由于有了更好的通知機制，使各個應用程式可以快取服務串列資訊，只有當收到通知時，才主動更新服務資訊，同時 zookeeper 是長連接，當服務在出現問題時可以更加及時獲取到變化，而Consul 必須要依賴健康檢查，而健康檢查是有周期性的，當然凡事都各有利弊，但我們要知曉個中優缺點，才能更加合理使用，
通知機制——Consul Watch
Consul 可以通過配置 Agent 對以下型別的資料進行監控，并且同樣受反熵機制的影響，如果想監控集群下所有服務，那么需要將監控配置放在服務端：
- key – 監視指定K/V鍵值對
- keyprefix – Watch a prefix in the KV store
- services – 監視服務串列
- nodes – 監控節點串列
- service – 監視服務實體
- checks- 監視健康檢查的值
- event – 監視用戶事件
Consul 主要提供2種通知方式：
- script：當發生變化時執行一段腳本（可以是放在服務器中的任何可執行腳本，例如 py sh 等）
- HTTP endpoint：當發生變化時請求配置的http地址
例如在 Consul 組態檔創建 watch.json ，重啟 Consul 后生效
vi /data/consul/config/watch.json
{
"watches": [
{
"type": "services",
"handler_type": "http",
"http_handler_config": {
"path": "http://192.168.1.1:8080/services",
"method": "POST"
}
},
{
"type": "nodes",
"handler_type": "http",
"http_handler_config": {
"path": "http://192.168.1.1:8080/nodes",
"method": "POST"
}
},
{
"type": "checks",
"handler_type": "http",
"http_handler_config": {
"path": "http://192.168.1.1:8080/checks",
"method": "POST"
}
}
]
}
結語
相信有了這些概念的初步理解，可以在初次接觸 Consul 時減少一些疑惑，筆者在這個程序中，從博客園一些同學的文章中收益匪淺，特別是 波斯瑪 同學的3篇文章，值得詳細閱讀，這里也推薦大家一并學習，
參考資料：
https://www.cnblogs.com/bossma/tag/Consul/
https://www.cnblogs.com/sunsky303/p/9209024.html
https://blog.csdn.net/iamonlyme/category_9266562.html
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/81899.html
標籤：.NET Core
上一篇：為什么有ASP.NET