背景
不同服務之間通常需要相互呼叫。在單體應用程式當中，服務間通過語言層級的方法或者過程實現相互呼叫。在傳統的分布式系統部署下，服務在固定並且已知的位置（主機與埠）執行，從而確保各服務可利用http/rest或者某種rpc機制進行相互呼叫。然而，現代化微服務應用程式中通常在虛擬化或者容器化環境中執行，在這樣的環境中服務的例項數量和位置是動態變化的。
因此，要想實現客戶端向動態變化的一組服務端例項傳送請求，我們必須採用新的機制。
問題
服務的客戶端——包括api閘道器或者其它服務——如何才能獲取服務端例項的位置？
需求
方案
在向某一服務傳送請求時，客戶端會通過查詢service registry，即服務登錄檔，以獲取該服務例項的位置。該登錄檔中包含全部服務的位置。
以下示意圖展現了這種模式的結構。
而這正是微服務底盤框架的典型處理方式。
示例
netflix oss正是客戶端發現機制的典型代表：
結果
客戶端發現機制擁有以下優勢：
客戶端發現機制亦存在著以下弊端：
相關模式
微服務架構模式系列文章之七 自註冊
背景 如採用客戶端服務發現模式或者伺服器端服務發現模式，各服務例項必須在啟動時註冊至服務登錄檔，從而保證其能夠被獲取，並在關閉時進行登出。問題 如何在服務登錄檔內註冊和登出服務例項？需求 方案 一項服務例項必須可以自動註冊到服務登錄檔中。在啟動時，該服務例項將自身 主機與ip位址 註冊至服務登錄檔，...
微服務架構模式系列文章之六 服務登錄檔
背景 一項服務的客戶端需要使用客戶端發現或者伺服器端發現機制，從而獲取給其傳送請求的服務例項的位置。問題 服務的客戶端 在客戶端發現機制中 或者服務路由 在服務端發現機制中 如何獲取可用服務例項的資訊？需求 方案 建立一套服務登錄檔，即乙個包括服務 服務的例項和其位置資訊的資料庫。各服務例項需要在啟...
微服務架構模式系列文章之六 服務登錄檔
背景 一項服務的客戶端需要使用客戶端發現或者伺服器端發現機制，從而獲取給其傳送請求的服務例項的位置。問題 服務的客戶端 在客戶端發現機制中 或者服務路由 在服務端發現機制中 如何獲取可用服務例項的資訊？需求 方案 建立一套服務登錄檔，即乙個包括服務 服務的例項和其位置資訊的資料庫。各服務例項需要在啟...