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

Question

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

在 client-side负载均衡，客户端调用中间服务器(例如 API 网关 - Zuul，配置有 负载均衡器 - Ribbon 例如和 命名服务器 - 例如 Eureka)，然后决定调用哪个微服务实例。

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

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

Answer 1

在客户端负载平衡中，客户端负责发现和连接到源服务器的繁重工作。客户端可能会引用查找(Eureka、Consul，可能是 DDNS)来发现最终目的地是什么，并且注册中心将分配一个有效的来源。通信是直接的，客户端到服务器，没有中间人。
在服务器端负载平衡中，客户端是哑的，并调用预定地址(通常是 DNS 或静态 IP)。然后，该设备基于查找、心跳等代理(TCP 或协议(protocol)级别)与源服务器的连接。
我已经看到客户端路由的好处，只要您在客户端和服务器之间有 IP 连接，基础设施的工作就可以轻松添加新服务、位置、产品、应用程序等。只要新服务器可以在注册表中“注册”，并且客户端对服务器具有 IP 访问权限，它可以正常工作，IT 不必参与推出您的新服务。
缺点是它使客户端更重一些，它确实需要从客户端直接访问服务器的 IP 访问，并且可能会让传统的 IT 人员和审计人员感到困惑。每个客户端都需要了解注册表并具有进行调用的代码(或使用 sidecar/sidekick)。
我在实践中看到一个团队开始将他们的应用程序转换到 Docker 环境，并且他们能够同时运行基于 Docker 的应用程序和非 docker 版本，而无需让 IT 参与，并且快速自主地进行大量实验和测试。
如果你有自治的团队，在 devops 领域非常先进，并且对你的团队有很大的信任，那么客户端路由和负载平衡对你来说可能是一个很好的体验。