服务发现、负载均衡和连接池方法

Question

在为大型系统（如 AWS）部署 SOA 时，有两种方法可用于服务交互。

1. 让每个服务集群都在内部 elb 之后。客户端用对应的elb创建一个连接池，elb做循环平衡。

2. 采用像 netflix eureka 这样的服务发现方法。

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

我对第二个方法有以下疑问。

1. 转向服务发现和智能客户端架构，服务客户端知道所有服务实例（通过 eureka 服务或同等服务）并进行内部负载平衡，是否有好处？
2. 在上述情况下，连接池如何工作？目前，每个客户端实例必须准确维护 1 个连接池，即与相应服务的 elb。但是对于富客户端，每个客户端都将拥有所有可以直接通信的服务实例端点。为每个请求建立连接效率不高，我猜每个客户端都有这么多连接池（每个服务实例 1 个）是一种过度杀伤力。

需要对以上两个问题的意见/建议。

Answer 1

第一个问题。

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

第二个问题。

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