在创build一个基于负载均衡和反向代理的体系结构时，两者如何放置？
这是正确的架构吗？ First LB server, then proxy: – 当客户端点击一个URL时，它基本上是一个负载平衡器，它有多个反向代理服务器坐在它后面。 它调用一个反向代理服务器，它反过来收集来自多个服务器的数据并完成请求
有没有First proxy server then LB server的可能性？
还是我完全错过了情节？
正如Jesper所说，你需要更多的细节。
在这种情况下，反向代理的作用是什么？ 目标性能，高可用性还是两者兼而有之？
一些负载均衡器会执行URL过滤，所以如果代理只是路由stream量（而不是caching），那么您可能根本不需要代理。
有多lessstream量可以被caching？ 你的瓶颈在哪里？
最近，我一直在使用这个基于PHP的应用程序的结果很好：
HAProxy --> Varnish --> Nginx --> PHP-FPM --> MySQL/NFS server
我们发现大约70％的请求都可以通过清漆caching来提供。 我们考虑把Varnish放在前面，但是一个Varnish服务器不能处理负载。 所以我们需要负载平衡。
这在LB级创build了一个单一的故障点，但我们的客户没有问题，因为我们可以在5分钟内启动一个新的实例。 他们愿意冒5-10分钟的风险，而不是有双代理服务器的复杂基础设施。
每个用例都有所不同，只有通过testing才能find符合预算的最佳解决scheme。
这是我通常做的。
有2个清漆服务器在前面与一个共享的IP通过Keepalive在一个死亡的情况下。 作为我的反向代理。
在它后面（或在同一台服务器上），请使用haproxy进行负载均衡。
Varnish也支持负载平衡到后端，但是你没有像haproxy那样得到好的统计数据或控制。 如果你使用一个硬件负载平衡器..很可能是先行，因为这也可能是你的防火墙。
最后..这真的取决于你想如何布局它。
这取决于你的详细和具体的需求，所以根据你所提供的信息来回答是不太可能的。 在某些情况下，您的build议都是有效且良好的解决scheme。
一如既往…分析您的实际生产负载，并对您正在使用的设备/软件进行基准testing和负载平衡testing。
一般来说：
如果您需要SSL，那么很大程度上取决于LB或代理是否最好地处理SSL。 通常，您需要在networking边缘（即第一台服务器上）处理SSL。
如果您需要多个代理服务器来处理负载，那么会向LB --> proxie(s) --> LB --> App Servers （或使用粗略的DNS Round Robin粗略分配负载到多个代理服务器）推送。
如果你需要在你的代理之前保持一致的散列 ，那么这将推动LB --> proxie(s) --> LB --> App Servers和一个支持一致哈希的负载平衡器。
如果一个代理可以处理你的负载，那么proxy --> LB --> App Servers是最简单的。 一些代理，如Varnish，甚至有一个基本的负载均衡器内置。
“HAProxy”的作者Willy Tarreau写了一篇关于通用前端负载平衡/ SSL卸载/代理体系结构的文章 。