1.consul的工作原理 · 初心（學習筆記）

## **consul原理與實戰** ### **1. consul簡介：** >[] consul是google開源的一個使用go語言開發的服務發現、配置管理中心服務。內置了服務注冊與發現框架、分布一致性協議實現、健康檢查、Key/Value存儲、多數據中心方案，不再需要依賴其他工具（比如ZooKeeper等）。服務部署簡單，只有一個可運行的二進制的包。每個節點都需要運行agent，他有兩種運行模式server和client。每個數據中心官方建議需要3或5個server節點以保證數據安全，同時保證server-leader的選舉能夠正確的進行。 **類似的工具還有：ZooKeeper，etcd等等。** ***** ### **2. 為什么使用服務發現：** * 防止硬編碼、容災、水平擴縮容、提高運維效率等等，只要你想使用服務發現總能找到合適的理由。 * 一般的說法是因為使用微服務架構。傳統的單體架構不夠靈活不能很好的適應變化，從而向微服務架構進行轉換。 * 而伴隨著大量服務的出現，管理運維十分不便，于是開始搞一些自動化的策略，服務發現應運而生。所以如果需要使用服務發現，你應該有一些對服務治理的痛點。 * 但是引入服務發現就可能引入一些技術棧，增加系統總體的復雜度，如果你只有很少的幾個服務，比如 10 個以下，并且業務不怎么變化，吞吐量預計也很穩定，可能就沒有必要使用服務發現。 ***** ### **3. consul工作原理** 掌握原理前，需了解下consul的組成結構，即多數據中心 ![](https://img.kancloud.cn/e9/0c/e90c5c7f95e5e3281b2bc055d57980f0_625x629.png) **集群中的特性功能：** * 節點角色：leader(領導者)、Follower(跟隨者) * consul節點身份：server、client * Agent：即節點內包含的一個后臺處理程序 * 健康檢查：由client的Agent來進行健康檢查的功能首先 Consul 支持多數據中心，在上圖中有兩個 DataCenter，他們通過 Internet 互聯，同時請注意為了提高通信效率，只有 Server 節點才加入跨數據中心的通信。 ***** 在單個數據中心中，Consul 分為 Client 和 Server 兩種節點（所有的節點也被稱為 Agent），Server 節點保存數據，Client 負責健康檢查及轉發數據請求到 Server。 ***** Server 節點有一個 Leader 和多個 Follower，Leader 節點會將數據同步到 Follower，Server 的數量推薦是 3 個或者 5 個，在 Leader 掛掉的時候會啟動選舉機制產生一個新的 Leader。 ***** 集群內的 Consul 節點通過 gossip 協議（流言協議）維護成員關系，也就是說某個節點了解集群內現在還有哪些節點，這些節點是 Client 還是 Server。 ***** 單個數據中心的流言協議同時使用 TCP 和 UDP 通信，并且都使用 8301 端口。跨數據中心的流言協議也同時使用 TCP 和 UDP 通信，端口使用 8302。 ***** 集群內數據的讀寫請求既可以直接發到 Server，也可以通過 Client 使用 RPC 轉發到 Server，請求最終會到達 Leader 節點。 ***** 在允許數據輕微陳舊的情況下，讀請求也可以在普通的 Server 節點完成，集群內數據的讀寫和復制都是通過 TCP 的 8300 端口完成。 ***** ### **4. consul服務發現原理** ![](https://img.kancloud.cn/95/aa/95aa5e5536abdbd149fe02a258c1ec74_766x433.png) 首先需要有一個正常的 Consul 集群，有 Server，有 Leader。這里在服務器 Server1、Server2、Server3 上分別部署了 Consul Server。 ***** 假設他們選舉了 Server2 上的 Consul Server 節點為 Leader。這些服務器上最好只部署 Consul 程序，以盡量維護 Consul Server 的穩定。 ***** 然后在服務器 Server4 和 Server5 上通過 Consul Client 分別注冊 Service A、B、C，這里每個 Service 分別部署在了兩個服務器上，這樣可以避免 Service 的單點問題。 ***** 服務注冊到 Consul 可以通過 HTTP API（8500 端口）的方式，也可以通過 Consul 配置文件的方式。 ***** Consul Client 可以認為是無狀態的，它將注冊信息通過 RPC 轉發到 Consul Server，服務信息保存在 Server 的各個節點中，并且通過 Raft 實現了強一致性。 ***** 最后在服務器 Server6 中 Program D 需要訪問 Service B，這時候 Program D 首先訪問本機 Consul Client 提供的 HTTP API，本機 Client 會將請求轉發到 Consul Server。 ***** Consul Server 查詢到 Service B 當前的信息返回，最終 Program D 拿到了 Service B 的所有部署的 IP 和端口，然后就可以選擇 Service B 的其中一個部署并向其發起請求了。 ***** 如果服務發現采用的是 DNS 方式，則 Program D 中直接使用 Service B 的服務發現域名，域名解析請求首先到達本機 DNS 代理，然后轉發到本機 Consul Client，本機 Client 會將請求轉發到 Consul Server。 ***** Consul Server 查詢到 Service B 當前的信息返回，最終 Program D 拿到了 Service B 的某個部署的 IP 和端口。