服务发现、负载平衡和连接池方法
在将SOA部署到像AWS这样的云上的大型系统时，有两种方法可用于服务交互。
>
让每个服务群集位于内部elb后面。客户端使用相应的elb创建连接池，elb执行循环平衡。
采用netflix eureka等服务发现方法。
目前，我们正在使用第1种方法，其中每个服务集群位于内部elb后面，客户机通过elb进行通信，因此每个客户机实例只需维护一个池，即与elbendpoint进行通信。
我对第二部分有以下疑问。
- 转向服务发现和智能客户端体系结构是否有好处？在智能客户端体系结构中，服务客户端知道所有服务实例（通过eureka服务或等效服务），并进行内部负载平衡
需要对上述两个问题的投入/建议。
共有1个答案
第一个问题。
有。首先，您可以更好地进行故障恢复—例如，在不向客户端显示任何错误的情况下，重试对另一个节点的失败请求。接下来，您可以比ELB提供的产品做更好的平衡。接下来，您可以在不改变ELB配置的情况下自动向集群添加/从集群中删除节点。如果节点具有运行状况检查，这非常有用。更重要的是，软件平衡器可以很快做到这一点。
第二个问题。
每个节点都有连接池。i、 e.[客户端代码中的api方法]-
-
我们正在使用持久连接，并尝试在x时间段后强制断开连接。虽然我认为我们在理论上可以使用连接保持投资策略，但我能说的是，这只适用于回应之后。。i、 e.当连接空闲时。 我们的问题是... 假设有一台客户端，通过负载平衡器访问两台服务器（A、B）。当其中一台服务器脱机（B）时，所有新连接都会在服务器（A）上建立。现在，当另一台服务器（B）重新联机时，它将保持空闲状态，因为所有连接都在另一台服务器（A）上
-
从我们的应用程序创建和运行开始，我们就需要一种发送信息到外边的方法。如果我们当前运行多个 app， 它们也需要一种方法来找到彼此。 我们可以通过域名系统(DNS)使用Mesos-DNS作为服务发现。Mesos-DNS 会给正运行在 Mesos 上的每个应用程序生成一个主机名， 在当前的机器上把这些名字转化成IP地址和端口。如果通过多个 framework（不只是 Marathon）发布应用程序，M
-
我是微服务的新手。（学习阶段）。我有一个问题。我们在云中部署微服务。（例如 AWS）。云已经提供了负载平衡和日志。我们还在Spring Boot中实现了负载平衡（功能区）和日志（Rabbit MQ和Zipkin）。这两种实现有什么区别？我们两者都需要吗？有些人可以回答这些问题吗？ 提前感谢。
-
Kubernetes在设计之初就充分考虑了针对容器的服务发现与负载均衡机制，提供了Service资源，并通过kube-proxy配合cloud provider来适应不同的应用场景。随着kubernetes用户的激增，用户场景的不断丰富，又产生了一些新的负载均衡机制。目前，kubernetes中的负载均衡大致可以分为以下几种机制，每种机制都有其特定的应用场景： Service：直接用Service
-
试图自学如何使用库伯内特斯，但有一些问题。 我的下一步是尝试使用LoadBalancer类型的服务来访问nginx。 我建立了一个新的集群并部署了nginx映像。 然后，我为LoadBalancer设置服务 设置完成后，我尝试使用LoadBalancer入口（我在描述LoadBalancer服务时发现）访问nginx。我收到一个此页面无法工作的错误。 不太确定我哪里出错了。 kubectl获得sv
-
我正在写一个集成测试。我有一个在Testcontainer中运行的Spring Boot 2.5应用程序。我还让StubRunnerExtension运行WireMock。 我需要Spring Boot应用程序连接到存根WireMock服务器。 发生错误是因为Spring认为是服务的名称。它不是-它是专门为这种情况提供的特殊Test容器主机名（从Test容器连接到主机）。 Wiremock存根肯定