前文中提到，微服務獨立部署、具有清晰的邊界，服務之間通過遠端呼叫來構建複雜的業務功能。那為什麼要引用服務註冊與發現呢？服務註冊與發現具體要解決什麼問題？
服務註冊與發現主要解決了如下兩個重要問題：
1）遮蔽，解耦服務之間相互依賴的細節
我們知道服務之間的遠端呼叫必須要知道對方的ip、埠資訊。我們可以在呼叫方直接配置被呼叫方的ip、埠，這種呼叫方直接依賴ip、埠的方式存在明顯的問題，如被呼叫的ip、埠變化後，呼叫方法也要同步修改。
通過服務發現，將服務之間ip與埠的依賴轉化為服務名的依賴，服務名可以根據具微服務業務來做標識，因此，遮蔽、解耦服務之間的依賴細節是服務發現與註冊解決的第乙個問題。
2）對微服務進行動態管理
在微服務架構中，服務眾多，服務之間的相互依賴也錯綜複雜，無論是服務主動停止，意外掛程式掉，還是因為流量增加對服務實現進行擴容，這些服務資料或狀態上的動態變化，都需要盡快的通知到被呼叫方，被呼叫方才採取相應的措施。因此，對於服務註冊與發現要實時管理者服務的資料與狀態，包括服務的註冊上線、服務主動下線，異常服務的剔除。
服務發現將服務ip、埠等細節通過乙個服務名抽象給呼叫者，並動態管理者各個微服務的狀態檢測、狀態更新，服務上線，下線等，這些都是微服務治理的基礎，包括，負載均衡，鏈路跟蹤。對於服務發現與註冊 一般有兩種實現模式：伺服器端模式，客戶端模式。
伺服器端模式通過使用乙個中間的伺服器，來遮蔽被呼叫服務的複雜性與變動性，當有新的服務加入或老服務剔除時，只需要修改中間伺服器上的配置即可，此模式的顯著特點是：引入獨立的中間**伺服器來遮蔽真實服務的具體細節。
如下圖所示：服務a是呼叫方（消費者），服務b是被呼叫方，微服b有三個負載，分別部署在三颱ip為100、101、102的機器上。當服務a要呼叫服務b時，先通過dns網域名稱解析找到nginx伺服器，然後將請求傳送給nginx，因為在nginx上配置了服務b的真實訪問位址，nginx收到請求後根據負載均衡演算法，將請求**到某個真實的服務b，服務b將請求結果返回給nginx，nginx再將返回結果給服務a，整個請求流程結束。
當然中間伺服器不一定非得nginx，還可以時基於硬體的f5，也可以工作在傳輸層的ip負載均衡等。
該模式的優點是：配置集中在獨立的中間伺服器端完成，對**沒有任何入侵，也不存在跨平台跨語言的問題。因為，所有請求都需要穿透中間伺服器，缺點也很明顯：中間伺服器會成為乙個單點，對效能也會有所影響。伺服器獨立模式
我們再看客戶端模式（下圖），應用場景還是一樣，服務a要呼叫服務b，服務b有三個負載。服務a呼叫服務b時，不需要通過中間伺服器，而是在自己程序內維護了服務b的資訊，再通過負載演算法選擇乙個服務b直接呼叫。那服務a具體是怎麼維護服務b的資訊呢？為此引入了服務註冊中心的概念，當服務b啟動時向註冊中心註冊自己（將自己的資訊傳送到註冊中心的登錄檔裡），服務a再從註冊中心獲取所有註冊的服務，這就是客戶端模式的基本原理。
客戶端（程序內）模式
客戶端模式因為在程序內直接呼叫服務，也叫做程序內負載，由於不需要穿透中間伺服器，所以客戶端模式的效能損耗比較小。但是，需要在服務內部維護服務註冊資訊，負載演算法等，有一定的**入侵性，對於跨平台，跨語言的支援不太友好。
服務發現的兩種模式各有優缺點，也適用於不同的場景，對於大型應用一般會有多層負載，外層用伺服器端負載均衡，內部用客戶端負載均衡。下面將重點介紹netflix的eureka服務發現元件，我們會從設計理念與原理，**實現等多個維度進行解析。微服系列文章**：微服務2,3,4 註冊與發現
格物致知，格註冊與發現。服務發現承載服務提供與消費者之間的橋梁，各個微服務與服務發現元件使用心跳機制進行通訊。服務發現元件如果長時間無法與某微服務例項通訊，就會登出該例項。spring cloud提供了多種服務發現元件的支援，如eureka,consul 和 zookeeper等 單節點eureka...
微服務 Consul（服務註冊發現）
類似dns伺服器會根據我們的網域名稱解析出乙個ip位址，然後去請求這個ip來獲取我們想要的資料，它可以讓我們只需說我想要什麼服務即可，而不必去關心服務提供者的具體網路位置 ip 位址 埠等 目前，服務發現主要分為兩種模式，客戶端模式與服務端模式 在客戶端模式下，首先要到服務註冊中心獲取服務列表，然後...
聊聊微服務的服務註冊與發現
摘要 乙個好的服務註冊發現中介軟體，應該是能完整地滿足服務開發和治理的基礎功能，然後才是效能和高可用。如果沒有想清楚前面的功能，再高的可用性和效能都是浮雲。最後，安全也同樣重要。下面將從 服務註冊 服務發現 容災和高可用三個大方面來回答這些問題的主流做法。聊起微服務的服務註冊與發現，很多人立馬就會脫...