頭一聽這個名詞覺得很高階，其實理解了原理思想和他的應用就覺得不是那麼高深。下面聽我娓娓道來。
首先看下面這個單伺服器模式：
多伺服器版：
客戶端與伺服器連線有乙個基本的要求，不管是長連線還是短連線，客戶端都需要知道伺服器的ip和port。
如果伺服器很多，你要把所有的伺服器配置都寫在配置檔案中。
如果增刪伺服器，那你還要去重新整理客戶端的配置檔案，怎麼重新整理呢？如果是長連線，那麼可以由伺服器傳送，但是如果是短連線呢？
可以實現，但是很複雜。
服務發現基本原理：
在客戶端和伺服器之間加了乙個「註冊中心」，可以把他乙個服務中介。
所有伺服器在啟動時，都需要在「註冊中心」進行註冊，把這個伺服器能提供的服務和這個服務對應的ip和port都發給註冊中心，由註冊中心來統計並儲存。客戶端需要資源時，向註冊中心來請求伺服器的位址。註冊中心根據原先的統計，把對應的伺服器位址傳送給客戶端。客戶端根據這個位址資訊，可以和伺服器完成通訊。
要明確的是：
伺服器和註冊中心長連線+短連線，短連線是為了伺服器的註冊，長連線是為了保持監控。
客戶端和註冊中心短連線。
客戶端和伺服器短連線。
優點
光從這個原理來看，就很好地解決了上面說的倆個問題。多配置的問題和伺服器增刪的問題。
因為現在的客戶端不關心伺服器，他配置只有註冊中心的位址，我只需要從註冊中心來獲取對應的伺服器位址資訊即可，這就實現了客戶端的零配置。
再談伺服器的增刪問題。首先我們讓伺服器和註冊中心保持長連線，這樣可以保持實時的通訊。伺服器異常掉線時，註冊中心可以檢查到。並根據檢查的內容，可以刪除註冊中心中對應儲存的服務。當新增乙個伺服器時，通過伺服器的註冊，註冊中心可以馬上檢查到，並可以馬上交給客戶端使用。
再說服務發現更加秒的應用：
負載均衡。之前說到，客戶端要向註冊中心來請求伺服器的位址。客戶端是根據需要的服務來請求，所以，註冊中心可能會發給客戶端不止乙個伺服器。這些伺服器都提供了這個服務。這時為了減輕伺服器的負擔，就需要從這一系列位址中拿出合適的來連線。可以使用輪詢，也可以是使用隨機訪問，也可以對健康狀況進行實時監控（這項較難）。
首先，從註冊中心出發，他整合了3個伺服器。乙個是與服務提供者保持長連線的伺服器，用乙個執行緒和乙個伺服器保持通訊。另乙個rmi伺服器保持短連線，用來接收伺服器的註冊資訊。所以需要提供給伺服器的api就是乙個註冊，註冊的資訊應該包括伺服器的ip，這個服務的port以及這個服務的名稱（就是乙個介面名）。最後乙個伺服器是和客戶端保持的短連線，之前已經講到。
那麼註冊中心應該用怎樣的資料結構來存放伺服器提供的服務？
我們給出倆個關係，map上面基本講完伺服器和註冊中心之間的關係。
註冊中心和客戶端的關係更加複雜。有乙個大問題，客戶端和註冊中心的連線時短鏈結，假如我一次已經拿到了一堆伺服器的位址，那麼我該何時進行第二次連線來重新整理這些位址。這些位址可能早就因為伺服器的掉線失效了。
所以我們要考慮客戶端重新整理的問題，基本的解決思路：每隔一定的時間和註冊中心連線來重新整理，當某發現某乙個位址失效時，也重新整理一次。
輪詢的方式。用迴圈鍊錶儲存所有的位址值，並記錄當前節點，每次從迴圈鍊錶來獲取時，先讓當前節點往後走一，在獲取。
隨機數的方式，產生乙個隨機數，用這個隨機數和儲存的位址列表的容量取餘，這個下標上得值作為返回值返回。
Zookeeper服務註冊與發現機制原理
zookeeper解決了分布式鎖的各種機制，通過它，我們可以將重心放在業務邏輯上，而非併發控制上。zookeeper提供了兩個功能 分布式鎖 服務註冊與發現。zookeeper的資料模型 zookeeper的資料儲存是基於節點的，稱作znode。znode的引用方式非常類似於檔案路徑，例如 當要訪問...
理解服務發現的基本原理
隨著微服務的大範圍應用，微服務中每個服務能做到按需伸縮拓展的優點也充分的體現在我們平常的工作中。但也暴露出乙個問題，就是微服務中每個服務的例項可能不止乙個，我們消費方 consumer 用傳統在專案配置中提供方 provider ip port來訪問服務提供方的方式就存在如下問題 部署在雲環境中，服...
RPC實戰與核心原理之服務發現
為了高可用，在生產環境中服務提供方都是以集群的方式對外提供服務，集群裡面的這些 ip 隨時可能變化，我們也需要用一本 通訊錄 及時獲取到對應的服務節點，這個獲取的過程我們一般叫作 服務發現 對於服務呼叫方和服務提供方來說，其契約就是介面，相當於 通訊錄 中的姓名，服務節點就是提供該契約的乙個具體例項...