ASP.NET CORE 使用Consul實現服務治理與健康檢查(1)——概念篇

背景

筆者所在的公司正在進行微服務改造，這其中服務治理組件是必不可少的組件之一，在一番討論以後，最終決定放棄 Zookeeper 而採用 Consul 做爲服務治理框架基礎組件。主要緣由是 Consul 自帶健康檢查，經過該功能能夠比較方便的監控應用的運行狀態，從而更好的運維整個系統。但在實際實施過程當中筆者發現，目前網絡上所能看到的不少資料，沒有比較清晰的解釋 Consul 的運行方式，特別是當用戶對於 Zookeeper 主動通知的方式比較熟悉以後，對於 Consul 這種每次都經過 HTTP 調用獲取服務信息的方式仍是存在不少疑惑的，好比：這樣的方式在調用鏈中，不是會致使 HTTP 調用鏈增長一倍嗎？

多數據中心

關於Consul，首先介紹最多見的一副圖：

該圖表示 Consul 支持的一個重要的功能———多數據中心，這也是不少服務註冊發現工具所不具有的，經過上述圖中咱們能夠解讀出以下一些信息：

1. Cosnul 分爲 Server 和 Client，多數據中心的實現主要依靠兩個數據中心的 Server 進行通訊，而且每一個數據中心有各自的主節點，也就是各自選舉。
2. Client 與 Server 之間經過8300端口，TCP協議進行RPC交互。
3. 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 時，具體的調用順序時怎樣的：

如上圖所示，這樣的部署其實會帶來一些問題：

1. 每臺機器上都須要部署 Consul Client
2. 服務請求鏈路成倍增長了

問題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種通知方式：

1. script：當發生變化時執行一段腳本（能夠是放在服務器中的任何可執行腳本，例如 py sh 等）
2. 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/
http://www.javashuo.com/article/p-fhmgwuqp-cs.html
https://blog.csdn.net/iamonlyme/category_9266562.html