由于微服務應用的動態性，很難調用具有固定 IP 地址的服務。這就是服務發現的概念出現的背景。服務發現有助于客戶端了解服務實例的位置。在這種情況下，服務發現組件將充當服務注冊表。

服務注冊表是一個包含服務實例位置的集中式服務器/數據庫。在微服務設置中，服務會定期更新其在服務注冊表中的位置。然后服務使用者可以連接到服務注冊表并獲取這些服務的位置。Netflix Eureka 是一種流行的“應用級”開源服務注冊表。

在服務發現中，有兩種模式。

• 客戶端端服務發現
• 服務器端服務發現

客戶端端服務發現

這涉及多個步驟。

圖 01 — 客戶端端服務發現

• 將服務提供者實例的位置添加到服務注冊表(自注冊模式)。
• 當服務消費者想要請求特定服務時，服務發現機制將查詢服務注冊表以獲取可用服務提供者實例位置的列表。
• 在從服務注冊表中獲取位置列表后，將其發送回服務消費者。
• 最后，服務消費者將路由服務請求到其中一個服務提供者實例。

自注冊模式

在自注冊模式中，服務實例會在啟動時向服務注冊表注冊自己（見圖 01 — 步驟 01）。這會在服務注冊表上發生，并且在關閉時取消注冊。

服務實例可能會調用服務注冊表的注冊 API 來注冊其網絡位置。除此之外，服務注冊表還會調用服務提供者實例的健康檢查 API。

模式 2：服務器端服務發現模式

與客戶端端服務發現模式不同，服務器端服務發現模式中，服務客戶端會發出對 DNS 名稱的請求，該名稱會解析為查詢服務注冊表并負載均衡請求的平臺請求路由器。

這種模式的主要優點是，與客戶端端發現模式不同，服務發現的所有方面都完全由部署平臺處理。這對于任何開發方來說都是一個主要優勢和一個無憂無慮的方法。部署平臺（例如 Kubernetes）具有內置的服務注冊表和服務發現機制，以覆蓋服務器端發現模式。

這種方法的唯一限制是，您會稍微耦合到用于服務注冊表的部署平臺上。例如，如果您使用 Kubernetes 作為部署平臺，那么您基本上與 Kubernetes 耦合，以用于服務發現。如果您的其他服務組件也在 Kubernetes 上運行，這將不是問題。然而，如今大多數部署都在云原生 Kubernetes 容器化環境中進行，這不是一個主要限制。

圖 02 — 服務器端服務發現模式

這涉及多個步驟：

• 服務實例通過 registrar（第三方注冊模式）向服務注冊表注冊。
• 服務客戶端從 Router 獲取服務網絡位置，并 Router 從服務注冊表查詢請求。
• 然后 Router 從可用的服務提供者實例中負載均衡請求。

第三方注冊模式

在第三方注冊模式（見圖 02 — 步驟 02）中，與服務注冊表的自注冊不同，一個稱為 registrar 的第三方負責注冊。