我们开发和维护 Web 应用程序；在我们当前的设置中；我们使用数据库服务器、应用程序服务器和 Web 服务器的三层系统。
到目前为止，一切都很好。
我们面临的问题是理论上此设置旨在帮助我们平衡这些机器之间的负载，并根据需要插入新的分片；实际上，这给我们的后台网络带来的压力正在成为一个严重的瓶颈。
还有提供静态文件的问题；由于我们目前的设置；这些文件必须由应用程序提供（占用我们可用于处理传入请求的 FastCGI 进程），或者首先使用 Web 服务器作为运行应用程序的机器上的本地代理。
那么问题就变成了：
简单地将 Web 服务器和应用程序服务器合并为一个；通过它带来的配置简化；以及访问的直接性（本地套接字而不是 TCP）；以及通过 Web 服务器提供静态文件的能力的增强是否可能会提高性能；或者是否存在我遗漏的开销因素？
答案1
一般来说，我喜欢采用分体式架构：一个数据库服务器群、一个“公共 www”服务器群（商业网站）和一个应用服务器群——可能根据需要还有其他中间件层。
这背后的逻辑很古老——基本上，公共 www 服务器不需要访问任何敏感数据，因此一些好奇的黑客在 www.mycompany.com 上四处搜索可能会破坏我们的营销网站，但他们不会得到任何其他东西。
这里还有一些其他的一般想法...
回复：后台网络负载，如果我们谈论的是联系 FastCGI 主机的流量负载，我会说在这些机器上安装一个 Web 服务器并让它们直接与外界通信可能是一个好主意。
要记住的一件事是，在发生安全漏洞时保持数据库的隔离/保护，这可能是将您的 FastCGI 内容推送到 Web 服务器上并编写一些更轻量级的东西来与您的数据库通信的理由……
（如果我们谈论的是其他事情请告诉我，我会尽力尝试 :-)
回复：静态文件问题，有很多方法可以解决这个问题。
将静态数据的副本放在每个需要发送它的服务器上。
我们称之为“磁盘便宜”方法——它可防止您在托管静态内容的单个机器上倾倒大量负载，并消除单点故障。缺点是您必须以某种方式同步该内容（部署脚本、cron'd rsync、cvs/git/svn 等）。在前端服务器上安装缓存基础架构
这是与上述“磁盘便宜”类似的解决方案，只有一台包含静态内容的后端服务器，而当前端服务器需要它时，它们会缓存一份副本以供$LIFETIME，从而无需同步脚本（缓存基础设施会为您完成此操作）。将静态内容放在内容传送网络上
这实际上只有在您没有使用 SSL 时才有效——商业 CDN 解决了加载问题，并为用户提供了地理分布的点，他们可以从这些点获取您的内容。缺点是，如果您对具有 SSL 的网站这样做，大多数浏览器都会大发雷霆，除非您的 CDN 也是安全的（即使这样，偏执的浏览器也应该有理由抱怨）。