在server-side负载平衡中，客户端调用一个中间服务器，然后由中间服务器决定调用实际服务器(或微服务)的哪个实例。
此外，在client-side负载平衡中，客户端调用中间服务器(例如，API网关-Zuul，配置有负载平衡器Ribbon和命名服务器-Eureka)，然后由其决定调用微服务的哪个实例。
除非我们将API网关作为客户端的一部分，否则客户端仍然不知道应该向其发送请求的确切服务器的IP地址。在我看来，这很像服务器端负载平衡。我有什么东西不见了吗？
(将API网关作为客户端的一部分似乎很奇怪，因为它通常部署在与客户端不同的服务器上)
在客户端负载平衡中，客户端承担着发现和连接到源服务器的重任。客户端可以参考查找(Eureka、Consul，可能是DDNS)，以发现最终目的地是什么，注册表将提供有效的来源。通信是直接的，客户端到服务器没有中间人
在服务器端负载平衡中，客户端是哑的，并对预定地址(通常是DNS或静态IP)进行调用。然后，该设备根据查找、心跳等代理(TCP或协议级别)到原始服务器的连接。
我看到了客户端路由的好处，因为只要你在客户端和服务器之间有IP连接，基础设施的工作就可以添加新的服务、位置、产品、应用程序等；寄存器"；有了注册表，客户端可以访问服务器的IP，它就可以正常工作，it不必参与推出新服务。
缺点是它让客户端变得更重，它确实需要从客户端到服务器的IP访问，并且可能会让传统的it人员和审计人员感到困惑。每个客户端都需要知道注册表，并有代码进行调用(或使用sidecar/sidekick)。
我在实践中看到，一个团队开始将他们的应用程序过渡到Docker环境，他们能够在不需要it参与的情况下，同时运行基于Docker的应用程序和非Docker版本，并快速自主地进行大量实验和测试。
如果你有自主的团队，在devops领域非常先进，并且对你的团队非常信任，那么客户端路由和负载平衡可能对你来说是一种很好的体验。