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

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

1、服務發(fā)現

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

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

2、應用程序級服務發(fā)現模式

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

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

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

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

3、應用層服務發(fā)現的缺點

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

4、平臺提供的服務發(fā)現模式

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

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

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

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

5、基于平臺的服務發(fā)現的好處

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

6、基于平臺的服務發(fā)現的缺點

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