我试图了解在哪种情况下我应该通过负载均衡器选择服务注册表。
据我所知，两种解决方案都涵盖相同的功能。
例如，如果我们将 consul.io 视为功能列表，我们就会：
例如 Amazon ELB 等负载均衡器具有：
所以在这种情况下，我无法理解为什么我会选择consul.io或netflix eureka而不是Amazon ELB来进行服务发现。
我预感到这可能是由于实施客户端服务发现 vs 服务器端服务发现，但我不太确定。
答案 0 :(得分：9)
您应该将其视为客户端负载平衡与专用负载平衡。
客户端负载均衡器包括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）作为其实现的一部分，但它们提供健康检查/结束 - 你可能正在寻找的终端功能。
答案 1 :(得分：5)
AWS ELB和尤里卡（Eureka）在许多方面有所不同：
边缘服务与中层服务
AWS ELB是针对暴露于最终用户Web流量的边缘服务的负载平衡解决方案。 Eureka满足了中层负载平衡的需求。
中间层服务器是指位于用户计算机和进行处理的数据库服务器之间的应用程序服务器。中间层服务器执行业务逻辑。
从理论上讲，您可以将中间层服务放在AWS ELB的后面，但在EC2中
经典的做法是将它们暴露给外界，从而失去了AWS安全组的所有实用性。
专用负载与客户端负载平衡
AWS ELB还是传统的基于代理的负载平衡解决方案，而与Eureka的不同之处在于，负载平衡以循环方式在实例/服务器/主机级别进行。客户端实例知道有关它们需要与哪些服务器通信的所有信息。
如果您正在寻找AWS现在提供的基于粘性用户会话（会话期间来自用户的所有请求都发送到同一实例）基于负载的平衡，则Eureka不会提供开箱即用的解决方案。
负载均衡器中断
区分基于代理的负载平衡与使用Eureka进行负载平衡的另一个重要方面是，由于有关可用服务器的信息已缓存在Eureka客户端上，因此您的应用程序可以抵御负载平衡器的中断。
这确实需要少量的内存，但可以提高弹性。 Eureka客户端一次获得所有注册表信息，并且在随后向Eureka服务器的请求中，它仅接收增量，即注册表信息中的更改，而不是整个注册表信息。此外，Eureka服务器可以在群集模式下运行，其中每个对等方均不受其他对等方性能的影响。
规模和便利性
另外，想象一下，有数千个微服务正在运行，每个微服务都具有多个实例。您将需要1000个ELB，每个微服务一个，或者位于ELB后面的诸如HAProxy之类的东西，以根据主机名做出第7层决策，等等，然后将流量转发到实例的子集。在使用Eureka时，您只需要使用简单得多的应用程序名称即可播放。
答案 2 :(得分：3)
Service Discovery组件通常具有通知组件。它不是负载均衡器，尽管有些人可能有这样的能力。它可以通知已注册的客户端有关更改，例如负载均衡器已关闭。
客户端可以查询服务发现/注册表以获取正在运行的负载均衡器。负载均衡器在关闭时并不会使客户端无法正常运行。
答案 3 :(得分：-1)
您还应该阅读有关EUREKA
的信息Amazon ELB基于负载均衡器为您的服务请求提供EC2实例，并且EC2实例的IP地址不一致，因此您也可以使用EUREKA，它执行相同的工作，但基于服务注册表和客户端负载平衡其中每个区域的应用程序客户端都有注册表。 你可以在这里读更多关于它的内容 ： https://github.com/Netflix/eureka/wiki/Eureka-at-a-glance