【发布时间】: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.io 或 netflix eureka 而不是 Amazon ELB 来进行服务发现。
我预感这可能是由于实现了客户端服务发现 vs 服务器端服务发现,但我不太确定。
【问题讨论】:
-
stackoverflow.com/questions/46807757/… 这个帖子似乎也有同样的担忧
标签: web-services amazon-web-services cloud distributed-computing microservices