服務(wù)發(fā)現(xiàn)與Consul實(shí)戰(zhàn)：注冊(cè)中心原理到Spring Cloud集成)
做微服務(wù)這段時(shí)間被問(wèn)得最多的問(wèn)題之一就是服務(wù)之間到底是怎么找到彼此的IP 寫(xiě)死不就行了嘛短期可以服務(wù)一多、實(shí)例一變、一擴(kuò)縮容馬上就會(huì)亂成一鍋粥。這也是為什么現(xiàn)在只要聊到微服務(wù)架構(gòu)服務(wù)發(fā)現(xiàn)絕對(duì)是繞不開(kāi)的一環(huán)。我這邊用的是 Consul 來(lái)做的服務(wù)注冊(cè)與發(fā)現(xiàn)從集群搭建到 Spring Cloud 集成完整跑了一遍期間踩了不少坑也把原理層面的東西摸了個(gè)七七八八。這篇就把我的實(shí)操過(guò)程和經(jīng)驗(yàn)整理出來(lái)給正準(zhǔn)備做服務(wù)發(fā)現(xiàn)、或者正在 Eureka、Nacos、Consul 之間糾結(jié)的團(tuán)隊(duì)一個(gè)參考。這篇文章會(huì)覆蓋這么幾個(gè)部分為什么需要服務(wù)發(fā)現(xiàn)、Consul 的核心原理與數(shù)據(jù)模型、單機(jī)和集群怎么搭、服務(wù)注冊(cè)和健康檢查怎么做、Spring Cloud 怎么集成最后還有我實(shí)際運(yùn)維中遇到的高頻問(wèn)題和排查思路。無(wú)論你是剛拆微服務(wù)的新手還是已經(jīng)在維護(hù)注冊(cè)中心的開(kāi)發(fā)這篇文章里應(yīng)該都有能直接拿去用的東西。1. 為什么微服務(wù)離不開(kāi)服務(wù)發(fā)現(xiàn)1.1 沒(méi)有注冊(cè)中心時(shí)服務(wù)調(diào)用有多痛苦先回到最原始的場(chǎng)景。假設(shè)你有一個(gè)訂單服務(wù)和一個(gè)用戶服務(wù)訂單服務(wù)要調(diào)用戶服務(wù)的接口。最笨的辦法就是配置里寫(xiě)死用戶服務(wù)的 IP 和端口比如http://192.168.1.10:8080。剛開(kāi)始實(shí)例少確實(shí)夠用。但一旦用戶服務(wù)部署了 3 個(gè)節(jié)點(diǎn)或者某臺(tái)機(jī)器掛了要縮容麻煩就來(lái)了你得手動(dòng)改配置、改 Nginx 上游、重新 reload而且掛掉的那個(gè)節(jié)點(diǎn) Nginx 并不知道照樣往里轉(zhuǎn)發(fā)流量線上就開(kāi)始零星報(bào)錯(cuò)。我見(jiàn)過(guò)不少團(tuán)隊(duì)在這個(gè)階段用 Nginx 做反向代理把服務(wù)地址統(tǒng)一收斂到 Nginx然后業(yè)務(wù)代碼只調(diào) Nginx。這比寫(xiě)死 IP 好一些但本質(zhì)上是把手動(dòng)改配置從業(yè)務(wù)代碼轉(zhuǎn)移到了 Nginx 配置實(shí)例變動(dòng)的通知依然靠人肉。一旦微服務(wù)規(guī)模上了兩位數(shù)每次發(fā)布、擴(kuò)容、故障轉(zhuǎn)移都要改一遍 Nginx運(yùn)維壓力非常大而且極易出錯(cuò)。這不是工具不好用而是思路錯(cuò)了。Nginx 適合做流量入口的負(fù)載均衡不適合做服務(wù)間動(dòng)態(tài)調(diào)用的注冊(cè)表。服務(wù)之間的調(diào)用關(guān)系是動(dòng)態(tài)的實(shí)例隨時(shí)在變必須有一個(gè)組件能實(shí)時(shí)記錄當(dāng)前有哪些服務(wù)、各自在哪個(gè)地址、是否健康并且把這個(gè)信息自動(dòng)同步給所有調(diào)用方。1.2 服務(wù)發(fā)現(xiàn)幫我們解決了哪三件事服務(wù)發(fā)現(xiàn)解決的核心問(wèn)題其實(shí)就三件事。第一件是服務(wù)注冊(cè)。服務(wù)啟動(dòng)時(shí)自動(dòng)把自己的 IP、端口、服務(wù)名、元數(shù)據(jù)信息上報(bào)給注冊(cè)中心。第二件是健康檢查。注冊(cè)中心定期探測(cè)服務(wù)的存活狀態(tài)發(fā)現(xiàn)實(shí)例不健康就自動(dòng)標(biāo)記、摘除不再把流量分給它。第三件是服務(wù)發(fā)現(xiàn)與負(fù)載均衡。調(diào)用方在發(fā)起請(qǐng)求前先向注冊(cè)中心拿一份可用實(shí)例列表然后按照負(fù)載均衡策略挑一個(gè)發(fā)起調(diào)用?？梢杂靡粋€(gè)生活化的類比來(lái)理解。你去一家熱門(mén)餐廳吃飯門(mén)口有個(gè)等位取號(hào)系統(tǒng)。你到了之后先取號(hào)這就是注冊(cè)系統(tǒng)會(huì)不斷喊號(hào)沒(méi)人應(yīng)答的就跳過(guò)這就是健康檢查輪到你的號(hào)時(shí)服務(wù)員帶你去空桌這就是發(fā)現(xiàn)與分配。如果沒(méi)有這個(gè)取號(hào)系統(tǒng)你就得挨個(gè)桌子問(wèn)有沒(méi)有空位效率極低而且很多桌子已經(jīng)坐滿了人你卻不知道。現(xiàn)在主流的注冊(cè)中心方案有 Consul、Nacos、Eureka、ZooKeeper 等。Eureka 2.x 已經(jīng)停止維護(hù)ZooKeeper 更偏向分布式協(xié)調(diào)場(chǎng)景。Nacos 在國(guó)內(nèi)用得多功能也很全自帶配置中心和注冊(cè)中心。我選擇 Consul 主要看中它的多數(shù)據(jù)中心支持、一致性協(xié)議更成熟、以及和 Spring Cloud 的集成度很高后面我會(huì)詳細(xì)講。2. Consul 服務(wù)發(fā)現(xiàn)的核心原理2.1 先認(rèn)識(shí) Consul 里的角色與端口Consul 是 HashiCorp 家的產(chǎn)品核心由 Agent 組成。Agent 有兩種運(yùn)行模式Server 模式和 Client 模式。Server 節(jié)點(diǎn)負(fù)責(zé)維護(hù)集群狀態(tài)、處理查詢和寫(xiě)入請(qǐng)求、參與 Raft 一致性協(xié)議選舉是 Consul 集群的大腦。生產(chǎn)環(huán)境一般部署 3 個(gè)或 5 個(gè) Server 節(jié)點(diǎn)必須是奇數(shù)因?yàn)?Raft 協(xié)議要求多數(shù)派才能提交數(shù)據(jù)。Client 模式則是一個(gè)輕量代理部署在每臺(tái)業(yè)務(wù)機(jī)器上負(fù)責(zé)轉(zhuǎn)發(fā)請(qǐng)求給 Server、執(zhí)行健康檢查、維護(hù)本機(jī)的服務(wù)注冊(cè)信息。業(yè)務(wù)進(jìn)程不直接和 Server 集群通信而是先找本機(jī) Client再由 Client 轉(zhuǎn)發(fā)這是一個(gè)很典型的分層設(shè)計(jì)。Consul 用到了幾個(gè)端口我用一張表整理了一下方便排查問(wèn)題的時(shí)候?qū)φ斩丝趨f(xié)議用途8500HTTP提供 REST API 和 Web UI服務(wù)注冊(cè)、查詢都走這里8600TCP/UDPDNS 接口可以通過(guò)域名解析服務(wù)地址8300TCPServer 節(jié)點(diǎn)之間的 RPC 通信8301TCP/UDP同數(shù)據(jù)中心內(nèi) Agent 間 gossip 通信LAN8302TCP/UDP跨數(shù)據(jù)中心 Agent 間 gossip 通信WAN我剛開(kāi)始部署的時(shí)候沒(méi)注意端口問(wèn)題結(jié)果集群起來(lái)之后成員之間一直互相看不到排查了半天才發(fā)現(xiàn)是防火墻把 8301 端口給攔了。如果你也遇到 Agent 日志里反復(fù)出現(xiàn) join 失敗優(yōu)先檢查這幾個(gè)端口是否放通。2.2 服務(wù)注冊(cè)與查詢的數(shù)據(jù)模型Consul 里最核心的數(shù)據(jù)模型是 Service。一個(gè)服務(wù)實(shí)例用下面幾個(gè)關(guān)鍵字段描述ID實(shí)例的唯一標(biāo)識(shí)同一個(gè)服務(wù)下不能重復(fù)Name服務(wù)名邏輯上的服務(wù)名稱Tags標(biāo)簽可以用來(lái)區(qū)分版本、環(huán)境等Address 和 Port實(shí)例的訪問(wèn)地址和端口Check健康檢查配置這里有個(gè)容易混淆的點(diǎn)Consul 的服務(wù)查詢接口有兩套/v1/catalog/service/{name}和/v1/health/service/{name}。前者返回的是注冊(cè)表里的原始數(shù)據(jù)不管實(shí)例是否健康都會(huì)返回后者只返回通過(guò)健康檢查的實(shí)例。實(shí)際調(diào)用的時(shí)候一定要用/v1/health/service/{name}否則你把流量打到一個(gè)已經(jīng)掛掉的實(shí)例上故障排查會(huì)非常痛苦。我自己在項(xiàng)目里就遇到過(guò)這樣的問(wèn)題服務(wù)調(diào)用的下游實(shí)例已經(jīng)宕機(jī)了但調(diào)用方還是能拿到它的地址。查了半天發(fā)現(xiàn)代碼里用的是 catalog 接口改成 health 接口之后掛掉的實(shí)例被自動(dòng)過(guò)濾掉問(wèn)題立刻消失。這個(gè)細(xì)節(jié)在 Consul 官方文檔里寫(xiě)得不算醒目但生產(chǎn)環(huán)境非常重要。2.3 三種健康檢查方式的選擇邏輯Consul 的健康檢查有三種模式適用場(chǎng)景完全不同很多人一開(kāi)始容易搞混。第一種是 HTTP 檢查。Consul 定期請(qǐng)求你指定的 HTTP 接口比如/actuator/health根據(jù)返回的 HTTP 狀態(tài)碼判斷是否健康。只要接口返回 200就認(rèn)為實(shí)例存活。這是我用得最多的一種因?yàn)?Spring Boot 的 Actuator 天然提供了健康檢查端點(diǎn)可以直接對(duì)接。第二種是 TCP 檢查。Consul 定期嘗試和實(shí)例的 IP:Port 建立 TCP 連接連得上就認(rèn)為健康。適合沒(méi)有 HTTP 接口的服務(wù)比如數(shù)據(jù)庫(kù)連接、自定義 RPC 服務(wù)。第三種是 TTL 檢查。服務(wù)實(shí)例自己定期主動(dòng)上報(bào)心跳告訴 Consul 我還活著。如果超過(guò)指定時(shí)間沒(méi)有上報(bào)就判定為不健康。這種模式下 Consul 不會(huì)主動(dòng)探測(cè)適合那些不方便提供 HTTP 端點(diǎn)、或者內(nèi)部有復(fù)雜存活判斷邏輯的服務(wù)。選擇邏輯其實(shí)很簡(jiǎn)單能用 HTTP 檢查就用 HTTP 檢查因?yàn)樗钪苯拥胤从沉朔?wù)的真實(shí)可用狀態(tài)服務(wù)本身沒(méi)有 HTTP 接口就用 TCP需要服務(wù)自己決定是否存活、或者不想讓注冊(cè)中心主動(dòng)探測(cè)的場(chǎng)景選 TTL。但要注意TTL 模式依賴業(yè)務(wù)代碼主動(dòng)上報(bào)心跳一旦業(yè)務(wù)線程卡死心跳可能還在發(fā)實(shí)際服務(wù)已經(jīng)不能處理請(qǐng)求了這會(huì)造成誤判所以能用 HTTP 檢查的地方我一般不會(huì)用 TTL。2.4 Consul 的一致性保證與多數(shù)據(jù)中心Consul 的 Server 節(jié)點(diǎn)采用 Raft 協(xié)議保證數(shù)據(jù)一致性。Raft 是一種分布式一致性算法核心思想是選舉一個(gè) Leader 節(jié)點(diǎn)負(fù)責(zé)處理寫(xiě)入請(qǐng)求其他節(jié)點(diǎn)同步數(shù)據(jù)。寫(xiě)入操作必須得到多數(shù)派節(jié)點(diǎn)確認(rèn)才算成功所以集群里掛掉的節(jié)點(diǎn)不能超過(guò)半數(shù)否則整個(gè)集群會(huì)變成只讀狀態(tài)服務(wù)注冊(cè)和更新都會(huì)失敗。這個(gè)機(jī)制保證了數(shù)據(jù)不會(huì)丟但也帶來(lái)一個(gè)運(yùn)維常識(shí)Consul 集群的 Server 節(jié)點(diǎn)數(shù)最好是 3 或 5不要因?yàn)楣?jié)省成本只部署 2 個(gè)因?yàn)?2 個(gè)節(jié)點(diǎn)掛 1 個(gè)就湊不齊多數(shù)派了連一臺(tái)都不掛反而不如單點(diǎn)穩(wěn)定。我后面會(huì)詳細(xì)演示 3 節(jié)點(diǎn)集群怎么搭。Consul 還支持多數(shù)據(jù)中心每個(gè)數(shù)據(jù)中心有獨(dú)立的 Server 集群數(shù)據(jù)中心之間通過(guò) WAN gossip 協(xié)議交換服務(wù)目錄信息。這一點(diǎn)在做異地多活或跨機(jī)房容災(zāi)時(shí)很有價(jià)值應(yīng)用層不需要感知物理機(jī)房的差異直接通過(guò)服務(wù)名就能拿到對(duì)端機(jī)房的可用實(shí)例。如果你的公司暫時(shí)沒(méi)有多機(jī)房需求這個(gè)功能可以先了解但選型時(shí)多一個(gè)加分項(xiàng)總是好的。3. 從零搭建 Consul 集群并完成服務(wù)注冊(cè)3.1 單機(jī)快速體驗(yàn)開(kāi)發(fā)模式先從最簡(jiǎn)單的單機(jī)模式開(kāi)始跑通了再上集群。Consul 的安裝很簡(jiǎn)單直接從官網(wǎng)下載二進(jìn)制包解壓后把可執(zhí)行文件放到 PATH 里就行。啟動(dòng)開(kāi)發(fā)模式consul agent -dev-dev模式會(huì)啟動(dòng)一個(gè)單節(jié)點(diǎn)的 Consul所有功能默認(rèn)開(kāi)啟非常適合本地調(diào)試。啟動(dòng)成功后打開(kāi)瀏覽器訪問(wèn)http://127.0.0.1:8500就能看到 Consul 的 Web UI。界面上有 Services、Nodes、ACL 等菜單服務(wù)注冊(cè)進(jìn)來(lái)后在 Services 頁(yè)面就能看到實(shí)例列表和健康狀態(tài)。開(kāi)發(fā)模式下如果提示端口被占用可以用-http-port指定其他端口。我做本地實(shí)驗(yàn)時(shí)常用consul agent -dev -http-port18500避開(kāi)可能被占用的 8500 端口。3.2 3 節(jié)點(diǎn)集群搭建實(shí)操生產(chǎn)環(huán)境我不會(huì)用單節(jié)點(diǎn)至少搭 3 個(gè) Server 節(jié)點(diǎn)的集群。這里演示在 3 臺(tái) Linux 服務(wù)器上搭建假設(shè)三臺(tái)機(jī)器的 IP 分別是 10.0.0.11、10.0.0.12、10.0.0.13。每臺(tái)機(jī)器上先準(zhǔn)備一個(gè)配置文件consul.hcl內(nèi)容大致如下data_dir /opt/consul/data log_level INFO server true bootstrap_expect 3 ui true bind_addr 0.0.0.0 client_addr 0.0.0.0 retry_join [10.0.0.11, 10.0.0.12, 10.0.0.13]然后依次在三臺(tái)機(jī)器上執(zhí)行consul agent -config-dir/etc/consul.d第一臺(tái)啟動(dòng)的時(shí)候因?yàn)閎ootstrap_expect 3Consul 會(huì)等待 3 個(gè) Server 節(jié)點(diǎn)都加入后才開(kāi)始選舉 Leader。這個(gè)參數(shù)的意思是期望的 Server 節(jié)點(diǎn)數(shù)用于避免過(guò)早選舉產(chǎn)生腦裂。等三臺(tái)機(jī)器全部啟動(dòng)后在任意一臺(tái)執(zhí)行consul members應(yīng)該能看到三個(gè)節(jié)點(diǎn)都是alive狀態(tài)。再執(zhí)行consul operator raft list-peers可以看到有一個(gè)節(jié)點(diǎn)是 leader其他節(jié)點(diǎn)是 followerRaft 集群正常工作了。這里有個(gè)經(jīng)驗(yàn)生產(chǎn)環(huán)境的 Server 節(jié)點(diǎn)最好是奇數(shù)3 個(gè)或 5 個(gè)。原因在 Raft 協(xié)議里說(shuō)過(guò)了要湊多數(shù)派。另外如果集群規(guī)模很大或者請(qǐng)求量很高還可以給 Server 節(jié)點(diǎn)前加一層負(fù)載均衡但一般的微服務(wù)規(guī)模用不到業(yè)務(wù)請(qǐng)求會(huì)優(yōu)先打到本機(jī)的 Client Agent再轉(zhuǎn)發(fā)給 Server壓力可控。3.3 通過(guò) REST API 注冊(cè)、查詢、注銷(xiāo)服務(wù)Consul 提供了完整的 REST API我先用 curl 演示最基礎(chǔ)的服務(wù)注冊(cè)流程。注冊(cè)一個(gè)名為user-service的服務(wù)實(shí)例到 Consulcurl -X PUT http://127.0.0.1:8500/v1/agent/service/register \ -H Content-Type: application/json \ -d { ID: user-service-1, Name: user-service, Tags: [primary], Address: 192.168.1.100, Port: 8080, Check: { HTTP: http://192.168.1.100:8080/actuator/health, Interval: 10s } }這里注意兩個(gè)細(xì)節(jié)。第一注冊(cè)接口是/v1/agent/service/register走的是本機(jī) Agent。第二Check 里的 HTTP 地址要填業(yè)務(wù)實(shí)例的地址不是 Consul 的地址Consul 會(huì)主動(dòng)去探測(cè)這個(gè)接口。注冊(cè)成功后在瀏覽器 UI 里能看到這個(gè)服務(wù)。查詢可用實(shí)例用 health 接口curl http://127.0.0.1:8500/v1/health/service/user-service返回結(jié)果里每個(gè)實(shí)例會(huì)帶一個(gè)Checks數(shù)組里面Status為passing的才是健康實(shí)例。服務(wù)下線時(shí)要調(diào)用注銷(xiāo)接口curl -X PUT http://127.0.0.1:8500/v1/agent/service/deregister/user-service-1這個(gè)接口是 Agent 級(jí)別的只注銷(xiāo)本機(jī) Agent 上注冊(cè)的這個(gè)實(shí)例。搞清楚 agent 和 catalog 兩套 API 的區(qū)別能避免很多誤操作。4. Spring Cloud 集成 Consul服務(wù)注冊(cè)與調(diào)用4.1 服務(wù)提供者注冊(cè)到 Consul手動(dòng)用 curl 注冊(cè)服務(wù)只是為了理解原理真實(shí)項(xiàng)目里不會(huì)這么干都是讓框架自動(dòng)完成。Spring Cloud 對(duì) Consul 的集成非常成熟我在 Spring Boot 2.x Spring Cloud 2021.0.x 環(huán)境下測(cè)試過(guò)步驟很簡(jiǎn)潔。在服務(wù)提供者項(xiàng)目里引入依賴dependency groupIdorg.springframework.cloud/groupId artifactIdspring-cloud-starter-consul-discovery/artifactId /dependency然后在application.yml里配置 Consul 地址和注冊(cè)信息spring: application: name: user-service cloud: consul: host: 127.0.0.1 port: 8500 discovery: instance-id: ${spring.application.name}-${spring.cloud.client.ip-address}-${server.port} prefer-ip-address: true health-check-path: /actuator/health health-check-interval: 10s主類上加上EnableDiscoveryClient注解SpringBootApplication EnableDiscoveryClient public class UserApplication { public static void main(String[] args) { SpringApplication.run(UserApplication.class, args); } }啟動(dòng)應(yīng)用后服務(wù)會(huì)自動(dòng)注冊(cè)到 Consul。這里instance-id的配置非常關(guān)鍵如果一臺(tái)機(jī)器上同一個(gè)服務(wù)部署了多個(gè)實(shí)例端口不同那么 ID 里帶上 IP 和端口就能保證唯一否則會(huì)出現(xiàn)后面的實(shí)例把前面的實(shí)例覆蓋掉的情況這是我在多實(shí)例部署時(shí)踩過(guò)的坑。prefer-ip-address: true會(huì)讓服務(wù)注冊(cè)時(shí)優(yōu)先使用 IP 而不是主機(jī)名。如果不開(kāi)這個(gè)配置在容器環(huán)境或內(nèi)網(wǎng) DNS 不完善的環(huán)境下注冊(cè)到 Consul 的地址可能是主機(jī)名其他服務(wù)解析不了調(diào)用就會(huì)失敗。4.2 服務(wù)消費(fèi)者通過(guò) Consul 找到并調(diào)用服務(wù)服務(wù)消費(fèi)者的配置和服務(wù)提供者幾乎一樣只是不注冊(cè)自身的情況更多。如果某個(gè)服務(wù)只是調(diào)用別人不需要被別人調(diào)用可以在配置里關(guān)閉注冊(cè)spring: cloud: consul: discovery: register: false調(diào)用方式有兩種主流方案。一種是 RestTemplate 加LoadBalanced注解Configuration public class RestTemplateConfig { Bean LoadBalanced public RestTemplate restTemplate() { return new RestTemplate(); } }然后直接通過(guò)服務(wù)名調(diào)用String result restTemplate.getForObject(http://user-service/api/user/1, String.class);另一種是用 OpenFeign聲明式調(diào)用更符合微服務(wù)的風(fēng)格FeignClient(name user-service) public interface UserClient { GetMapping(/api/user/{id}) String getUser(PathVariable(id) Long id); }這兩套方式底層的原理是一樣的攔截到服務(wù)名后向 Consul 查詢可用實(shí)例列表再用負(fù)載均衡策略選一個(gè)實(shí)例發(fā)起請(qǐng)求。Spring Cloud LoadBalancer 默認(rèn)的負(fù)載均衡策略是輪詢你也可以根據(jù)自己的需求替換成隨機(jī)、最少連接數(shù)等策略。我第一次用 RestTemplate 調(diào)服務(wù)名時(shí)報(bào)了UnknownHostException原因就是忘加LoadBalanced注解。這個(gè)注解的作用是給 RestTemplate 注入一個(gè)攔截器讓它能識(shí)別http://user-service這種服務(wù)名格式并走服務(wù)發(fā)現(xiàn)邏輯。沒(méi)有這個(gè)注解RestTemplate 只會(huì)把它當(dāng)普通域名去 DNS 解析自然就失敗了。4.3 健康檢查、優(yōu)雅下線與自動(dòng)摘除Spring Cloud Consul 默認(rèn)的健康檢查路徑就是/actuator/health但前提是項(xiàng)目里引入了 Spring Boot Actuator。如果沒(méi)引入健康檢查請(qǐng)求會(huì)返回 404Consul 會(huì)把實(shí)例標(biāo)記為不健康。所以一定要在服務(wù)提供者項(xiàng)目里加上dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-actuator/artifactId /dependencyhealth-check-interval: 10s表示每 10 秒檢查一次。這個(gè)值不要設(shè)得太短否則頻率太高會(huì)浪費(fèi)不必要的資源也不要設(shè)得太長(zhǎng)否則實(shí)例掛了之后下游最長(zhǎng)要等一個(gè)周期才能感知到。10 秒是我覺(jué)得比較平衡的配置如果對(duì)時(shí)效性要求高可以壓到 5 秒。還有一個(gè)很實(shí)用的配置是deregister-critical-service-after。當(dāng)健康檢查連續(xù)失敗實(shí)例進(jìn)入 critical 狀態(tài)后如果超過(guò)這個(gè)時(shí)間還沒(méi)有恢復(fù)Consul 會(huì)自動(dòng)把實(shí)例從注冊(cè)表里刪除spring: cloud: consul: discovery: deregister-critical-service-after: 2m這個(gè)配置我強(qiáng)烈建議加上否則一個(gè)實(shí)例掛了之后它的記錄會(huì)一直躺在 Consul 服務(wù)列表里UI 上看著紅叉一片數(shù)據(jù)也不干凈。加了這個(gè)配置后Consul 會(huì)在 2 分鐘后自動(dòng)清理。優(yōu)雅下線方面Spring Cloud 在應(yīng)用關(guān)閉時(shí)會(huì)自動(dòng)從 Consul 注銷(xiāo)服務(wù)實(shí)例不需要額外寫(xiě)代碼。但如果你用的是容器編排系統(tǒng)比如 Kubernetes 或 Docker Compose要注意關(guān)閉順序。先讓 Consul 把實(shí)例標(biāo)記為不健康并停止接收新流量再真正銷(xiāo)毀容器這樣才能做到滾動(dòng)發(fā)布無(wú)感知。單純依賴進(jìn)程退出時(shí)的注銷(xiāo)邏輯在容器被強(qiáng)殺時(shí)往往來(lái)不及執(zhí)行。5. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄5.1 服務(wù)列表里看不到服務(wù)這個(gè)是最常見(jiàn)的問(wèn)題排查思路從簡(jiǎn)單到復(fù)雜排開(kāi)先看 Consul UI 的 Services 頁(yè)面確認(rèn)服務(wù)有沒(méi)有注冊(cè)成功再看服務(wù)提供者的啟動(dòng)日志有沒(méi)有報(bào)錯(cuò)然后用curl http://127.0.0.1:8500/v1/agent/services查看本機(jī) Agent 上注冊(cè)的服務(wù)列表。一個(gè)容易被忽略的原因是配置的spring.cloud.consul.host指向了錯(cuò)誤的機(jī)器或者端口不是 8500。另外檢查服務(wù)提供者和 Consul 之間的網(wǎng)絡(luò)連通性在服務(wù)提供者所在機(jī)器上直接執(zhí)行telnet {consul_host} 8500如果端口不通說(shuō)明網(wǎng)絡(luò)層面有問(wèn)題。踩過(guò)的一個(gè)隱蔽坑是服務(wù)注冊(cè)請(qǐng)求確實(shí)發(fā)出去了但注冊(cè)到 Consul 的地址是內(nèi)網(wǎng) Docker 網(wǎng)段的 IP比如172.17.0.2其他機(jī)器訪問(wèn)不了。這就是沒(méi)有配prefer-ip-address: true或者容器網(wǎng)絡(luò)配置不當(dāng)造成的。解決方法是配置spring: cloud: consul: discovery: prefer-ip-address: true ip-address: 宿主機(jī)對(duì)外IP # 可選手動(dòng)指定注冊(cè)IP5.2 控制臺(tái)健康狀態(tài)紅叉但服務(wù)本身正常服務(wù)進(jìn)程明明還在跑接口也能通但 Consul UI 里顯示健康檢查失敗。這時(shí)候先看 Consul 配置的健康檢查路徑是什么再手動(dòng)在 Consul 所在機(jī)器上 curl 一下這個(gè)地址。如果是/actuator/health返回 404說(shuō)明服務(wù)提供者沒(méi)引入 Actuator或者 context-path 配置導(dǎo)致路徑不對(duì)。Spring Boot 如果設(shè)置了server.servlet.context-path/api那么健康檢查端點(diǎn)也會(huì)跟著變化Consul 配置里的health-check-path也要改成/api/actuator/health。還有一種情況是健康檢查返回了 200但檢查頻率太高把服務(wù)打掛了表現(xiàn)就是服務(wù)偶爾可用偶爾不可用。我有一次把 interval 配成了 1 秒結(jié)果 Consul 集群對(duì)每個(gè)實(shí)例每秒發(fā)一個(gè)請(qǐng)求業(yè)務(wù)高峰期把服務(wù)拖得很慢。后來(lái)調(diào)整為 10 秒一切正常。健康檢查的頻率不是越高越好還是一個(gè)平衡問(wèn)題。5.3 服務(wù)實(shí)例被自動(dòng)摘除后反復(fù)重連如果實(shí)例處于不太健康的狀態(tài)Consul 會(huì)標(biāo)記為 critical然后deregister-critical-service-after時(shí)間一到就刪除注冊(cè)信息。但服務(wù)端的 Spring Cloud Consul 組件有自動(dòng)重連機(jī)制會(huì)嘗試重新注冊(cè)于是在 UI 上看到的現(xiàn)象就是服務(wù)一直在注冊(cè)、刪除、注冊(cè)、刪除之間反復(fù)橫跳。這種情況下核心問(wèn)題是實(shí)例本身不穩(wěn)定可能是內(nèi)存溢出、數(shù)據(jù)庫(kù)連接池耗盡、或者磁盤(pán)滿了。先去查服務(wù)日志和健康檢查端點(diǎn)的返回內(nèi)容Actuator 的/actuator/health返回體里會(huì)帶上各組件的健康狀態(tài)比如 MySQL 連接、Redis、磁盤(pán)空間等能直接指出是哪一個(gè)組件出了問(wèn)題。5.4 集群出現(xiàn)腦裂或不可寫(xiě)Consul 集群的 Server 節(jié)點(diǎn)網(wǎng)絡(luò)發(fā)生分區(qū)時(shí)Raft 協(xié)議會(huì)觸發(fā)重新選舉。如果某個(gè)分區(qū)的節(jié)點(diǎn)數(shù)湊不齊多數(shù)派這個(gè)分區(qū)就不可寫(xiě)服務(wù)注冊(cè)和更新都會(huì)失敗。這不是 Consul 的 bug而是 Raft 為防止腦裂寫(xiě)的固有機(jī)制。排查方法是登錄 Server 節(jié)點(diǎn)執(zhí)行consul operator raft list-peers查看 Raft 狀態(tài)。如果 leader 一直在切換或者沒(méi)有 leader說(shuō)明節(jié)點(diǎn)間網(wǎng)絡(luò)不穩(wěn)定檢查 8300 端口連通性和機(jī)房之間的專線質(zhì)量。另一個(gè)常見(jiàn)原因是服務(wù)器時(shí)鐘偏差太大Raft 對(duì)時(shí)鐘一致性有要求生產(chǎn)環(huán)境務(wù)必配置好 NTP 時(shí)間同步。5.5 服務(wù)下線時(shí)沒(méi)有及時(shí)清空進(jìn)程被 kill 之后服務(wù)實(shí)例在 Consul 里還會(huì)存在一段時(shí)間直到健康檢查連續(xù)失敗后才被標(biāo)記為 critical再等到deregister-critical-service-after觸發(fā)才被清理。這是正?，F(xiàn)象但如果是主動(dòng)發(fā)布最好在發(fā)布腳本里先調(diào)用注銷(xiāo)接口把實(shí)例從 Consul 里摘掉再停進(jìn)程。寫(xiě)一個(gè)簡(jiǎn)單的下線腳本#!/bin/bash SERVICE_IDuser-service-192.168.1.100-8080 curl -X PUT http://127.0.0.1:8500/v1/agent/service/deregister/${SERVICE_ID} kill -TERM $(pgrep -f user-service)這里調(diào)的還是本機(jī) Agent 的接口所以腳本在服務(wù)提供者機(jī)器上執(zhí)行即可。結(jié)合 CI/CD 流水線在停止容器前先執(zhí)行這個(gè)下線步驟可以讓發(fā)布期間下游調(diào)用方始終只訪問(wèn)存活實(shí)例真正實(shí)現(xiàn)無(wú)感發(fā)布。6. 一點(diǎn)擴(kuò)展ACL 安全與配置中心玩法6.1 別忽略 ACL 安全Consul 老版本曝出過(guò)一些安全漏洞大多和 ACL 權(quán)限校驗(yàn)繞過(guò)有關(guān)。如果只是在內(nèi)網(wǎng)跑很多人會(huì)忽略安全配置但微服務(wù)架構(gòu)里注冊(cè)中心掌握著所有服務(wù)的地址一旦被入侵整個(gè)系統(tǒng)的調(diào)用拓?fù)渚捅┞读孙L(fēng)險(xiǎn)非常高。Consul 支持完整的 ACL 系統(tǒng)可以為不同的服務(wù)、Key 配置細(xì)粒度的讀寫(xiě)權(quán)限。簡(jiǎn)單做法是啟用 ACLacl { enabled true default_policy deny tokens { master your-bootstrap-token } }開(kāi)啟后所有 API 請(qǐng)求都需要帶 Token 頭。Spring Cloud 的 Consul 集成也支持配置 Tokenspring: cloud: consul: config: acl-token: your-token discovery: acl-token: your-token我的建議是即使內(nèi)網(wǎng)環(huán)境也把 ACL 開(kāi)啟至少做個(gè)基礎(chǔ)防護(hù)。同時(shí)盡量使用較新版本的 Consul官方修復(fù)安全漏洞后在 release note 里都有記錄及時(shí)升級(jí)比什么防護(hù)都管用。6.2 Consul 還能當(dāng)輕量配置中心用Consul 的內(nèi)置 KV 存儲(chǔ)除了支撐服務(wù)發(fā)現(xiàn)也可以直接用做配置中心。雖然沒(méi)有 Nacos 的命名空間、分組、灰度這些豐富功能但對(duì)中小團(tuán)隊(duì)來(lái)說(shuō)夠用。Spring Cloud Consul Config 的接入方式和 Nacos 類似。引入依賴dependency groupIdorg.springframework.cloud/groupId artifactIdspring-cloud-starter-consul-config/artifactId /dependency配置里指定 KV 路徑spring: cloud: consul: config: enabled: true prefixes: config default-context: application然后在 Consul 的 KV 里創(chuàng)建config/user-service/data這樣的路徑存放配置文件內(nèi)容。配合spring-cloud-starter-bus可以實(shí)現(xiàn)配置變更后的自動(dòng)刷新。不過(guò)要提醒一句Consul 的 KV 功能適合存一些簡(jiǎn)單的、變更頻率不高的配置。如果配置項(xiàng)特別多、需要分環(huán)境分團(tuán)隊(duì)管理、需要灰度發(fā)布還是用 Nacos 或者 Apollo 這類專業(yè)配置中心更合適。選型要看團(tuán)隊(duì)體量沒(méi)有銀彈。我在實(shí)際使用中最深的一個(gè)體會(huì)是服務(wù)發(fā)現(xiàn)這塊選哪個(gè)注冊(cè)中心不是最難的難的是把健康檢查、優(yōu)雅上下線、負(fù)載均衡這些細(xì)節(jié)真正落實(shí)到生產(chǎn)環(huán)境里。很多人項(xiàng)目跑起來(lái)看著一切正常等到發(fā)布日才發(fā)現(xiàn)流量打到了正在關(guān)停的實(shí)例上或者服務(wù)擴(kuò)容后新實(shí)例遲遲沒(méi)有被下游感知到。這些坑大多不是注冊(cè)中心本身的問(wèn)題而是配置和使用姿勢(shì)的問(wèn)題。希望這篇文章能讓你在搭服務(wù)發(fā)現(xiàn)的時(shí)候少走些彎路。最后再分享一個(gè)小習(xí)慣無(wú)論用 Consul 還是其他注冊(cè)中心上線前一定要把“實(shí)例下線 - 健康檢查失敗 - 自動(dòng)摘除”這條鏈路完整演練一遍確認(rèn)每個(gè)環(huán)節(jié)的時(shí)間都符合預(yù)期。這個(gè)流程順暢了線上發(fā)布和故障處理會(huì)省去很多麻煩。 微服務(wù)服務(wù)發(fā)現(xiàn)與Consul實(shí)戰(zhàn)：注冊(cè)中心原理到Spring Cloud集成
做微服務(wù)這段時(shí)間被問(wèn)得最多的問(wèn)題之一就是服務(wù)之間到底是怎么找到彼此的IP 寫(xiě)死不就行了嘛短期可以服務(wù)一多、實(shí)例一變、一擴(kuò)縮容馬上就會(huì)亂成一鍋粥。這也是為什么現(xiàn)在只要聊到微服務(wù)架構(gòu)服務(wù)發(fā)現(xiàn)絕對(duì)是繞不開(kāi)的一環(huán)。我這邊用的是 Consul 來(lái)做的服務(wù)注冊(cè)與發(fā)現(xiàn)從集群搭建到 Spring Cloud 集成完整跑了一遍期間踩了不少坑也把原理層面的東西摸了個(gè)七七八八。這篇就把我的實(shí)操過(guò)程和經(jīng)驗(yàn)整理出來(lái)給正準(zhǔn)備做服務(wù)發(fā)現(xiàn)、或者正在 Eureka、Nacos、Consul 之間糾結(jié)的團(tuán)隊(duì)一個(gè)參考。這篇文章會(huì)覆蓋這么幾個(gè)部分為什么需要服務(wù)發(fā)現(xiàn)、Consul 的核心原理與數(shù)據(jù)模型、單機(jī)和集群怎么搭、服務(wù)注冊(cè)和健康檢查怎么做、Spring Cloud 怎么集成最后還有我實(shí)際運(yùn)維中遇到的高頻問(wèn)題和排查思路。無(wú)論你是剛拆微服務(wù)的新手還是已經(jīng)在維護(hù)注冊(cè)中心的開(kāi)發(fā)這篇文章里應(yīng)該都有能直接拿去用的東西。1. 為什么微服務(wù)離不開(kāi)服務(wù)發(fā)現(xiàn)1.1 沒(méi)有注冊(cè)中心時(shí)服務(wù)調(diào)用有多痛苦先回到最原始的場(chǎng)景。假設(shè)你有一個(gè)訂單服務(wù)和一個(gè)用戶服務(wù)訂單服務(wù)要調(diào)用戶服務(wù)的接口。最笨的辦法就是配置里寫(xiě)死用戶服務(wù)的 IP 和端口比如http://192.168.1.10:8080。剛開(kāi)始實(shí)例少確實(shí)夠用。但一旦用戶服務(wù)部署了 3 個(gè)節(jié)點(diǎn)或者某臺(tái)機(jī)器掛了要縮容麻煩就來(lái)了你得手動(dòng)改配置、改 Nginx 上游、重新 reload而且掛掉的那個(gè)節(jié)點(diǎn) Nginx 并不知道照樣往里轉(zhuǎn)發(fā)流量線上就開(kāi)始零星報(bào)錯(cuò)。我見(jiàn)過(guò)不少團(tuán)隊(duì)在這個(gè)階段用 Nginx 做反向代理把服務(wù)地址統(tǒng)一收斂到 Nginx然后業(yè)務(wù)代碼只調(diào) Nginx。這比寫(xiě)死 IP 好一些但本質(zhì)上是把手動(dòng)改配置從業(yè)務(wù)代碼轉(zhuǎn)移到了 Nginx 配置實(shí)例變動(dòng)的通知依然靠人肉。一旦微服務(wù)規(guī)模上了兩位數(shù)每次發(fā)布、擴(kuò)容、故障轉(zhuǎn)移都要改一遍 Nginx運(yùn)維壓力非常大而且極易出錯(cuò)。這不是工具不好用而是思路錯(cuò)了。Nginx 適合做流量入口的負(fù)載均衡不適合做服務(wù)間動(dòng)態(tài)調(diào)用的注冊(cè)表。服務(wù)之間的調(diào)用關(guān)系是動(dòng)態(tài)的實(shí)例隨時(shí)在變必須有一個(gè)組件能實(shí)時(shí)記錄當(dāng)前有哪些服務(wù)、各自在哪個(gè)地址、是否健康并且把這個(gè)信息自動(dòng)同步給所有調(diào)用方。1.2 服務(wù)發(fā)現(xiàn)幫我們解決了哪三件事服務(wù)發(fā)現(xiàn)解決的核心問(wèn)題其實(shí)就三件事。第一件是服務(wù)注冊(cè)。服務(wù)啟動(dòng)時(shí)自動(dòng)把自己的 IP、端口、服務(wù)名、元數(shù)據(jù)信息上報(bào)給注冊(cè)中心。第二件是健康檢查。注冊(cè)中心定期探測(cè)服務(wù)的存活狀態(tài)發(fā)現(xiàn)實(shí)例不健康就自動(dòng)標(biāo)記、摘除不再把流量分給它。第三件是服務(wù)發(fā)現(xiàn)與負(fù)載均衡。調(diào)用方在發(fā)起請(qǐng)求前先向注冊(cè)中心拿一份可用實(shí)例列表然后按照負(fù)載均衡策略挑一個(gè)發(fā)起調(diào)用?？梢杂靡粋€(gè)生活化的類比來(lái)理解。你去一家熱門(mén)餐廳吃飯門(mén)口有個(gè)等位取號(hào)系統(tǒng)。你到了之后先取號(hào)這就是注冊(cè)系統(tǒng)會(huì)不斷喊號(hào)沒(méi)人應(yīng)答的就跳過(guò)這就是健康檢查輪到你的號(hào)時(shí)服務(wù)員帶你去空桌這就是發(fā)現(xiàn)與分配。如果沒(méi)有這個(gè)取號(hào)系統(tǒng)你就得挨個(gè)桌子問(wèn)有沒(méi)有空位效率極低而且很多桌子已經(jīng)坐滿了人你卻不知道。現(xiàn)在主流的注冊(cè)中心方案有 Consul、Nacos、Eureka、ZooKeeper 等。Eureka 2.x 已經(jīng)停止維護(hù)ZooKeeper 更偏向分布式協(xié)調(diào)場(chǎng)景。Nacos 在國(guó)內(nèi)用得多功能也很全自帶配置中心和注冊(cè)中心。我選擇 Consul 主要看中它的多數(shù)據(jù)中心支持、一致性協(xié)議更成熟、以及和 Spring Cloud 的集成度很高后面我會(huì)詳細(xì)講。2. Consul 服務(wù)發(fā)現(xiàn)的核心原理2.1 先認(rèn)識(shí) Consul 里的角色與端口Consul 是 HashiCorp 家的產(chǎn)品核心由 Agent 組成。Agent 有兩種運(yùn)行模式Server 模式和 Client 模式。Server 節(jié)點(diǎn)負(fù)責(zé)維護(hù)集群狀態(tài)、處理查詢和寫(xiě)入請(qǐng)求、參與 Raft 一致性協(xié)議選舉是 Consul 集群的大腦。生產(chǎn)環(huán)境一般部署 3 個(gè)或 5 個(gè) Server 節(jié)點(diǎn)必須是奇數(shù)因?yàn)?Raft 協(xié)議要求多數(shù)派才能提交數(shù)據(jù)。Client 模式則是一個(gè)輕量代理部署在每臺(tái)業(yè)務(wù)機(jī)器上負(fù)責(zé)轉(zhuǎn)發(fā)請(qǐng)求給 Server、執(zhí)行健康檢查、維護(hù)本機(jī)的服務(wù)注冊(cè)信息。業(yè)務(wù)進(jìn)程不直接和 Server 集群通信而是先找本機(jī) Client再由 Client 轉(zhuǎn)發(fā)這是一個(gè)很典型的分層設(shè)計(jì)。Consul 用到了幾個(gè)端口我用一張表整理了一下方便排查問(wèn)題的時(shí)候?qū)φ斩丝趨f(xié)議用途8500HTTP提供 REST API 和 Web UI服務(wù)注冊(cè)、查詢都走這里8600TCP/UDPDNS 接口可以通過(guò)域名解析服務(wù)地址8300TCPServer 節(jié)點(diǎn)之間的 RPC 通信8301TCP/UDP同數(shù)據(jù)中心內(nèi) Agent 間 gossip 通信LAN8302TCP/UDP跨數(shù)據(jù)中心 Agent 間 gossip 通信WAN我剛開(kāi)始部署的時(shí)候沒(méi)注意端口問(wèn)題結(jié)果集群起來(lái)之后成員之間一直互相看不到排查了半天才發(fā)現(xiàn)是防火墻把 8301 端口給攔了。如果你也遇到 Agent 日志里反復(fù)出現(xiàn) join 失敗優(yōu)先檢查這幾個(gè)端口是否放通。2.2 服務(wù)注冊(cè)與查詢的數(shù)據(jù)模型Consul 里最核心的數(shù)據(jù)模型是 Service。一個(gè)服務(wù)實(shí)例用下面幾個(gè)關(guān)鍵字段描述ID實(shí)例的唯一標(biāo)識(shí)同一個(gè)服務(wù)下不能重復(fù)Name服務(wù)名邏輯上的服務(wù)名稱Tags標(biāo)簽可以用來(lái)區(qū)分版本、環(huán)境等Address 和 Port實(shí)例的訪問(wèn)地址和端口Check健康檢查配置這里有個(gè)容易混淆的點(diǎn)Consul 的服務(wù)查詢接口有兩套/v1/catalog/service/{name}和/v1/health/service/{name}。前者返回的是注冊(cè)表里的原始數(shù)據(jù)不管實(shí)例是否健康都會(huì)返回后者只返回通過(guò)健康檢查的實(shí)例。實(shí)際調(diào)用的時(shí)候一定要用/v1/health/service/{name}否則你把流量打到一個(gè)已經(jīng)掛掉的實(shí)例上故障排查會(huì)非常痛苦。我自己在項(xiàng)目里就遇到過(guò)這樣的問(wèn)題服務(wù)調(diào)用的下游實(shí)例已經(jīng)宕機(jī)了但調(diào)用方還是能拿到它的地址。查了半天發(fā)現(xiàn)代碼里用的是 catalog 接口改成 health 接口之后掛掉的實(shí)例被自動(dòng)過(guò)濾掉問(wèn)題立刻消失。這個(gè)細(xì)節(jié)在 Consul 官方文檔里寫(xiě)得不算醒目但生產(chǎn)環(huán)境非常重要。2.3 三種健康檢查方式的選擇邏輯Consul 的健康檢查有三種模式適用場(chǎng)景完全不同很多人一開(kāi)始容易搞混。第一種是 HTTP 檢查。Consul 定期請(qǐng)求你指定的 HTTP 接口比如/actuator/health根據(jù)返回的 HTTP 狀態(tài)碼判斷是否健康。只要接口返回 200就認(rèn)為實(shí)例存活。這是我用得最多的一種因?yàn)?Spring Boot 的 Actuator 天然提供了健康檢查端點(diǎn)可以直接對(duì)接。第二種是 TCP 檢查。Consul 定期嘗試和實(shí)例的 IP:Port 建立 TCP 連接連得上就認(rèn)為健康。適合沒(méi)有 HTTP 接口的服務(wù)比如數(shù)據(jù)庫(kù)連接、自定義 RPC 服務(wù)。第三種是 TTL 檢查。服務(wù)實(shí)例自己定期主動(dòng)上報(bào)心跳告訴 Consul 我還活著。如果超過(guò)指定時(shí)間沒(méi)有上報(bào)就判定為不健康。這種模式下 Consul 不會(huì)主動(dòng)探測(cè)適合那些不方便提供 HTTP 端點(diǎn)、或者內(nèi)部有復(fù)雜存活判斷邏輯的服務(wù)。選擇邏輯其實(shí)很簡(jiǎn)單能用 HTTP 檢查就用 HTTP 檢查因?yàn)樗钪苯拥胤从沉朔?wù)的真實(shí)可用狀態(tài)服務(wù)本身沒(méi)有 HTTP 接口就用 TCP需要服務(wù)自己決定是否存活、或者不想讓注冊(cè)中心主動(dòng)探測(cè)的場(chǎng)景選 TTL。但要注意TTL 模式依賴業(yè)務(wù)代碼主動(dòng)上報(bào)心跳一旦業(yè)務(wù)線程卡死心跳可能還在發(fā)實(shí)際服務(wù)已經(jīng)不能處理請(qǐng)求了這會(huì)造成誤判所以能用 HTTP 檢查的地方我一般不會(huì)用 TTL。2.4 Consul 的一致性保證與多數(shù)據(jù)中心Consul 的 Server 節(jié)點(diǎn)采用 Raft 協(xié)議保證數(shù)據(jù)一致性。Raft 是一種分布式一致性算法核心思想是選舉一個(gè) Leader 節(jié)點(diǎn)負(fù)責(zé)處理寫(xiě)入請(qǐng)求其他節(jié)點(diǎn)同步數(shù)據(jù)。寫(xiě)入操作必須得到多數(shù)派節(jié)點(diǎn)確認(rèn)才算成功所以集群里掛掉的節(jié)點(diǎn)不能超過(guò)半數(shù)否則整個(gè)集群會(huì)變成只讀狀態(tài)服務(wù)注冊(cè)和更新都會(huì)失敗。這個(gè)機(jī)制保證了數(shù)據(jù)不會(huì)丟但也帶來(lái)一個(gè)運(yùn)維常識(shí)Consul 集群的 Server 節(jié)點(diǎn)數(shù)最好是 3 或 5不要因?yàn)楣?jié)省成本只部署 2 個(gè)因?yàn)?2 個(gè)節(jié)點(diǎn)掛 1 個(gè)就湊不齊多數(shù)派了連一臺(tái)都不掛反而不如單點(diǎn)穩(wěn)定。我后面會(huì)詳細(xì)演示 3 節(jié)點(diǎn)集群怎么搭。Consul 還支持多數(shù)據(jù)中心每個(gè)數(shù)據(jù)中心有獨(dú)立的 Server 集群數(shù)據(jù)中心之間通過(guò) WAN gossip 協(xié)議交換服務(wù)目錄信息。這一點(diǎn)在做異地多活或跨機(jī)房容災(zāi)時(shí)很有價(jià)值應(yīng)用層不需要感知物理機(jī)房的差異直接通過(guò)服務(wù)名就能拿到對(duì)端機(jī)房的可用實(shí)例。如果你的公司暫時(shí)沒(méi)有多機(jī)房需求這個(gè)功能可以先了解但選型時(shí)多一個(gè)加分項(xiàng)總是好的。3. 從零搭建 Consul 集群并完成服務(wù)注冊(cè)3.1 單機(jī)快速體驗(yàn)開(kāi)發(fā)模式先從最簡(jiǎn)單的單機(jī)模式開(kāi)始跑通了再上集群。Consul 的安裝很簡(jiǎn)單直接從官網(wǎng)下載二進(jìn)制包解壓后把可執(zhí)行文件放到 PATH 里就行。啟動(dòng)開(kāi)發(fā)模式consul agent -dev-dev模式會(huì)啟動(dòng)一個(gè)單節(jié)點(diǎn)的 Consul所有功能默認(rèn)開(kāi)啟非常適合本地調(diào)試。啟動(dòng)成功后打開(kāi)瀏覽器訪問(wèn)http://127.0.0.1:8500就能看到 Consul 的 Web UI。界面上有 Services、Nodes、ACL 等菜單服務(wù)注冊(cè)進(jìn)來(lái)后在 Services 頁(yè)面就能看到實(shí)例列表和健康狀態(tài)。開(kāi)發(fā)模式下如果提示端口被占用可以用-http-port指定其他端口。我做本地實(shí)驗(yàn)時(shí)常用consul agent -dev -http-port18500避開(kāi)可能被占用的 8500 端口。3.2 3 節(jié)點(diǎn)集群搭建實(shí)操生產(chǎn)環(huán)境我不會(huì)用單節(jié)點(diǎn)至少搭 3 個(gè) Server 節(jié)點(diǎn)的集群。這里演示在 3 臺(tái) Linux 服務(wù)器上搭建假設(shè)三臺(tái)機(jī)器的 IP 分別是 10.0.0.11、10.0.0.12、10.0.0.13。每臺(tái)機(jī)器上先準(zhǔn)備一個(gè)配置文件consul.hcl內(nèi)容大致如下data_dir /opt/consul/data log_level INFO server true bootstrap_expect 3 ui true bind_addr 0.0.0.0 client_addr 0.0.0.0 retry_join [10.0.0.11, 10.0.0.12, 10.0.0.13]然后依次在三臺(tái)機(jī)器上執(zhí)行consul agent -config-dir/etc/consul.d第一臺(tái)啟動(dòng)的時(shí)候因?yàn)閎ootstrap_expect 3Consul 會(huì)等待 3 個(gè) Server 節(jié)點(diǎn)都加入后才開(kāi)始選舉 Leader。這個(gè)參數(shù)的意思是期望的 Server 節(jié)點(diǎn)數(shù)用于避免過(guò)早選舉產(chǎn)生腦裂。等三臺(tái)機(jī)器全部啟動(dòng)后在任意一臺(tái)執(zhí)行consul members應(yīng)該能看到三個(gè)節(jié)點(diǎn)都是alive狀態(tài)。再執(zhí)行consul operator raft list-peers可以看到有一個(gè)節(jié)點(diǎn)是 leader其他節(jié)點(diǎn)是 followerRaft 集群正常工作了。這里有個(gè)經(jīng)驗(yàn)生產(chǎn)環(huán)境的 Server 節(jié)點(diǎn)最好是奇數(shù)3 個(gè)或 5 個(gè)。原因在 Raft 協(xié)議里說(shuō)過(guò)了要湊多數(shù)派。另外如果集群規(guī)模很大或者請(qǐng)求量很高還可以給 Server 節(jié)點(diǎn)前加一層負(fù)載均衡但一般的微服務(wù)規(guī)模用不到業(yè)務(wù)請(qǐng)求會(huì)優(yōu)先打到本機(jī)的 Client Agent再轉(zhuǎn)發(fā)給 Server壓力可控。3.3 通過(guò) REST API 注冊(cè)、查詢、注銷(xiāo)服務(wù)Consul 提供了完整的 REST API我先用 curl 演示最基礎(chǔ)的服務(wù)注冊(cè)流程。注冊(cè)一個(gè)名為user-service的服務(wù)實(shí)例到 Consulcurl -X PUT http://127.0.0.1:8500/v1/agent/service/register \ -H Content-Type: application/json \ -d { ID: user-service-1, Name: user-service, Tags: [primary], Address: 192.168.1.100, Port: 8080, Check: { HTTP: http://192.168.1.100:8080/actuator/health, Interval: 10s } }這里注意兩個(gè)細(xì)節(jié)。第一注冊(cè)接口是/v1/agent/service/register走的是本機(jī) Agent。第二Check 里的 HTTP 地址要填業(yè)務(wù)實(shí)例的地址不是 Consul 的地址Consul 會(huì)主動(dòng)去探測(cè)這個(gè)接口。注冊(cè)成功后在瀏覽器 UI 里能看到這個(gè)服務(wù)。查詢可用實(shí)例用 health 接口curl http://127.0.0.1:8500/v1/health/service/user-service返回結(jié)果里每個(gè)實(shí)例會(huì)帶一個(gè)Checks數(shù)組里面Status為passing的才是健康實(shí)例。服務(wù)下線時(shí)要調(diào)用注銷(xiāo)接口curl -X PUT http://127.0.0.1:8500/v1/agent/service/deregister/user-service-1這個(gè)接口是 Agent 級(jí)別的只注銷(xiāo)本機(jī) Agent 上注冊(cè)的這個(gè)實(shí)例。搞清楚 agent 和 catalog 兩套 API 的區(qū)別能避免很多誤操作。4. Spring Cloud 集成 Consul服務(wù)注冊(cè)與調(diào)用4.1 服務(wù)提供者注冊(cè)到 Consul手動(dòng)用 curl 注冊(cè)服務(wù)只是為了理解原理真實(shí)項(xiàng)目里不會(huì)這么干都是讓框架自動(dòng)完成。Spring Cloud 對(duì) Consul 的集成非常成熟我在 Spring Boot 2.x Spring Cloud 2021.0.x 環(huán)境下測(cè)試過(guò)步驟很簡(jiǎn)潔。在服務(wù)提供者項(xiàng)目里引入依賴dependency groupIdorg.springframework.cloud/groupId artifactIdspring-cloud-starter-consul-discovery/artifactId /dependency然后在application.yml里配置 Consul 地址和注冊(cè)信息spring: application: name: user-service cloud: consul: host: 127.0.0.1 port: 8500 discovery: instance-id: ${spring.application.name}-${spring.cloud.client.ip-address}-${server.port} prefer-ip-address: true health-check-path: /actuator/health health-check-interval: 10s主類上加上EnableDiscoveryClient注解SpringBootApplication EnableDiscoveryClient public class UserApplication { public static void main(String[] args) { SpringApplication.run(UserApplication.class, args); } }啟動(dòng)應(yīng)用后服務(wù)會(huì)自動(dòng)注冊(cè)到 Consul。這里instance-id的配置非常關(guān)鍵如果一臺(tái)機(jī)器上同一個(gè)服務(wù)部署了多個(gè)實(shí)例端口不同那么 ID 里帶上 IP 和端口就能保證唯一否則會(huì)出現(xiàn)后面的實(shí)例把前面的實(shí)例覆蓋掉的情況這是我在多實(shí)例部署時(shí)踩過(guò)的坑。prefer-ip-address: true會(huì)讓服務(wù)注冊(cè)時(shí)優(yōu)先使用 IP 而不是主機(jī)名。如果不開(kāi)這個(gè)配置在容器環(huán)境或內(nèi)網(wǎng) DNS 不完善的環(huán)境下注冊(cè)到 Consul 的地址可能是主機(jī)名其他服務(wù)解析不了調(diào)用就會(huì)失敗。4.2 服務(wù)消費(fèi)者通過(guò) Consul 找到并調(diào)用服務(wù)服務(wù)消費(fèi)者的配置和服務(wù)提供者幾乎一樣只是不注冊(cè)自身的情況更多。如果某個(gè)服務(wù)只是調(diào)用別人不需要被別人調(diào)用可以在配置里關(guān)閉注冊(cè)spring: cloud: consul: discovery: register: false調(diào)用方式有兩種主流方案。一種是 RestTemplate 加LoadBalanced注解Configuration public class RestTemplateConfig { Bean LoadBalanced public RestTemplate restTemplate() { return new RestTemplate(); } }然后直接通過(guò)服務(wù)名調(diào)用String result restTemplate.getForObject(http://user-service/api/user/1, String.class);另一種是用 OpenFeign聲明式調(diào)用更符合微服務(wù)的風(fēng)格FeignClient(name user-service) public interface UserClient { GetMapping(/api/user/{id}) String getUser(PathVariable(id) Long id); }這兩套方式底層的原理是一樣的攔截到服務(wù)名后向 Consul 查詢可用實(shí)例列表再用負(fù)載均衡策略選一個(gè)實(shí)例發(fā)起請(qǐng)求。Spring Cloud LoadBalancer 默認(rèn)的負(fù)載均衡策略是輪詢你也可以根據(jù)自己的需求替換成隨機(jī)、最少連接數(shù)等策略。我第一次用 RestTemplate 調(diào)服務(wù)名時(shí)報(bào)了UnknownHostException原因就是忘加LoadBalanced注解。這個(gè)注解的作用是給 RestTemplate 注入一個(gè)攔截器讓它能識(shí)別http://user-service這種服務(wù)名格式并走服務(wù)發(fā)現(xiàn)邏輯。沒(méi)有這個(gè)注解RestTemplate 只會(huì)把它當(dāng)普通域名去 DNS 解析自然就失敗了。4.3 健康檢查、優(yōu)雅下線與自動(dòng)摘除Spring Cloud Consul 默認(rèn)的健康檢查路徑就是/actuator/health但前提是項(xiàng)目里引入了 Spring Boot Actuator。如果沒(méi)引入健康檢查請(qǐng)求會(huì)返回 404Consul 會(huì)把實(shí)例標(biāo)記為不健康。所以一定要在服務(wù)提供者項(xiàng)目里加上dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-actuator/artifactId /dependencyhealth-check-interval: 10s表示每 10 秒檢查一次。這個(gè)值不要設(shè)得太短否則頻率太高會(huì)浪費(fèi)不必要的資源也不要設(shè)得太長(zhǎng)否則實(shí)例掛了之后下游最長(zhǎng)要等一個(gè)周期才能感知到。10 秒是我覺(jué)得比較平衡的配置如果對(duì)時(shí)效性要求高可以壓到 5 秒。還有一個(gè)很實(shí)用的配置是deregister-critical-service-after。當(dāng)健康檢查連續(xù)失敗實(shí)例進(jìn)入 critical 狀態(tài)后如果超過(guò)這個(gè)時(shí)間還沒(méi)有恢復(fù)Consul 會(huì)自動(dòng)把實(shí)例從注冊(cè)表里刪除spring: cloud: consul: discovery: deregister-critical-service-after: 2m這個(gè)配置我強(qiáng)烈建議加上否則一個(gè)實(shí)例掛了之后它的記錄會(huì)一直躺在 Consul 服務(wù)列表里UI 上看著紅叉一片數(shù)據(jù)也不干凈。加了這個(gè)配置后Consul 會(huì)在 2 分鐘后自動(dòng)清理。優(yōu)雅下線方面Spring Cloud 在應(yīng)用關(guān)閉時(shí)會(huì)自動(dòng)從 Consul 注銷(xiāo)服務(wù)實(shí)例不需要額外寫(xiě)代碼。但如果你用的是容器編排系統(tǒng)比如 Kubernetes 或 Docker Compose要注意關(guān)閉順序。先讓 Consul 把實(shí)例標(biāo)記為不健康并停止接收新流量再真正銷(xiāo)毀容器這樣才能做到滾動(dòng)發(fā)布無(wú)感知。單純依賴進(jìn)程退出時(shí)的注銷(xiāo)邏輯在容器被強(qiáng)殺時(shí)往往來(lái)不及執(zhí)行。5. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄5.1 服務(wù)列表里看不到服務(wù)這個(gè)是最常見(jiàn)的問(wèn)題排查思路從簡(jiǎn)單到復(fù)雜排開(kāi)先看 Consul UI 的 Services 頁(yè)面確認(rèn)服務(wù)有沒(méi)有注冊(cè)成功再看服務(wù)提供者的啟動(dòng)日志有沒(méi)有報(bào)錯(cuò)然后用curl http://127.0.0.1:8500/v1/agent/services查看本機(jī) Agent 上注冊(cè)的服務(wù)列表。一個(gè)容易被忽略的原因是配置的spring.cloud.consul.host指向了錯(cuò)誤的機(jī)器或者端口不是 8500。另外檢查服務(wù)提供者和 Consul 之間的網(wǎng)絡(luò)連通性在服務(wù)提供者所在機(jī)器上直接執(zhí)行telnet {consul_host} 8500如果端口不通說(shuō)明網(wǎng)絡(luò)層面有問(wèn)題。踩過(guò)的一個(gè)隱蔽坑是服務(wù)注冊(cè)請(qǐng)求確實(shí)發(fā)出去了但注冊(cè)到 Consul 的地址是內(nèi)網(wǎng) Docker 網(wǎng)段的 IP比如172.17.0.2其他機(jī)器訪問(wèn)不了。這就是沒(méi)有配prefer-ip-address: true或者容器網(wǎng)絡(luò)配置不當(dāng)造成的。解決方法是配置spring: cloud: consul: discovery: prefer-ip-address: true ip-address: 宿主機(jī)對(duì)外IP # 可選手動(dòng)指定注冊(cè)IP5.2 控制臺(tái)健康狀態(tài)紅叉但服務(wù)本身正常服務(wù)進(jìn)程明明還在跑接口也能通但 Consul UI 里顯示健康檢查失敗。這時(shí)候先看 Consul 配置的健康檢查路徑是什么再手動(dòng)在 Consul 所在機(jī)器上 curl 一下這個(gè)地址。如果是/actuator/health返回 404說(shuō)明服務(wù)提供者沒(méi)引入 Actuator或者 context-path 配置導(dǎo)致路徑不對(duì)。Spring Boot 如果設(shè)置了server.servlet.context-path/api那么健康檢查端點(diǎn)也會(huì)跟著變化Consul 配置里的health-check-path也要改成/api/actuator/health。還有一種情況是健康檢查返回了 200但檢查頻率太高把服務(wù)打掛了表現(xiàn)就是服務(wù)偶爾可用偶爾不可用。我有一次把 interval 配成了 1 秒結(jié)果 Consul 集群對(duì)每個(gè)實(shí)例每秒發(fā)一個(gè)請(qǐng)求業(yè)務(wù)高峰期把服務(wù)拖得很慢。后來(lái)調(diào)整為 10 秒一切正常。健康檢查的頻率不是越高越好還是一個(gè)平衡問(wèn)題。5.3 服務(wù)實(shí)例被自動(dòng)摘除后反復(fù)重連如果實(shí)例處于不太健康的狀態(tài)Consul 會(huì)標(biāo)記為 critical然后deregister-critical-service-after時(shí)間一到就刪除注冊(cè)信息。但服務(wù)端的 Spring Cloud Consul 組件有自動(dòng)重連機(jī)制會(huì)嘗試重新注冊(cè)于是在 UI 上看到的現(xiàn)象就是服務(wù)一直在注冊(cè)、刪除、注冊(cè)、刪除之間反復(fù)橫跳。這種情況下核心問(wèn)題是實(shí)例本身不穩(wěn)定可能是內(nèi)存溢出、數(shù)據(jù)庫(kù)連接池耗盡、或者磁盤(pán)滿了。先去查服務(wù)日志和健康檢查端點(diǎn)的返回內(nèi)容Actuator 的/actuator/health返回體里會(huì)帶上各組件的健康狀態(tài)比如 MySQL 連接、Redis、磁盤(pán)空間等能直接指出是哪一個(gè)組件出了問(wèn)題。5.4 集群出現(xiàn)腦裂或不可寫(xiě)Consul 集群的 Server 節(jié)點(diǎn)網(wǎng)絡(luò)發(fā)生分區(qū)時(shí)Raft 協(xié)議會(huì)觸發(fā)重新選舉。如果某個(gè)分區(qū)的節(jié)點(diǎn)數(shù)湊不齊多數(shù)派這個(gè)分區(qū)就不可寫(xiě)服務(wù)注冊(cè)和更新都會(huì)失敗。這不是 Consul 的 bug而是 Raft 為防止腦裂寫(xiě)的固有機(jī)制。排查方法是登錄 Server 節(jié)點(diǎn)執(zhí)行consul operator raft list-peers查看 Raft 狀態(tài)。如果 leader 一直在切換或者沒(méi)有 leader說(shuō)明節(jié)點(diǎn)間網(wǎng)絡(luò)不穩(wěn)定檢查 8300 端口連通性和機(jī)房之間的專線質(zhì)量。另一個(gè)常見(jiàn)原因是服務(wù)器時(shí)鐘偏差太大Raft 對(duì)時(shí)鐘一致性有要求生產(chǎn)環(huán)境務(wù)必配置好 NTP 時(shí)間同步。5.5 服務(wù)下線時(shí)沒(méi)有及時(shí)清空進(jìn)程被 kill 之后服務(wù)實(shí)例在 Consul 里還會(huì)存在一段時(shí)間直到健康檢查連續(xù)失敗后才被標(biāo)記為 critical再等到deregister-critical-service-after觸發(fā)才被清理。這是正?，F(xiàn)象但如果是主動(dòng)發(fā)布最好在發(fā)布腳本里先調(diào)用注銷(xiāo)接口把實(shí)例從 Consul 里摘掉再停進(jìn)程。寫(xiě)一個(gè)簡(jiǎn)單的下線腳本#!/bin/bash SERVICE_IDuser-service-192.168.1.100-8080 curl -X PUT http://127.0.0.1:8500/v1/agent/service/deregister/${SERVICE_ID} kill -TERM $(pgrep -f user-service)這里調(diào)的還是本機(jī) Agent 的接口所以腳本在服務(wù)提供者機(jī)器上執(zhí)行即可。結(jié)合 CI/CD 流水線在停止容器前先執(zhí)行這個(gè)下線步驟可以讓發(fā)布期間下游調(diào)用方始終只訪問(wèn)存活實(shí)例真正實(shí)現(xiàn)無(wú)感發(fā)布。6. 一點(diǎn)擴(kuò)展ACL 安全與配置中心玩法6.1 別忽略 ACL 安全Consul 老版本曝出過(guò)一些安全漏洞大多和 ACL 權(quán)限校驗(yàn)繞過(guò)有關(guān)。如果只是在內(nèi)網(wǎng)跑很多人會(huì)忽略安全配置但微服務(wù)架構(gòu)里注冊(cè)中心掌握著所有服務(wù)的地址一旦被入侵整個(gè)系統(tǒng)的調(diào)用拓?fù)渚捅┞读孙L(fēng)險(xiǎn)非常高。Consul 支持完整的 ACL 系統(tǒng)可以為不同的服務(wù)、Key 配置細(xì)粒度的讀寫(xiě)權(quán)限。簡(jiǎn)單做法是啟用 ACLacl { enabled true default_policy deny tokens { master your-bootstrap-token } }開(kāi)啟后所有 API 請(qǐng)求都需要帶 Token 頭。Spring Cloud 的 Consul 集成也支持配置 Tokenspring: cloud: consul: config: acl-token: your-token discovery: acl-token: your-token我的建議是即使內(nèi)網(wǎng)環(huán)境也把 ACL 開(kāi)啟至少做個(gè)基礎(chǔ)防護(hù)。同時(shí)盡量使用較新版本的 Consul官方修復(fù)安全漏洞后在 release note 里都有記錄及時(shí)升級(jí)比什么防護(hù)都管用。6.2 Consul 還能當(dāng)輕量配置中心用Consul 的內(nèi)置 KV 存儲(chǔ)除了支撐服務(wù)發(fā)現(xiàn)也可以直接用做配置中心。雖然沒(méi)有 Nacos 的命名空間、分組、灰度這些豐富功能但對(duì)中小團(tuán)隊(duì)來(lái)說(shuō)夠用。Spring Cloud Consul Config 的接入方式和 Nacos 類似。引入依賴dependency groupIdorg.springframework.cloud/groupId artifactIdspring-cloud-starter-consul-config/artifactId /dependency配置里指定 KV 路徑spring: cloud: consul: config: enabled: true prefixes: config default-context: application然后在 Consul 的 KV 里創(chuàng)建config/user-service/data這樣的路徑存放配置文件內(nèi)容。配合spring-cloud-starter-bus可以實(shí)現(xiàn)配置變更后的自動(dòng)刷新。不過(guò)要提醒一句Consul 的 KV 功能適合存一些簡(jiǎn)單的、變更頻率不高的配置。如果配置項(xiàng)特別多、需要分環(huán)境分團(tuán)隊(duì)管理、需要灰度發(fā)布還是用 Nacos 或者 Apollo 這類專業(yè)配置中心更合適。選型要看團(tuán)隊(duì)體量沒(méi)有銀彈。我在實(shí)際使用中最深的一個(gè)體會(huì)是服務(wù)發(fā)現(xiàn)這塊選哪個(gè)注冊(cè)中心不是最難的難的是把健康檢查、優(yōu)雅上下線、負(fù)載均衡這些細(xì)節(jié)真正落實(shí)到生產(chǎn)環(huán)境里。很多人項(xiàng)目跑起來(lái)看著一切正常等到發(fā)布日才發(fā)現(xiàn)流量打到了正在關(guān)停的實(shí)例上或者服務(wù)擴(kuò)容后新實(shí)例遲遲沒(méi)有被下游感知到。這些坑大多不是注冊(cè)中心本身的問(wèn)題而是配置和使用姿勢(shì)的問(wèn)題。希望這篇文章能讓你在搭服務(wù)發(fā)現(xiàn)的時(shí)候少走些彎路。最后再分享一個(gè)小習(xí)慣無(wú)論用 Consul 還是其他注冊(cè)中心上線前一定要把“實(shí)例下線 - 健康檢查失敗 - 自動(dòng)摘除”這條鏈路完整演練一遍確認(rèn)每個(gè)環(huán)節(jié)的時(shí)間都符合預(yù)期。這個(gè)流程順暢了線上發(fā)布和故障處理會(huì)省去很多麻煩。