【问题标题】:Service discovery vs load balancing服务发现与负载均衡
【发布时间】:2016-01-12 13:14:59
【问题描述】:

我试图了解在哪种情况下我应该选择服务注册表而不是负载均衡器。

据我了解,两种解决方案都涵盖相同的功能。

例如,如果我们将 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 来进行服务发现。

我预感这可能是由于实现了客户端服务发现 vs 服务器端服务发现,但我不太确定。

【问题讨论】:

标签: web-services amazon-web-services cloud distributed-computing microservices


【解决方案1】:

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

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

【讨论】:

    【解决方案2】:

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

    客户端负载均衡器包括 Baker Street (http://bakerstreet.io);智能栈(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 代理使用 Consul)作为其实现的一部分,但它们提供健康检查/端到端-end 您可能正在寻找的功能。

    【讨论】:

      【解决方案3】:

      您还应该阅读有关 EUREKA 的信息


      Amazon ELB 根据负载均衡器为您的服务请求提供 EC2 实例,并且 EC2 实例的 IP 地址不一致,因此您也可以使用 EUREKA,它执行相同的工作,但基于服务注册表和客户端负载均衡其中每个区域的应用程序客户端都有注册表。 你可以在这里读更多关于它的内容 : https://github.com/Netflix/eureka/wiki/Eureka-at-a-glance

      【讨论】:

        【解决方案4】:

        AWS ELB 和 Eureka 有很多不同之处:

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

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

        负载平衡器中断
        将基于代理的负载平衡与使用 Eureka 进行负载平衡区分开来的另一个重要方面是,由于有关可用服务器的信息已缓存在 Eureka 客户端上,因此您的应用程序可以灵活应对负载平衡器的中断。
        这确实需要少量内存,但可以购买更好的弹性。 Eureka 客户端一次获取所有注册表信息,并且在对 Eureka 服务器的后续请求中,它只接收增量,即注册表信息中的更改,而不是整个注册表信息。此外,Eureka 服务器可以在集群模式下运行,每个对等点不受其他对等点的性能影响。

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

        【讨论】:

        • “AWS ELB 是面向最终用户 Web 流量的边缘服务的负载平衡解决方案。”当 eureka 在 2012 年创建时,这可能不再是真的。现在 AWS 可以选择创建 ELB 而不会暴露于外部流量。
        猜你喜欢
        • 2021-01-10
        • 1970-01-01
        • 2013-08-26
        • 2022-10-23
        • 2017-12-15
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多