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

Question

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

在client-side负载均衡中，客户端也会调用一个中间服务器（例如，API 网关——Zuul例如，配置了一个负载均衡器——Ribbon例如和一个命名服务器—— Eureka），然后它决定调用微服务的哪个实例。

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

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

Answer 1

在客户端负载平衡中，客户端负责发现和连接到原始服务器的繁重工作。客户端可以引用查找（Eureka、Consul、也许是 DDNS）来发现最终目的地是什么，并且注册表将分发有效的来源。通信是直接的，客户端到服务器，无需中间人。

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

我已经看到客户端路由的好处，因为只要客户端和服务器之间有 IP 连接，添加新服务、位置、产品、应用程序等的基础设施工作就很简单。只要新服务器可以向注册表“注册”，并且客户端具有对服务器的 IP 访问权限，它就可以正常工作，IT 不必参与推出新服务。

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

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

如果您拥有自治团队，在开发运营方面非常先进，并且对您的团队有很大的信任，那么客户端路由和负载平衡可能对您来说是一种很好的体验。