沒有硬編碼的微服務發現的最佳實踐？

Question

這是一個令我討厭的問題，如何編寫一系列在不同位置的各種機器上運行的微服務，而無需對每個服務的每個位置進行硬編碼？

就像說例如我有服務A，它執行json消息的某種形式的驗證。服務A在方框1,3,5上運行，隨着需求增長，可以調出更多的實例。

現在說我有服務B，它看起來要打電話給服務A，我將如何與我的服務A所在的服務B進行通信？

可能的解決方案，我認爲：

• 硬編碼與服務A，然後委託任務分給服務A的所有實例「主」節點的位置服務B

• 消息隊列的使用情況？ - 服務B寫入一系列消息隊列，服務A實例從設置的消息隊列中讀取並將結果發送回服務B.

• SSDP-利用某種形式的簡單服務發現協議來廣播哪些服務在哪裏運行設置網絡並跟蹤這些服務。

我對這種建築風格很陌生，所以我希望我沒有遺漏一些非常簡單的東西？

Answer 1

一般來說，有2種方法來實現服務發現：

1. 與反向代理/ API網關。這種方法提供更快的更新傳播。當您的服務被部署/重新部署/取消部署時，所有更改都可以立即通過反向代理進行處理，因此其配置總是反映您的微服務的狀態。但是，這會對性能產生影響 - 所有請求（包括內部請求）都應該通過反向代理組件。有關此方法的更多詳細信息https://memz.co/api-gateway-microservices-docker-node-js/
2. 與DNS。由於每個組件（實質上是每個用於調用可發現組件的http客戶端）需要重新驗證其DNS緩存，這可能需要一些時間（可以使用相應的DNS條目的TTL進行配置），因此此方法提供的更新速度較慢。此外，它假定每個http客戶端實現都將遵守該TTL值。作爲第一個近似值，我們可以假設TTL可以設置爲低至60秒，因此，配置更改將不會生效。關於此方法的更多詳細信息https://memz.co/service-discovery-microservices-skydns-docker/

Answer 2

使用service registry並在運行時查找其他服務的位置。以下是一些用於此的典型技術（還有其他一些技術）。

• Eureka
• Apache ZooKeeper
• Consul
• Etcd

服務註冊必須存在於一個已知位置。該位置應始終是微服務中的可配置屬性。從來沒有硬編碼！爲了提高靈活性，通過DNS訪問註冊表端點是非常典型的。所以，你的服務尋找https://registry-1而不是一個特定的IP地址，這可能會改變。

根據您希望在系統中使用的通信機制，消息隊列將幫助您的服務進行通信，但它不會幫助發現。在這種方法中，您仍然使用DNS和可配置屬性來告知每個微服務消息隊列的位置。然後，單個服務將發佈消息並將消息訂閱到隊列中。微服務永遠不會意識到其他服務（沒有發現），並且所有的通信都將通過隊列中的消息。

Sam Newman's book on microservices更詳細地介紹了這些方法，並涵蓋了您可能感興趣的其他關注領域。