由于微服務(wù)應(yīng)用的動態(tài)性，很難調(diào)用具有固定 IP 地址的服務(wù)。這就是服務(wù)發(fā)現(xiàn)的概念出現(xiàn)的背景。服務(wù)發(fā)現(xiàn)有助于客戶端了解服務(wù)實例的位置。在這種情況下，服務(wù)發(fā)現(xiàn)組件將充當服務(wù)注冊表。

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

在服務(wù)發(fā)現(xiàn)中，有兩種模式。

• 客戶端端服務(wù)發(fā)現(xiàn)
• 服務(wù)器端服務(wù)發(fā)現(xiàn)

客戶端端服務(wù)發(fā)現(xiàn)

這涉及多個步驟。

圖 01 — 客戶端端服務(wù)發(fā)現(xiàn)

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

自注冊模式

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

服務(wù)實例可能會調(diào)用服務(wù)注冊表的注冊 API 來注冊其網(wǎng)絡(luò)位置。除此之外，服務(wù)注冊表還會調(diào)用服務(wù)提供者實例的健康檢查 API。

模式 2：服務(wù)器端服務(wù)發(fā)現(xiàn)模式

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

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

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

圖 02 — 服務(wù)器端服務(wù)發(fā)現(xiàn)模式

這涉及多個步驟：

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

第三方注冊模式

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