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