在创建基于负载平衡和反向代理的架构时，这两者应该如何放置？
这是正确的架构吗？
First LB server, then proxy:- 当客户端点击 URL 时，它基本上是一个负载平衡器，其后面有多个反向代理服务器。它调用反向代理服务器，后者又从多个服务器收集数据并满足请求
有可能吗First proxy server then LB server？
还是我根本没理解剧情？
答案1
正如 Jesper 所说，您需要更多详细信息。
在这种情况下，反向代理的作用是什么？目标是性能、高可用性还是两者兼而有之？
一些负载平衡器会进行 URL 过滤，因此如果代理只是路由流量（而不是缓存），那么您可能根本不需要代理。
有多少流量可以被缓存？你的瓶颈在哪里？
最近，我一直在使用这个堆栈，对于基于 PHP 的应用程序取得了良好的效果：
HAProxy --> Varnish --> Nginx --> PHP-FPM --> MySQL/NFS server
我们发现大约 70% 的请求可以通过 Varnish 缓存来处理。我们考虑过将 Varnish 放在最前面，但单个 Varnish 服务器无法处理负载。因此无论如何我们都需要进行负载平衡。
这会在 LB 级别产生单点故障，但我们的客户对此并不介意，因为我们可以在大约 5 分钟内启动一个新实例。他们愿意冒 5-10 分钟的停机风险，而不是拥有带有双 HA-Proxy 服务器的更复杂的基础设施。
每个使用情况各不相同，只有通过测试才能找到适合预算的最佳解决方案。
答案2
这是我通常会做的事情。
在前面有 2 个 varnish 服务器，通过 keepalive 共享一个 IP，以防其中一个服务器死机。作为我的反向代理。
在它后面（或者在同一台服务器上），haproxy 负责进行负载平衡。
Varnish 还支持后端负载平衡，但您无法像使用 haproxy 那样获得良好的统计数据或控制。如果您使用硬件负载平衡器，那么很有可能首先要考虑它，因为它也可能是您的防火墙。
最后……这真的取决于你想如何布局。
答案3
这取决于您更详细和更具体的需求，因此无法根据您提供的信息来回答。在某些情况下，您的建议都是有效的，也是很好的解决方案。
与往常一样...分析您的实时生产负载，并对您正在使用的代理和负载平衡设备/软件进行基准测试。
一般来说：
如果您需要 SSL，那么很大程度上取决于 LB 或代理是否能最好地处理 SSL。通常，您需要在网络边缘（即第一台服务器）处理 SSL。
如果您需要多个代理服务器来处理负载，那么将会推动
LB --> proxie(s) --> LB --> App Servers（或使用粗略的 DNS 循环将负载粗略地分配给多个代理）。如果你需要一致性哈希在您的代理前面，那么它将会推向
LB --> proxie(s) --> LB --> App Servers支持一致性散列的负载均衡器。如果单个代理可以处理您的负载，那么这
proxy --> LB --> App Servers是最简单的。某些代理（如 Varnish）甚至内置了基本的负载平衡器。
Willy Tarreau 是优秀的 HAProxy 的作者，他写了一篇关于常见的前端负载平衡/ SSL 卸载/代理架构。