聊起微服務的服務註冊與發現，很多人立馬就會脫口而出 zk、etcd、consul、eureka 這些元件，進而聊到 cap 如何取捨，效能如何，高可用和容災是怎麼實現的。
在這之前，站在元件使用者的角度，我想先問這麼幾個問題：
看完這些問題後，您也許會發現，對於服務註冊與發現，首先應該關注的是服務註冊發現本身的功能，然後才是效能和高可用。
乙個好的服務註冊發現中介軟體，應該是能完整地滿足服務開發和治理的基礎功能，然後才是效能和高可用。如果沒有想清楚前面的功能，再高的可用性和效能都是浮雲。最後，安全也同樣重要。
下面將從 服務註冊、服務發現、容災和高可用三個大方面來回答這些問題的主流做法。
最後會介紹一下 ans(alibaba naming service) ， ans 綜合了這些解決方案中的優點，並在 edas(阿里巴巴企業級分布式應用服務) 中輸出，目前完全免費！
ip 如何確定
主流的 ip 獲取有這幾種方法。
埠如何確定
埠的獲取，沒有標準化的方案。
簡單地將 ip 和 port 資訊註冊上去，可以滿足基本的服務呼叫的需求，但是在業務發展到一定程度的時候，我們還會有這些需求：
這些高階功能的實現，本質上是依賴於客戶端呼叫時候的負載均衡策略和呼叫策略，但是如果服務元資料沒有註冊上來，也只能是巧婦難為無公尺之炊。乙個良好的服務註冊中心在設計最初就應該支援這些擴充套件字段。
優雅發布
雖然服務註冊一般發生在服務的啟動階段，但是細分的話，服務註冊應該在服務已經完全啟動成功，並準備對外提供服務之後才能進行註冊。
優雅下線
絕大多數的服務註冊中心都提供了健康檢查功能，在應用停止後會自動摘除服務所對應的節點。但是我們也不能完全依賴此功能，應用應該在停止時主動呼叫服務註冊中心的服務下線介面。
健康檢查分為客戶端心跳和服務端主動探測兩種方式。
但是客戶端心跳中，長連線的維持和客戶端的主動心跳都只是表明鏈路上的正常，不一定是服務狀態正常。
服務端主動呼叫服務進行健康檢查是乙個較為準確的方式，返回結果成功表明服務狀態確實正常。
服務端主動探測也存在問題。服務註冊中心主動呼叫 rpc 服務的某個介面無法做到通用性；在很多場景下服務註冊中心到服務發布者的網路是不通的，服務端無法主動發起健康檢查。
所以如何取捨，還是需要根據實際情況來決定，根據不同的場景，選擇不同的策略。
很經典的 push 和 pull 問題。
push 的經典實現有兩種，基於 socket 長連線的 notify，典型的實現如 zookeeper；另一種為 http 連線所使用 long polling。
但是基於 socket 長連線的 notify 和基於 http 協議的 long polling 都會存在notify訊息丟失的問題。
所以通過 pull 的方式定時輪詢也必不可少，時間間隔的選擇也很關鍵，頻率越高服務註冊中心所承受的壓力也越大。需要結合服務端的效能和業務的規模進行權衡。
還有一種方式，真實的 push，客戶端開啟乙個 udp server，服務註冊中心通過 udp 的方式進行資料推送，當然這個也受限於網路的連通性。
當服務節點數越來越多時，服務註冊中心的效能會成為瓶頸，這時候就需要通過水平擴容來提公升服務註冊中心集群的效能。
首先，本地記憶體快取，當執行時與服務註冊中心的連線丟失或服務註冊中心完全宕機，仍能正常地呼叫服務。
然後，本地快取檔案，當應用與服務註冊中心發生網路分割槽或服務註冊中心完全宕機後，應用進行了重啟操作，記憶體裡沒有資料，此時應用可以通過讀取本地快取檔案的資料來獲取到最後一次訂閱到的內容。
最後，本地容災資料夾。正常的情況下，容災資料夾內是沒有內容的。當服務端完全宕機且長時間不能恢復，同時服務提供者又發生了很大的變更時，可以通過在容災資料夾內新增檔案的方式來開啟本地容災。此時客戶端會忽略原有的本地快取檔案，只從本地容災檔案中讀取配置。
服務端的無狀態性保證了服務的容災和高可用可以做的很薄。
鏈路安全，對於使用 http 連線的服務註冊中心，保護鏈路安全的最好方式是使用 https。而使用 tcp 連線的服務註冊中心來說，由於應用層協議一般使用的是私有協議，不一定存在現成的 tls 支援方案。
在業務安全方面，應該在每一次的發布、訂閱、心跳，都帶上鑑權的資訊就行驗籤和鑑權，確保業務資訊的安全性。
ans (alibaba naming service) 是阿里巴巴中介軟體團隊將多年業務實踐沉澱打磨的開源產品。在服務註冊與發現方面，ans 綜合了上述解決方案中的優點，是最適合雲原生應用的服務註冊與發現元件。
ans 服務已經在 edas(阿里巴巴企業級分布式應用服務) 上線，目前已經提供 spring cloud ans starter 方便 spring cloud 使用者直接使用乙個安全的可靠的商業版服務註冊與發現功能。ans 能完美地支援 eureka 的特性，而且目前完全免費！更多資訊參見 edas 幫助文件。
聊聊微服務的服務註冊與發現
摘要 乙個好的服務註冊發現中介軟體，應該是能完整地滿足服務開發和治理的基礎功能，然後才是效能和高可用。如果沒有想清楚前面的功能，再高的可用性和效能都是浮雲。最後，安全也同樣重要。下面將從 服務註冊 服務發現 容災和高可用三個大方面來回答這些問題的主流做法。聊起微服務的服務註冊與發現，很多人立馬就會脫...
微服務2,3,4 註冊與發現
格物致知，格註冊與發現。服務發現承載服務提供與消費者之間的橋梁，各個微服務與服務發現元件使用心跳機制進行通訊。服務發現元件如果長時間無法與某微服務例項通訊，就會登出該例項。spring cloud提供了多種服務發現元件的支援，如eureka,consul 和 zookeeper等 單節點eureka...
微服務 Consul（服務註冊發現）
類似dns伺服器會根據我們的網域名稱解析出乙個ip位址，然後去請求這個ip來獲取我們想要的資料，它可以讓我們只需說我想要什麼服務即可，而不必去關心服務提供者的具體網路位置 ip 位址 埠等 目前，服務發現主要分為兩種模式，客戶端模式與服務端模式 在客戶端模式下，首先要到服務註冊中心獲取服務列表，然後...