Consul實戰：術語和命令解釋
這篇文章主要說下Consul里面用到最多的術語然后再說明下啟動命令背后發生的故事，為后面搭建一個Consul集群做準備。
Agent
Consul集群中在后臺長時間運行的進程就是代理。代理通過consul agent啟動。代理能夠以客戶端或服務端模式運行。因為集群中每個節點都必須有一個代理，因此將節點稱為客戶端或服務器更為簡單。所有的代理都可以有DNS或HTTP接口，負責健康檢查和保持服務同步。
Client
客戶端是將所有RPC請求轉發到服務端的代理?？蛻舳耸窍鄬o狀態的?？蛻舳伺艿奈ㄒ缓笈_程序就是參與LAN的gossip池。這種活動資源開銷最小，并且僅消耗少量的網絡帶寬。
Server
服務端是有擴展職責集的代理，擴展功能包括參與Raft仲裁，維護集群狀態，響應RPC請求，與其他數據中心交換WAN gossip，以及將查詢轉發給集群leader或遠程數據中心。
Datacenter
數據中心是一個私有的，低延遲的，高帶寬的網絡環境。當然這不包括穿越公網的通信，但出于我們的目的，單個EC2區域內的多個可用區將被視為單個數據中心的一部分。
Consensus
共識協議就是集群選舉leader的一致性協議和交易順序的協議。由于這些事務適用于有限狀態機，因此我們對一致性的定義意味著復制狀態機的一致性。共識在Wikipedia上有更詳細的描述，后面的文章會說Consul的實現。
Gossip
Consul建立在Serf之上，Serf提供了完整的，可用于多種目的Gossip協議。Serf提供了成員管理，故障檢測和事件廣播等功能。后面會重點說Gossip協議。Gossip會涉及到隨機的節點到節點的UDP通信。
LAN Gossip
指的是局域網Gossip池，其中包含的節點都位于同一局域網或數據中心上。
WAN Gossip
指僅包含服務端的WAN Gossip池。這些Consul服務端主要位于不同的數據中心上，一般通過Internet或廣域網進行通信。
RPC
遠程過程調用。一種請求/響應模式，允許客戶端向服務器發出請求。
serf
serf 和Consul一樣，也是出自 Hashicorp 的開源項目， 實現了去中心化的 gossip協議，其中 gossip 協議定義了一種類似病毒感染的消息傳播過程。一些著名的開源項目，如 Docker 和這里說的 Consul，網絡管理和服務發現的核心組件是基于 serf 實現的，然而它們背后的 serf 似乎還鮮為人知，一方面其復雜的理論以及不完善的文檔讓人望而卻步;另一方面，gossip 協議天然的數據 弱一致性 也制約了 serf 的使用場景。想深入了解的可以看這里：
https://www.infoq.cn/article/principle-and-impleme-of-de-centering-system-in-serf
https://www.serf.io/intro/index.html
創建一個數據中心，需要先創建一個服務端集群。創建一個服務端的推薦方法是使用-bootstrap-expect選項。此選項是創建的Consul服務器節點的預期數量，并在有那么多服務器可用時自動引導。為避免出現不一致和腦裂(多個服務器將其視為leader的集群)情況，必須要把-bootstrap-expect指定相同的值，或者在所有服務器上完全不指定任何值。只有指定值的服務器才會嘗試引導群集。
假設正在啟動一個三個服務節點的集群。可以通過分別提供-bootstrap-expect 3的標識來啟動節點A，節點B和節點C。節點啟動后，可以在服務輸出中看到一條警告消息。
- [WARN] raft: EnableSingleNode disabled, and no known peers. Aborting election.
警告表明節點期望有2個對等節點，但還不知道。下篇文章會介紹如何啟動一個三個幾點的Consul集群，到時候會用到這個命令。
接上一篇文章的啟動命令
- docker run \
- -d \
- -p 8500:8500 \
- -p 8600:8600/udp \
- --name=badger \
- consul agent -server -ui -node=server -bootstrap-expect=1
之前在創建Consul節點的時候，指定了bootstrap-expect的值為1，這里就是一個單節點的Consul集群，因為是實驗性的課程，所以這里設置了1，1個節點也是可以的，同樣可以作為服務使用，只是在生產環境別這樣設置，sh
端口
一個服務端Consul節點最多需要6個不同的端口才能正常工作，某些端口需要使用TCP，UDP或同時使用這兩種協議。
在運行Consul之前，應該確?？梢栽L問以下綁定端口。
| 用途 | 默認端口 |
|---|---|
| DNS: DNS服務 (TCP 或者 UDP) | 8600 |
| HTTP: HTTP接口(只有TCP) | 8500 |
| HTTPS: HTTPs接口 | 建議端口 ，默認關閉(8501)* |
| gRPC：gRPC接口 | 建議端口，默認關閉 (8502)* |
| LAN Serf: 局域網端口(TCP和UDP) | 8301 |
| Wan Serf：Serf WAN端口（TCP和UDP） | 8302 |
| 服務器：服務器RPC地址（僅TCP） | 8300 |
| Sidecar Proxy Min：包含的最小端口號，用于自動分配的sidecar服務注冊。 | 21000 |
| Sidecar Proxy Max: 包含的最大端口號，用于自動分配的sidecar服務注冊。 | 21255 |
端口用途
- DNS接口 用于解析DNS查詢
- HTTP API 客戶端通過HTTP API請求服務端
- HTTPS API(可選)默認情況下處于關閉狀態，但8501端口是多種工具默認使用的。
- gRPC API(可選)當前，gRPC僅用于將xDS API公開給Envoy代理。默認情況下它是關閉的，但是端口8502是各種工具默認使用的。在-dev模式下默認為8502。
- Serf LAN 用于處理LAN中的gossip協議。所有代理都需要。
- Serf WAN 服務器廣域網服務器使用它來通過廣域網傳播到其他服務器。從Consul 0.8開始，WAN連接泛洪功能要求Serf WAN端口(TCP / UDP)在WAN和LAN接口上進行監聽。
- RPC 服務器用來處理來自其他代理(agent)的請求。
總結
本文主要介紹了后面會用到的一些術語和一些啟動命令選項，還有就Consul會用到的幾個端口，通過了解這些，方便在后面的文章中學習Consul鋪開道路。
本文轉載自微信公眾號「碼小菜」，可以通過以下二維碼關注。轉載本文請聯系碼小菜公眾號。
