原文地址http://microservices.io/patterns/service-registry.html，谷歌翻譯（略微調整）如下。
背景
使用服務的客戶端可以采取客戶端發現（Client-side discovery）和服務端發現（Server-side discovery）兩種方式進行服務的發現，那么我們如何做到這些呢？
考慮因素
一個服務的每個實例公開一個遠程接口如HTTP/ REST、Thrift等。
服務實例數量和它們的位置是動態變化的。如：虛擬機和容器通常分配動態IP地址，一個EC2自動縮放集群可以調整基於負載實例的數量。
解決方案
實現服務注冊，服務的實例和它們的位置保存在服務注冊里。服務實例啟動時進行注冊，服務停止時進行注銷。服務的使用客戶或者路由器查詢服務注冊發現服務的可用實例。
示例
經常用作服務注冊的技術包括：
l Eureka
l Apache Zookeeper
l Consul
l Etcd
一些系統，如Kubernetes，Marathon和AWS ELB有一個隱含的服務注冊表（譯注：很多傳統應用使用LDAP存放服務注冊表，當然還有數據庫、緩存等，不過這些都只是存儲服務注冊表的方法，和監測服務狀態的機制一起才能構建服務注冊功能）。
解決方案背景
Service Registry模式的好處包括：
l 客戶端或路由器可以發現服務實例的位置。
也有一些缺點：
除非服務注冊表內置於基礎設施，否則這又是一個基礎設施組件，必須單獨設置、配置和管理。此外，服務注冊表是一個關鍵的系統組件。雖然客戶端可以緩存注冊表數據，但如果服務注冊失敗，緩存數據終將過時，因此，服務注冊中心必須具有高可用性。
你需要決定如何服務實例注冊到服務注冊中心。有兩種選擇：
l 自注冊模式 - 服務實例注冊自己。
l 第三方注冊模式 – 使用第三方進行注冊。
服務注冊的客戶端需要知道服務注冊表實例的位置（S）。服務注冊表實例都必須部署在固定的和眾所周知的IP地址，客戶端被配置到這些地址。例如，Netflix的Eureka服務實例通常使用彈性IP地址發布。彈性IP地址的可用池使用屬性文件或DNS來完成。當一個Eureka實例啟動時，它會查詢配置，以確定使用哪一個可用的彈性IP地址。Eureka的客戶端也需要配置彈性IP地址池。
相關模式
- Client-side discovery 和 Server-side discovery 用戶服務發現。
- Self registration 和3rd party registration 是兩種服務注冊方法。
自身注冊服務
Self registration 解決方案部分。服務實例負責在服務注冊中心注冊自己。在啟動服務實例將自己注冊（主機和IP地址）到服務注冊表，使自己可以發現。通常必須定期更新其客戶端的注冊，使注冊表知道它仍然活着。在關閉時，服務實例從服務注冊表中注銷本身。Netflix的Eureka是一個服務注冊中心的一個例子。它提供了一個注冊API和一個客戶端庫，服務實例使用（UN）注冊自己。當使用Apache Zookeeper作為服務注冊，每個服務對應於特定Zookeeper znode。在啟動時，每個服務實例創建服務znode的一個短暫的子znode。短暫znode包含實例的位置。服務的客戶端只需檢索服務znode的子節點就可以確定可用的實例。如果客戶端終止，無需拆卸短暫的節點，Apache Zookeeper將超時客戶端並刪除znode（淘寶的dubbo使用該機制）。
第三方注冊
3rd party registration解決方案部分。第三方注冊管理器是負責注冊和注銷服務實例到服務注冊表。當服務實例啟動時，注冊管理器注冊服務到服務注冊表，當服務實例關閉時，注冊管理器從服務注冊表中注銷服務實例。使用第三方注冊的例子如：
Netflix的Prana - 一個非JVM應用，以"side car"方式運行，注冊服務到Eureka。
Registrator – 向服務中心Consul注冊和注銷Docker容器包含的各種服務。
集群框架（Docker集群），如Kubernetes和Marathon（UN）內置服務注冊功能。
客戶端服務發現
Client-side discovery方案解決方案部分。客戶端請求服務時，客戶端通過查詢服務注冊中心獲得一個服務實例的位置。下圖顯示了這種模式的結構：
Netflix的OSS提供客戶端發現一個很好的例子，Eureka提供服務注冊，Ribbon Client是一個http client客戶端通過查詢Eureka獲得可用的服務實例。客戶端發現相比服務端發現減少了網絡通訊並且更為簡單。但是，相比服務端發現，你需要為每種編程語言/框架編寫服務發現的邏輯實現，例如Java和Scala，JavaScript / Nodejs。例如，Netflix公司提供了一個HTTP代理為基礎的非Java虛擬機客戶服務發現方法。
服務端服務發現
Server-side discovery 解決方案部分。客戶端請求服務時，客戶端請求運行在一個公知位置的路由器（又名負載平衡器）。路由器再去查詢服務注冊，服務注冊可能本身就被建立在路由器中，並且將可用服務實例轉發給客戶端。下圖顯示了這種模式的結構：
一個AWS彈性負載均衡器（ELB）是一個服務器端發現路由器的一個例子。客戶端發出的HTTP（S）請求（或打開TCP連接）到ELB。一個ELB可以負載均衡的請求可以是來自互聯網也可以是來自VPC，負載均衡的內部通信時。一個ELB可以用作服務注冊。 EC2實例是通過調用一個API進行注冊或自動成為集群的一部分。
一些集群解決方案，如Kubernetes和Marathon運行一個代理服務器作為作為服務器端發現的路由。為了訪問服務，客戶端連接到分配給該服務的本地代理，然后代理服務器將請求轉發到集群中某處運行的服務實例。