实践中的客户端负载平衡似乎与服务器端负载平衡几乎相同。是这样吗？答案

【问题标题】：Client-side load balancing in practice seems to be almost the same as server-side load balancing. Is that so?实践中的客户端负载平衡似乎与服务器端负载平衡几乎相同。是这样吗？
【发布时间】：2019-06-03 04:58:58
【问题描述】：

在server-side 负载平衡中，客户端调用中间服务器，然后由中间服务器决定调用实际服务器（或微服务）的哪个实例。

在client-side 负载平衡中，客户端也会调用中间服务器（API 网关 - 例如Zuul，配置有负载平衡器 - @例如 987654325@ 和 命名服务器 - 例如 Eureka），然后决定调用哪个微服务实例。

除非我们将 API 网关作为客户端的一部分，否则客户端仍然不知道它应该向其发送请求的确切服务器的 IP 地址。在我看来，这很像服务器端负载平衡。我有什么遗漏吗？

（将 API 网关作为客户端的一部分似乎很奇怪，因为它通常部署在与客户端不同的服务器上）

【问题讨论】：

这可能会有所帮助 - stackoverflow.com/questions/29730310/…
@SundararajGovindasamy 我仍然不清楚它的客户端是如何做出负载平衡决定的，当它明确地将 Ribbon 放置在 API 网关上时，它会这样做
您不必调用中间服务器。您可以使用RestTEmplate 并以负载平衡的方式使用它。你不需要/不需要 ZUUL。您可以直接在客户端中使用 Ribbon。在您的情况下，您模拟了服务器端负载平衡，而不是使用客户端负载平衡。
@M.Deinum 那么，就是说如果我们使用像Zuul这样的API网关，整个架构就不能再说是遵循客户端负载均衡了？
没错，除非您将您的 api-gateway 视为客户端，否则您可以说这是在进行客户端负载平衡（虽然有点牵强）。

标签： spring spring-boot microservices netflix-eureka spring-cloud-netflix

【解决方案1】：

在客户端负载平衡中，客户端负责发现和连接到源服务器的繁重工作。客户端可以参考查找（Eureka、Consul，可能是 DDNS），以发现最终目的地是什么，并且注册中心将分配一个有效的来源。通信是直接的，客户端到服务器，没有中间人。

在服务器端负载平衡中，客户端是哑的，并调用预定地址（通常是 DNS 或静态 IP）。然后，该设备根据查找、心跳等代理（TCP 或协议级别）与源服务器的连接。

我看到客户端路由的好处在于，只要您在客户端和服务器之间建立 IP 连接，基础架构的工作就可以轻松添加新的服务、位置、产品、应用程序等。只要新服务器可以向注册表“注册”，并且客户端可以通过 IP 访问服务器，它可以正常工作，而 IT 不必参与推出新服务。

缺点是它使客户端有点重，它确实需要从客户端直接访问服务器的 IP 访问，并且可能会让传统的 IT 人员和审计人员感到困惑。每个客户端都需要了解注册表并拥有调用代码（或使用 sidecar/sidekick）。

我在实践中看到一个团队开始将他们的应用程序转换到 Docker 环境，并且他们能够同时运行基于 Docker 的应用程序和非 Docker 版本，而无需获取IT 参与并快速自主地进行大量实验和测试。

如果您拥有自治团队，在 devops 领域非常先进，并且对您的团队非常信任，那么客户端路由和负载平衡对您来说可能是一个很好的体验。

【讨论】：