当反向代理主要用于负载平衡时，很明显为什么将请求路由到 N 个代理服务器池应该有助于平衡负载。
但是，一旦请求的服务器端计算完成并且是时候将响应发送回客户端，那么单个反向代理服务器为什么永远不会成为瓶颈？
我对反向代理概念的直观理解告诉我，
在它后面代理 N 个源服务器的反向代理服务器显然不会像涉及 N 个代理服务器的单服务器等效设置那样容易或早成为瓶颈，但它也会成为在某个时候成为瓶颈，因为所有 N 个代理服务器的响应都通过它。
为了进一步延迟上述瓶颈点（达到），N 个代理服务器应该“以某种方式”直接将响应分派给客户端，而不是通过单个坐在他们面前的反向代理。
我对反向代理概念的理解有什么问题？也许第 2 点根据定义不是反向代理服务器设置，但保留定义，为什么第 2 点相对于反向代理选项不受欢迎？
【问题讨论】：
标签： reverse-proxy
反向代理，当用于负载平衡时，会将所有流量代理到源服务器池。 这意味着客户端 TCP 连接在 LB（反向代理）处终止，LB 代表客户端向其中一个源节点发起新的 TCP 连接。现在，节点在处理完请求后，无法直接与客户端通信，因为客户端 TCP 连接已通过负载均衡器的 IP 打开。 客户端期待来自 LB 的响应，而不是来自任何其他随机家伙或随机 IP（-：某个节点的）。因此，响应通常与请求以相同的方式流动，通过LB。此外，您不想将节点的 IP 暴露给客户端。这对于请求-响应系统来说通常都可以很好地扩展。所以我对 #1 的回答是：LB 通常可以很好地适用于请求-响应系统。如果在所有必需的，可以添加更多的 LB 以在 VIP 后面创建冗余。
现在，话虽如此，如果您的响应很大，则绕过 LB 来编写响应仍然是有意义的。例如，如果您正在流式传输视频作为响应，那么您可能不想用巨大的响应来扼杀您的 LB。在这种情况下，可以配置Direct Server Return LB。这基本上就是您在#2 中所想的。这允许响应直接从源服务器流出，绕过 LB，并且仍然对客户端隐藏源节点的 IP。这是通过特殊方式配置ARP来实现的，使得源节点写入的响应携带LB的IP。这不是直接设置，LB 的常用代理模式适用于大多数用例。
【讨论】：