在我們服務使用 REST API 調用服務時，是需要知道服務實例的網絡位置（IP 地址和端口）。

在服務器上運行的傳統應用程序中服務實例的api通常是靜態的。在現在基于云的微服務應用程序中，api通常不是那么簡單設置。由于自動縮放、故障和升級，服務實例會動態變化。因此，我們必須在客戶端代碼中使用服務發現。

1、服務發現

服務的IP地址不能在客戶端靜態配置。需要使用動態服務發現。從概念上講，服務發現非常簡單，它的主要組件是一個服務注冊表，它包含一個應用程序服務實例的網絡位置列表。

當服務實例啟動和停止時，服務注冊表會更新。服務發現機制通過查詢服務注冊表以獲取可用服務實例的列表，并在客戶端調用服務時將請求路由到其中一個。

2、應用程序級服務發現模式

應用程序的服務及其客戶端可以與服務注冊中心交互以實現服務發現。每個服務實例向服務注冊表注冊其網絡位置，在調用服務之前從服務注冊中心請求服務實例列表。然后，客戶端向其中一個實例發送請求。

這種方法是兩種模式的組合。

• 自注冊模式：在啟動期間，服務實例調用注冊中心的注冊 API 來注冊其網絡位置，注冊中心要求服務實例定期調用心跳 API 以防止其注冊過期。當服務實例關閉時，它會從服務注冊表中注銷自己。
• 客戶端發現模式：為了調用服務，服務客戶端向服務注冊中心查詢服務實例列表。客戶端使用負載平衡算法來選擇服務實例，然后由客戶端請求選定的實例。

Netflix 和 Pivotal 已經普及了企業級服務發現。例如，Netflix 的 Eureka 是一個高可用的服務注冊中心。Netflix 組件可以很容易地與 Spring Cloud 一起使用，這是一個由 Pivotal 開發的基于 Spring 的框架。基于 Spring Cloud 的服務向 Eureka 注冊，基于 Spring Cloud 的客戶端使用 Eureka 發現服務。

3、應用層服務發現的缺點

• 需要特定語言的服務發現庫。
• 需要運維人員維護設置和管理服務注冊表。
• 當服務實例正在運行但不處理請求時，會出現從服務注冊中心遺漏注銷的可行性。

4、平臺提供的服務發現模式

許多部署平臺例如 Docker 和 Kubernetes，都內置了服務注冊表和服務發現機制。每個服務都分配有一個 DNS 名稱、一個虛擬 IP (VIP) 地址和一個解析為 VIP 地址的 DNS 名稱。

服務客戶端請求 DNS 名稱/VIP，部署平臺自動將請求路由到可用服務實例。這樣服務注冊、服務發現、請求路由等全部由部署平臺處理。服務注冊表跟蹤部署平臺中已部署服務的 IP 地址。

這種方法是兩種模式的組合：

• 第 三 方注冊模式：不是服務向服務注冊中心注冊自己，而是由第三方注冊商（通常是部署平臺的一部分）進行注冊。注冊器在啟動時向服務注冊中心注冊服務實例。當實例關閉時，注冊器會從服務注冊表中取消注冊服務實例。
• 服務器端發現模式：它不是客戶端查詢服務注冊表，而是向 DNS 名稱發出請求，DNS 名稱解析為查詢注冊表并負載平衡請求的請求路由器。AWS 彈性負載均衡器 (ELB) 是服務器端發現路由器的一個示例。客戶端向 ELB 發送 HTTP/TCP 請求，ELB 在一組 EC2 實例之間對流量進行負載平衡。ELB 還充當服務注冊表。實例通過 API 調用顯式注冊到 ELB，或者作為自動擴展組的一部分自動注冊。

5、基于平臺的服務發現的好處

• 部署平臺處理服務發現的所有工作。
• 服務和客戶端都不包含任何用于服務發現的代碼。
• 服務發現對所有服務和客戶端都可用，無論它們是用什么語言編寫的。

6、基于平臺的服務發現的缺點

• 只能發現已使用該平臺部署的服務。