我建議你閱讀 Alexander Sigachev 的報告《分散式系統中的服務發現》的文字記錄，以 Consul 為例。
創建服務發現的目的是為了讓您能夠以最低的成本將新應用程式連接到我們現有的環境。 使用服務發現，我們可以最大程度地將 docker 容器或虛擬服務與其運行的環境分開。
我歡迎大家！ 我是 Alexander Sigachev，在 Inventos 工作。 今天我要跟大家介紹一個服務發現這樣一個概念。 讓我們以 Consul 為例來看看服務發現。
服務發現解決什麼問題？ 創建服務發現的目的是為了讓您能夠以最低的成本將新應用程式連接到我們現有的環境。 使用服務發現，我們可以最大程度地將 docker 容器或虛擬服務與其運行的環境分開。
它是什麼樣子的？ 在網路上的一個經典範例中，這是接受使用者請求的前端。 然後它將其路由到後端。 在此範例中，此負載平衡器平衡兩個後端。
在這裡我們看到我們正在啟動應用程式的第三個實例。 因此，當應用程式啟動時，它會向服務發現註冊。 服務發現通知負載平衡器。 負載平衡器自動變更其配置，新的後端投入運作。 透過這種方式，可以添加後端，或者相反，從工作中排除後端。
服務發現還有哪些方便的用途？ 服務發現可以儲存 nginx 設定、憑證和活動後端伺服器清單。
服務發現還允許您檢測故障並檢測故障。 檢測故障的可能方案有哪些？
- 我們開發的這個應用程式會自動通知服務發現它仍然有效。
- 服務發現本身會輪詢應用程式的可用性。
- 或者，我們使用第三方腳本或應用程式來檢查我們的應用程式的可用性，並通知服務發現一切都很好並且可以工作，或者相反，一切都不好並且需要從平衡中排除該應用程式實例。
每個方案的使用取決於我們使用的軟體。 例如，我們剛開始開發一個新項目，那麼當我們的應用程式通知服務發現時，我們可以輕鬆地提供一個方案。 或者我們可以連接服務發現正在檢查。
如果我們繼承了應用程式或由其他人開發了應用程序，那麼當我們編寫處理程序時，第三種選擇是合適的，所有這些都會自動進入我們的工作。
這是一個例子。 nginx 形式的負載平衡器被重新啟動。 這是 Consul 提供的可選實用程式。 這是領事模板。 我們描述該規則。 我們說我們正在使用模板（Golang Template Engine）。 當事件發生時，當發生變更的通知時，它會重新生成，並將「重新載入」命令傳送到服務發現。 最簡單的例子是當 nginx 透過事件重新配置並重新啟動時。
什麼是領事？
-
首先，這是服務發現。
-
它有一個可用性檢查機制——健康檢查。
-
它還有一個 KV 商店。
-
它基於使用多個數據中心的能力。
這一切能用來做什麼？ 在 KV Store 中我們可以儲存範例配置。 健康檢查我們可以檢查本地服務並通知。 使用多資料中心，可以建立服務地圖。 例如，亞馬遜擁有多個區域，並以最佳方式路由流量，以便資料中心之間不會產生不必要的請求，這些請求與本地流量分開計費，因此延遲更短。
讓我們了解一下 Consul 中使用的術語。
- Consul 是一個用 Go 寫的服務。 Go 程式的優點之一是您只需下載 1 個二進位。 從任何地方啟動，您沒有任何依賴項。
- 然後，使用這些金鑰，我們可以在客戶端模式或伺服器模式下啟動該服務。
- 此外，「datacenter」屬性可讓您設定該伺服器屬於哪個資料中心的標誌。
- 共識——基於raft協議。 如果有人有興趣，您可以在 Consul 網站上閱讀更多相關資訊。 這是一個協議，可讓您確定領導者並確定哪些資金被認為是有效且可訪問的。
- Gossip 是一種支援節點之間互動的協定。 此外，該系統是分散的。 在一個資料中心內，所有節點都與其鄰居進行通訊。 並且，相應地，有關當前狀態的資訊被相互傳輸。 可以說，這是鄰居之間的閒話。
- LAN Gossip – 同一資料中心內的鄰居之間的本地資料交換。
- WAN Gossip - 當我們需要在兩個資料中心之間同步資訊時使用。 資訊在標記為伺服器的節點之間流動。
- RPC – 允許您透過伺服器上的客戶端執行請求。
RPC 的描述。 假設 Consul 作為客戶端在虛擬機器或實體伺服器上運行。 我們在當地聯繫他。 然後本地客戶端向伺服器請求資訊並進行同步。 根據設置，資訊可以從本地快取中檢索，也可以與領導者、伺服器主控同步。
這兩種方案各有利弊。 如果我們使用本地緩存，那麼速度會很快。 如果我們處理儲存在伺服器上的數據，則需要更長的時間，但我們會獲得更多相關資訊。
如果您以圖形方式描述這一點，那麼這就是該網站的圖片。 我們看到有三個master正在運行。 其中一個標有星號作為領導者。 在此範例中，有三個用戶端透過 UDP/TCP 在本地相互交換資訊。 並且資料中心之間的資訊在伺服器之間傳輸。 在這裡，客戶可以在本地進行互動。
Consul提供什麼API？ 為了獲取訊息，Consul 有兩種類型的 API。
這是 DNS API。 預設情況下，Consul 在連接埠 8600 上運行。 我們可以配置請求代理並透過本機 DNS 進行本機解析來提供存取。 我們可以按網域查詢並接收回應中的IP位址資訊。
HTTP API - 或者我們可以在連接埠 8500 上本機請求有關特定服務的資訊並接收 JSON 回應，伺服器有什麼 IP、什麼主機、註冊什麼連接埠。 並且可以透過令牌傳輸附加資訊。
運行 Consul 需要什麼？
在第一個選項中，在開發人員模式下，我們指示這是開發人員模式的標誌。 代理作為伺服器啟動。 它在一台機器上獨立執行整個功能。 方便、快捷，首次啟動幾乎無需額外設定。
第二種模式是在生產中啟動。 這就是啟動變得有點複雜的地方。 如果我們沒有任何版本的consul，那麼我們必須將第一台機器帶入bootstrap，也就是這台機器，它將承擔領導者的職責。 我們提出它，然後我們提出伺服器的第二個實例，向它傳遞我們的主伺服器所在位置的資訊。 我們提出第三個。 當我們啟動三台機器後，我們在第一台機器上從正在運行的引導程式中以正常模式重新啟動它。 資料已同步，初始叢集已啟動。
建議在伺服器模式下運行三到七個實例。 這是因為，如果伺服器數量增加，那麼它們之間同步資訊的時間就會增加。 節點數必須為奇數以保證法定人數。
如何提供健康檢查？ 我們在Consul配置目錄下以Json的形式編寫驗證規則。 第一個選項是本範例中 google.com 網域的可用性。 我們說這個檢查需要每隔30秒進行一次。 這樣我們就可以檢查我們的節點是否可以存取外部網路。
第二個選擇是檢查自己。 我們使用常規的curl以10秒的間隔在指定連接埠上呼叫localhost。
這些檢查會被匯總並發送給服務發現。 根據可用性，這些節點要么被排除，要么出現在可用且正常工作的電腦的清單中。
Consul還提供了一個UI介面，該介面以單獨的標誌啟動，並將在機器上可用。 這允許您查看訊息，也可以進行一些更改。
在此範例中，「服務」標籤已開啟。 可以看到有XNUMX個服務正在運行，其中之一就是Consul。 執行的檢查次數。 這些機器位於三個資料中心。
這是“節點”選項卡的範例。 我們看到它們有涉及資料中心的複合名稱。 它還顯示哪些服務正在運行，即我們看到沒有設定標籤。 這些附加標籤可以提供一些信息，開發人員可以使用這些資訊來指定附加參數。
您也可以向 Consul 傳輸有關磁碟狀態和平均負載的資訊。
問題
問題：我們有一個 docker 容器，如何與 Consul 一起使用它？
答：docker容器有多種實作方式。 最常見的一種是使用第三方 docker 容器負責註冊。 啟動時，會向其傳遞一個 docker 套接字。 所有容器註冊和取消發布事件都記錄在 Consul 中。
問題：那Consul自己啟動docker容器？
答：不。 我們正在運行一個 docker 容器。 在配置時，我們指示 - 監聽這樣那樣的套接字。 這與我們使用憑證的方式大致相同，即上傳有關我們擁有的位置和內容的資訊。
問題：事實證明，我們嘗試連接到 Service Discovery 的 Docker 容器內部應該有某種可以將資料傳送到 Consul 的邏輯？
答：不是真的。 當它啟動時，我們會透過環境變數傳遞變數。 比如說服務名稱、服務埠。 暫存器監聽該資訊並將其輸入Consul。
問題：我還有一個關於 UI 的問題。 例如，我們將 UI 部署在生產伺服器上。 安全性怎麼樣？ 資料儲存在哪裡？ 是否有可能以某種方式累積數據？
答：在 UI 中，有來自資料庫和服務發現的資料。 我們自己在設定中設定密碼。
Q：這個可以在網路上發佈嗎？
答：預設情況下，Consul 在 localhost 上啟動。 要在互聯網上發布，您需要安裝某種代理。 我們對自己的安全規則負責。
Q：它是否提供開箱即用的歷史資料？ 查看健康檢查的統計數據很有趣。 如果伺服器經常發生故障，您也可以診斷問題。
答：我不確定那裡有支票的詳細資料。
Q：當前的狀態並不像動態那麼重要。
答案：用於分析——是的。
問題：Consul docker 最好不要使用服務發現？
答：我不建議使用它。 報告的目的是要介紹這樣一個概念是如何存在的。 從歷史上看，我認為它已經發展到了第一個版本。 現在有更完整的解決方案，例如 Kubernetes，它在幕後擁有這一切。 作為 Kubernetes 的一部分，服務發現不如 Etcd。 但我對它並不像對Consul那麼熟悉。 因此，我決定以Consul為例進行服務發現。
Q：帶有leader伺服器的方案會不會降低整個應用程式的啟動速度？ 如果領事說謊，他如何確定新的領導者呢？
答：他們有一個完整的協議描述。 如果您有興趣，可以閱讀。
問題：Consul 充當我們的成熟伺服器，所有請求都透過它進行？
答：它不充當完整的伺服器，而是接管特定區域。 它通常以 service.consul 結尾。 然後我們按邏輯繼續前進。 我們在生產中不使用域名，而是使用內部基礎設施，如果我們使用 DNS，則內部基礎設施通常隱藏在伺服器快取後面。
問題：也就是說，如果我們要存取一個資料庫，那麼無論如何我們都會先拉Consul來找到這個資料庫，對嗎？
答：是的。 如果我們使用 DNS，那麼當我們使用 DNS 名稱時，它的運作方式與沒有 Consul 時的工作方式相同。 通常，現代應用程式不會在每個請求中提取域名，因為我們安裝了 connect，一切正常，並且在不久的將來我們實際上不會使用它。 如果連接中斷，那麼是的，我們會再次詢問我們的基地在哪裡並前往那裡。
— Hashicorp 用戶聊天：Consul、Nomad、Terraform
PS關於健康檢查。 Consul 與 Kubernetes 一樣，使用相同的系統根據程式碼狀態檢查服務的生存狀態。
200 OK for healthy
503 Service Unavailable for unhealthy來源：
來源： www.habr.com