背景 筆者所在的公司正在進行微服務改造，這其中服務治理組件是必不可少的組件之一，在一番討論之後，最終決定放棄 Zookeeper 而採用 Consul 作為服務治理框架基礎組件。主要原因是 Consul 自帶健康檢查，通過該功能可以比較方便的監控應用的運行狀態，從而更好的運維整個系統。但在實際實施過 ...
背景
筆者所在的公司正在進行微服務改造，這其中服務治理組件是必不可少的組件之一，在一番討論之後，最終決定放棄 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
