微服務，客戶端發現

Question

我是新來的微服務，所以在閱讀這件事，我無法理解下述第談論負載均衡，客戶會怎麼做這樣的事情是什麼時候？

「當使用客戶端的發現，該客戶端負責在它們之間確定可用的服務實例和負載平衡的請求的網絡位置。」

Answer 1

一個微服務架構涉及到一些可能具有層次依賴的服務。例如，服務A取決於服務B，服務B取決於服務C等。同樣，每個服務可能有多個實例，並且它們的部署位置可能會動態變化。例如，服務C的訪問量過多，您可能會動態擴展/縮減該服務。

通常，最終用戶不能直接訪問的任何這些微服務。它只能通過位置固定的邊緣服務（如www.microservice.com/apis）訪問，並負責進行身份驗證，速率限制等。因此，所有服務呼叫都將通過邊緣服務和負載此階段的平衡主要通過使用硬件負載平衡器或Amazon ELB來實現。

現在，假設一個用戶想要訪問服務A.他必須通過邊緣服務來將請求委託給服務A.服務A必須調用服務B來獲得一些信息。在這種情況下，服務A是服務B的客戶端，服務A需要找到B的所有可用實例，然後調用其中一個實例。這是像Consul，Eureka等一個微服務註冊進入畫面。每個服務實例將不斷更新其註冊表的狀態（IP，端口，向上/向下等）。邊緣服務也將使用此註冊表來查找服務A的實例位置。

服務A還應該確保所有對服務B的調用都是負載平衡的。在這裏使用ELB進行負載平衡是不可行的，因爲這意味着如果你有50個服務，你需要有50個ELB。有些軟件負載平衡器可以以更有效的方式來實現這一點。對於如：Ribbon是一個很好的HTTP客戶端庫，用Java編寫的負載均衡器的支持。

Answer 2

客戶端負責確定的網絡位置 跨可用的服務實例和負載均衡請求。

我不確定你在哪裏閱讀，但服務消費者被迫執行負載平衡的整個概念是荒謬的。

客戶端發現模式實際上是說推遲呼叫路由（有時渠道建設），直到通過服務註冊的方式運行時的另一種方式。隨着理查德森says在他的模式頁：

製作到服務請求時，客戶端通過查詢服務註冊中心，哪知道所有服務實例的 位置獲得的 服務實例的位置。

負載均衡是一個完全不同的關注，總是被委派，最好到實際的負載均衡，但根據不同的服務平臺上使用的是你可以有機會獲得某種進程總代理。