实际上，客户端负载平衡似乎与服务器端负载平衡几乎相同。是这样吗？

Question

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

在client-side负载均衡中，客户端也会调用中间服务器（例如，配置为 load-balancer -Zuul） strong>-例如Ribbon和命名服务器-Eureka），然后决定要调用微服务的哪个实例。

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

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

Answer 1

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

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

我已经看到了客户端路由的好处，只要您在客户端和服务器之间有 IP 连接，基础设施的工作对于添加新服务、位置、产品、应用程序等来说是微不足道的。只要新服务器可以向注册中心“注册”，并且客户端拥有对服务器的 IP 访问权限，它可以正常工作并且 IT 不必参与推出您的新服务。

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

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

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