背景
使用服務的客戶端可以採取客戶端發現（client-side discovery）和服務端發現（server-side discovery）兩種方式進行服務的發現，那麼我們如何做到這些呢？
考慮因素
乙個服務的每個例項公開乙個遠端介面如http/ rest、thrift等。
解決方案
實現服務註冊，服務的例項和它們的位置儲存在服務註冊裡。服務例項啟動時進行註冊，服務停止時進行登出。服務的使用客戶或者路由器查詢服務註冊發現服務的可用例項。
示例
經常用作服務註冊的技術包括：
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位址池。
相關模式
自身註冊服務
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方案解決方案部分。客戶端請求服務時，客戶端通過查詢服務註冊中心獲得乙個服務例項的位置。下圖顯示了這種模式的結構：
服務端服務發現
server-side discovery 解決方案部分。客戶端請求服務時，客戶端請求執行在乙個公知位置的路由器（又名負載平衡器）。路由器再去查詢服務註冊，服務註冊可能本身就被建立在路由器中，並且將可用服務例項**給客戶端。下圖顯示了這種模式的結構：
乙個aws彈性負載均衡器（elb）是乙個伺服器端發現路由器的乙個例子。客戶端發出的http（s）請求（或開啟tcp連線）到elb。乙個elb可以負載均衡的請求可以是來自網際網路也可以是來自vpc，負載均衡的內部通訊時。乙個elb可以用作服務註冊。 ec2例項是通過呼叫乙個api進行註冊或自動成為集群的一部分。
一些集群解決方案，如kubernetes和marathon執行乙個**伺服器作為作為伺服器端發現的路由。為了訪問服務，客戶端連線到分配給該服務的本地**，然後**伺服器將請求**到集群中某處執行的服務例項。
服務註冊與發現
在分布式系統中，各個子系統都是多個例項存在，這個時候必須要引入乙個服務協調器，用於給呼叫方提供可用的呼叫提供者的命名訊息。服務協調器，如zookeeper，etcd，eureka 他們必須要有的特性 本身高可用，由多個服務節點構成，就算有些節點掛掉也不影響正常執行，避免了單點故障。本身是乙個分布式，...
服務發現與註冊
提供restful api或者其他的api的服務。為了完成一次請求，服務呼叫方需要知道服務例項的ip和埠。平台中的應用一般有多個例項，例項故障重啟和負載均衡都與服務發現有關。通過服務發現機制，可以透明的對多個例項進行訪問，並實現負載均衡。且應用的某個例項隨時可能故障，這時就需要動態配置服務呼叫方的路...
服務註冊與服務發現
應用場景 多台伺服器提供同乙個服務 是儲存服務名稱與ip和埠對應關係的伺服器 服務只會註冊ip,埠這些資訊，至於服務提供什麼介面，consul不管,需要消費者知道這些細節.安裝執行 consul agent dev 監控頁面 新建2個專案，分別提供兩個服務 給專案隨便新建乙個控制器提供健康檢查使用 ...