如果你想跟朋友失去聯繫的最簡單方法就是在不通知他們的情況下更改您的電話號碼。同樣適用於微服務架構系統中的服務。兩個服務可能會愉快地相互通信，直到其中一個服務移動到另一個IP地址，而不通知對方，導致服務不可用。
一、什麼是服務發現？
服務發現是關於查找服務提供者的網絡位置。
二、我們為什麼需要它？
如果一個團隊正在維護的是一臺物理服務器，那麼配置文件將主要滿足需求。
如果你正在使用雲，由於重新啟動，失敗和縮放，您的服務可能具有動態網絡位置。因此，手動維護配置文件就不可行了。
三、什麼是組件
服務發現涉及三方：服務提供者，服務使用者和服務註冊中心。
- 服務提供者在服務註冊表進入註冊時註冊自己，並在註銷時自行註銷。
- 服務消費者從註冊中心獲取提供者的位置，然後與提供者交談。
- 服務註冊中心維護提供者的最新位置。
目前，市面上有許多現有的服務發現工具可供使用。但是，我們如果想要建立自己的註冊中心，應該怎麼做呢？
四、設計服務發現
由於服務註冊表基本上保持鍵值對(provider name, provider locations) ，因此redis可能是一個不錯的選擇。因此，我們用redis模擬服務發現過程作為註冊表。
當服務提供者 inventory_service 在註冊表中註冊時，我們使用 SADD 它的位置添加到 set ：
當服務消費者查詢位置時 inventory_service ，我們可以使用 SMEMBERS 獲取所有位置，或者我們可以隨機選擇一個SRANDMEMBER ：
當 inventory_service 註銷本身時，我們用 SREM 它從集合中刪除它：
但是處理起來很複雜：
- 該服務在消失時可能不會註銷。然後註冊表向消費者提供一個無效的地址。為了解決這個問題，服務提供商需要定期發送心跳「每5秒鐘」。如果提供者在一段時間內沒有發送任何心跳，則註冊管理機構將認定提供者死亡，並取消註冊。
- 每次調用提供者之前查詢註冊表？這對註冊表造成太大的負擔，並施加不必要的性能影響。最好在消費者身上也保留一份副本。
- 如果保存在消費者中，如何通知消費者關於服務提供者的變化？有兩種方法可以做到這一點。1）消費者使用投票獲取最新版本。由於這些地點通常不會如此頻繁地變化，所以這仍然有效。缺點是輪詢之間可能會停機。2）pubsub 模式。它提供了更直接的位置更新，但它會佔用額外的消費者線索。
- 返回提供者的所有數據可能不是必需的。我們可以保留提供者的全局版本，消費者只需要在版本增加時更新其本地副本。
- 單點故障。如果服務註冊表中心「如我們在此使用的 redis 實例」關閉，則所有消費者和提供者都將受到影響。為了減輕這一點，我們可以使用分佈式數據庫作為服務註冊表，例如 zookeeper/etcd/consul 。
五、客戶端發現或服務器端發現
- 客戶端發現：客戶端查詢服務註冊中心，接著使用負載均衡算法選擇可用的服務實例中的一個並把這個請求路由到該實例。 優點：註冊表是唯一一個更多的組件。缺點：需要為系統中使用的不同語言/框架實現服務發現客戶端。
- 服務器端發現：客戶端通過負載均衡器向服務發送請求。負載均衡器查詢服務註冊中心並路由每個請求到可用的服務實例。優點：語言/框架不可知。 缺點：現在你需要管理另一個移動部分「負載平衡器」。
六、結論
本文解釋了服務發現是如何在微服務體系結構系統中起作用的；它將會有助於你在使用Netflix Eureka等開源工具時瞭解或調試。
七、參考
https://github.com/Netflix/eureka/wiki/Understanding-eureka-client-server-communication
https://www.nginx.com/blog/service-discovery-in-a-microservices-architecture/
閱讀更多 憶蓉之心 的文章
