服务发现，负载平衡和连接池方法

Question

当针对在AWS等云上部署的大型系统使用SOA时，可以使用两种方法进行服务交互。

1. 将每个服务群集放在内部Elb后面。客户端与相应的elb建立连接池，而elb进行循环平衡。

2. 使用netflix eureka之类的服务发现方法。

当前，我们正在使用第一种方法，其中每个服务群集都位于内部elb后面，并且客户端通过elb进行通信，因此每个客户端实例仅需维护1个池，即与elb端点。

对于第二种方法，我有以下疑问。

1. 迁移到服务发现和智能客户端体系结构（服务客户端知道所有服务实例（通过eureka服务或同等服务）并且内部负载平衡）是否有好处？
2. 在以上情况下，连接池如何工作？当前，每个客户端实例必须维护1个连接池，即与相应服务的Elb连接的池。但是对于富客户端，每个客户端将具有所有服务实例终结点以直接与之通信。在每个请求上建立连接将不是高效的，我想每个客户端拥有如此多的连接池（每个服务实例1个）是过大的。

在以上两个问题上需要输入/建议。

Answer 1

第一个问题。

就在这里。首先，您可以进行更好的故障恢复 - 例如，重试对另一个节点的失败请求，而不向客户端显示任何错误。接下来，您可以进行比 ELB 提供的更好的平衡。接下来，您可以自动向集群添加节点或从集群中删除节点，而无需更改 ELB 配置。如果您的节点有健康检查，这非常有用。更重要的是，软件平衡器可以快速做到这一点。

第二个问题。

每个节点都有连接池。即[客户端代码中的api方法] -> [软件均衡器] -> [节点连接池] -> [节点连接] -> [使用此连接发出请求]