[英]Service discovery vs load balancing
我試圖了解在哪種情況下我應該通過負載均衡器選擇服務注冊表。
根據我的理解,兩種解決方案都涵蓋相同的功能。
例如,如果我們將consul.io視為功能列表,我們有:
例如Amazon ELB等負載均衡器有:
所以在這種情況下,我無法理解為什么我會選擇consul.io
或netflix eureka
consul.io
這樣的東西來通過Amazon ELB
進行服務發現。
我有一種預感,這可能是由於實現客戶端服務發現與服務器端服務發現 ,但我不太確定。
您應該將其視為客戶端負載平衡與專用負載平衡。
客戶端負載均衡器包括Baker Street( http://bakerstreet.io ); SmartStack( http://nerds.airbnb.com/smartstack-service-discovery-cloud/ ); 或Consul HA代理( https://hashicorp.com/blog/haproxy-with-consul.html )。
客戶端LB使用服務發現組件(Baker Street使用無狀態發布/子服務發現機制; SmartStack使用ZooKeeper; Consul HA Proxy使用Consul)作為其實現的一部分,但它們提供健康檢查/端到端功能你可能正在尋找。
AWS ELB和Eureka在許多方面有所不同:
邊緣服務與中端服務
AWS ELB是面向最終用戶Web流量的邊緣服務的負載平衡解決方案。 Eureka滿足了中層負載平衡的需求。
中間層服務器是指位於用戶計算機和進行處理的數據庫服務器之間的應用程序服務器。中間層服務器執行業務邏輯。
雖然理論上您可以將您的中間層服務置於AWS ELB之后,但在EC2 Classic中,您會將它們暴露給外部世界,從而失去AWS安全組的所有實用性。
專用於客戶端負載平衡
AWS ELB也是傳統的基於代理的負載平衡解決方案,而與Eureka不同的是,負載均衡以實例/服務器/主機級別以循環方式發生。 客戶端實例知道他們需要與哪些服務器通信的所有信息。
如果您正在查找AWS現在提供的基於負載平衡的粘性用戶會話(會話期間來自用戶的所有請求都被發送到同一實例),Eureka不提供開箱即用的解決方案。
負載平衡器中斷
使用Eureka區分基於代理的負載平衡與負載平衡的另一個重要方面是,您的應用程序可以適應負載均衡器的中斷,因為有關可用服務器的信息緩存在Eureka客戶端上。
這確實需要少量內存,但可以獲得更好的彈性。 Eureka客戶端立即獲取所有注冊表信息,並在隨后向Eureka服務器發出的請求中,它僅接收增量,即注冊表信息的更改,而不是整個注冊表信息。 此外,Eureka服務器可以在群集模式下運行,其中每個對等體不受其他對等體的性能影響。
規模和便利
此外,想象一下,1000個微服務正在運行,每個微服務都有多個實例。 您需要1000個ELB,每個微服務一個,或者像ELB后面的HAProxy,根據主機名等做出第7層決策,然后將流量轉發到實例的子集。 使用Eureka時,您只能使用遠不那么復雜的應用程序名稱。
Service Discovery組件通常具有通知組件。 它不是負載均衡器,盡管有些人可能有這樣的能力。 它可以通知已注冊的客戶端有關更改,例如負載均衡器發生故障。
客戶端可以查詢服務發現/注冊表以獲取正在運行的負載均衡器。 負載均衡器在客戶端關閉時並不會使客戶端無法正常運行。
您還應該閱讀有關EUREKA的信息
Amazon ELB基於負載均衡器為您的服務請求提供EC2實例,並且EC2實例的IP地址不一致,因此您也可以使用EUREKA,它執行相同的工作,但基於服務注冊表和客戶端負載平衡,其中每個區域的應用程序客戶端都有注冊表。 你可以在這里閱讀更多相關信息: https : //github.com/Netflix/eureka/wiki/Eureka-at-a-glance
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.