服务发现与负载平衡

Luc*_*che 38 cloud web-services distributed-computing amazon-web-services microservices

我试图了解在哪种情况下我应该通过负载均衡器选择服务注册表.

根据我的理解,两种解决方案都涵盖相同的功能.

例如,如果我们将consul.io视为功能列表,我们有:

  • 服务发现
  • 健康检查
  • 键/值存储
  • 多数据中心

例如Amazon ELB等负载均衡器有:

  • 可配置为仅接受来自负载均衡器的流量
  • 使用以下协议接受流量:HTTP,HTTPS(安全HTTP),TCP和SSL(安全TCP)
  • 将请求分发到多个可用区中的EC2实例
  • 连接数与负载均衡器接收的并发请求数成比例
  • 配置Elastic Load Balancing用于监视使用负载均衡器注册的EC2实例的运行状况的运行状况检查,以便它可以仅向健康实例发送请求
  • 您可以在使用安全(HTTPS/SSL)连接的网络上使用端到端流量加密
  • [EC2-VPC]您可以创建面向Internet的负载均衡器,它通过Internet接收来自客户端的请求并将它们路由到您的EC2实例,或者面向内部的负载均衡器,它接收来自VPC中客户端的请求并路由它们到您的私有子网中的EC2实例.EC2-Classic中的负载平衡器始终面向Internet.
  • [EC2-Classic] EC2-Classic的负载平衡器支持IPv4和IPv6地址.VPC的负载平衡器不支持IPv6地址.
  • 您可以使用CloudWatch指标,访问日志和AWS CloudTrail监控负载均衡器.
  • 您可以将面向Internet的负载均衡器与您的域名相关联.
  • 等等

因此,在这种情况下,我无法理解为什么我会选择类似consul.ionetflix eureka以上Amazon ELB的服务发现.

我有一种预感,这可能是由于实现客户端服务发现服务器端服务发现,但我不太确定.

Ric*_* Li 12

您应该将其视为客户端负载平衡与专用负载平衡.

客户端负载均衡器包括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)作为其实现的一部分,但它们提供健康检查/端到端功能你可能正在寻找.


tec*_*oma 6

服务发现组件通常有一个通知组件。它不是负载平衡器,尽管有些人可能有能力这样做。它可以通知已注册的客户端有关更改的信息,例如负载均衡器出现故障。

客户端可以查询服务发现/注册以获取正在运行的负载均衡器。而负载均衡器在关闭时不会通知客户端。


roh*_*wal 6

AWS ELB和Eureka在许多方面有所不同:

边缘服务与中间层服务的对比
AWS ELB是针对暴露于最终用户Web流量的边缘服务的负载平衡解决方案。Eureka满足了中层负载平衡的需求。
中间层服务器是指位于用户计算机和进行处理的数据库服务器之间的应用程序服务器。中间层服务器执行业务逻辑。
从理论上讲,您可以将中间层服务放在AWS ELB后面,但在EC2 Classic中,您会将它们暴露给外界,从而失去了AWS安全组的所有有用性。

专用负载平衡与客户端负载平衡
AWS ELB还是传统的基于代理的负载平衡解决方案,而与Eureka的不同之处在于,负载平衡以循环方式在实例/服务器/主机级别进行。客户端实例知道有关它们需要与哪些服务器通信的所有信息。
如果您正在寻找AWS现在提供的基于粘性用户会话(会话期间来自用户的所有请求都发送到同一实例)基于负载的平衡,则Eureka不会提供开箱即用的解决方案。

负载平衡器中断
另一个使基于代理的负载平衡与使用Eureka进行负载平衡区别的重要方面是,由于有关可用服务器的信息已缓存在Eureka客户端上,因此您的应用程序可以抵御负载平衡器的中断。
这确实需要少量的内存,但可以提高弹性。Eureka客户端一次获得所有注册表信息,并在随后向Eureka服务器的请求中,仅接收增量,即注册表信息中的更改,而不是整个注册表信息。此外,Eureka服务器可以在集群模式下运行,其中每个对等方均不受其他对等方性能的影响。

规模和便利性
此外,请想象一下,正在运行的微服务有数千个,每个微服务都有多个实例。您将需要1000个ELB,每个微服务一个,或者位于ELB后面的HAProxy之类的东西,以根据主机名做出第7层决策,等等,然后将流量转发到实例的子集。在使用Eureka时,您仅使用不太复杂的应用程序名称进行播放。

  • “ AWS ELB是针对暴露于最终用户Web流量的边缘服务的负载平衡解决方案。” 当尤里卡(Eureka)于2012年不再创建时,这可能是正确的。现在,AWS可以选择创建ELB而不暴露于外部流量。 (3认同)