为什么不建议将数据库和 Web 服务器放在同一台机器上？

小开

我认为最重要的因素是表现。Web 服务器/应用程序代码和 SQL 服务器都会将通常请求的数据缓存在内存中，如果在相同的内存空间中运行它们，那么缓存性能就会大打折扣。

小开

我认为这是因为这两台机器通常需要以不同的方式进行优化。除此之外，我不知道，我们所有的应用程序都是在同一台机器上的服务器数据库上运行的——当然我们不是面向公众的——但是我们没有遇到任何问题。

我无法想象有多少人关心一台机器在两者之间受到威胁，因为 Web 应用程序通常几乎可以不受限制地访问数据库中的模式，即使不能访问数据库中的模式，也可以访问最少的数据。

对别人可能说的话感兴趣。

小开

这取决于应用程序和目的。当高可用性和性能不重要时，不把数据库和 web 服务器分开也不错。特别是考虑到性能的提高——如果应用程序执行大量的数据库查询，那么可以通过在同一个系统上保持所有查询，保持较低的响应时间，从而消除大量的网络负载。

小开

汤姆说得对。其他一些原因是，它不具有成本效益，而且存在额外的安全风险。

Webserver 与数据库服务器有不同的硬件需求。数据库服务器有大量的内存和非常快的磁盘阵列，而 Web 服务器只需要足够的内存来缓存文件和频繁的数据库请求(取决于您的设置)。关于成本效益，这两个服务器不一定比较便宜，但是性能/成本比应该更高，因为不需要不同的应用程序竞争资源。出于这个原因，您可能需要为一台服务器花费更多的钱，这台服务器既能满足两者的需求，又能提供与两台专用服务器相同的性能。

安全问题是，如果单个计算机受到攻击，webserver 和数据库都会受到攻击。有了两台服务器，您就有了一些喘息空间，因为第二台服务器仍然是安全的(至少在一段时间内)。

此外，可伸缩性还有一些好处，因为您可能只需要维护一些数据库服务器，这些服务器由一些不同的 Web 应用程序使用。这样你就可以减少应用升级或者补丁和性能调优的工作量。我相信有一些服务器管理工具可以使这些任务变得更容易(在单机情况下)。

小开

另一方面，参考另一个博客 Scott (Watermasyck，来自 Telligent) ，他们发现大多数用户可以通过把数据库放在与网站相同的机器上来加速网站(使用 Telligent 的 Community Server)。然而，在他们的客户的情况下，通常数据库和网络服务器是唯一的应用程序在该机器上，网站是不是过度紧张的机器。然后，不必通过网络发送更多数据的效率弥补了增加的应变。

小开

从我的第一手经验来看，将 Web 服务器和数据库放在不同的机器上通常是一个好主意。如果您的应用程序是资源密集型的，那么它很容易导致机器上的 CPU 周期达到峰值，从本质上使机器停止运行。但是，如果您的应用程序对数据库的使用有限，那么让它们共享一个服务器可能没什么大不了的。

小开

安全是个大问题。理想情况下，数据库服务器应该位于防火墙之后，只打开执行数据访问所需的端口。您的 Web 应用程序应该使用一个 SQL 帐户连接到数据库服务器，这个 SQL 帐户只有足够的权限使应用程序能够正常运行。例如，您应该删除允许删除对象的权限，而且最肯定的是，您不应该使用诸如“ sa”之类的帐户进行连接。

如果你的网络服务器被劫持了(也就是管理员权限的权限提升) ，最坏的情况是你的应用程序的数据库可能会被破坏，但是不会破坏整个数据库服务器(如果数据库服务器和网络服务器是同一台机器就会出现这种情况)。如果你已经加密了你的数据库连接字符串，而黑客没有足够的悟性来解密它们，那么你失去的只是网络服务器。

小开

另外一个问题是，数据库喜欢占用所有可用内存，并在需要使用时将其保留起来。您可以强制它限制内存，但这会大大降低数据访问速度。

小开

最佳答案

保安。您的 Web 服务器位于一个 DMZ 中，可以访问公共互联网，并接受匿名用户的不可信输入。如果你的 web 服务器受到了威胁，并且你在连接数据库时遵循了最少的权限规则，那么你的应用程序通过数据库 API 所能做的就是最大的暴露。如果在两者之间有一个业务层，那么在攻击者和数据之间还有一个步骤。另一方面，如果您的数据库位于同一台服务器上，那么攻击者现在可以根访问您的数据和服务器。
可伸缩性。让你的 web 服务器保持无状态可以让你毫不费力地横向扩展你的 web 服务器。非常很难水平伸缩数据库服务器。
性能。2个机箱 = 2倍于 CPU，2倍于 RAM，2倍于磁盘访问的主轴。

尽管如此，我当然可以看到一些合理的案例，其中没有一点是真正重要的。

小开

一个尚未被提及的因素是负载平衡。如果你开始考虑网络服务器和数据库作为独立的机器，你优化了更少的网络往返，而且随着需求的增加，添加第二个网络服务器或第二个数据库引擎变得更加容易。

小开

哇，没有人提出这样一个事实，如果你真的以5000美元的价格购买 SQL 服务器，你可能希望使用它超过你的网络应用程序。如果你使用快递，也许你不在乎。我看到 SQL 服务器运行20到30个应用程序的数据库，所以把它放在网络服务器上是不明智的。

其次，取决于服务器是为谁服务的。我为金融公司和政府工作。因此，我们使用一个疯狂的痛苦的屁股方法只使用 sprocs 和限制端口从 webserver 到 SQL。所以如果网络应用被黑了。黑客唯一能做的就是调用 sprocs，因为 webserver 上的用户帐户被锁定，只能在 DB 上查看/调用 sprocs。所以现在黑客得想办法进入数据库。如果它在网络服务器很好它的种容易到达。

小开

真的并不重要(你可以很高兴地在同一台机器上用 web/database 运行你的站点) ，它只是扩展中最简单的一步。.

这正是 StackOverflow 所做的——从运行 IIS/SQL Server 的单台机器开始，然后当它开始负载过重时，购买第二台服务器，并将 SQL 服务器转移到该服务器上。

如果性能不是问题，不要浪费钱购买/维护两台服务器。

小开

操作系统是另一个考虑因素。虽然您的数据库可能需要更大的内存空间，因此需要 UNIX，但是您的 Web 服务器——或者更具体地说，您的应用程序服务器，因为您只提到了两层——可能是一个。基于网络，因此需要 Windows。

小开

我听了那个播客，很有趣，但是关于安全的争论对我来说毫无意义。如果您已经损害了服务器 A，并且该服务器可以访问服务器 B 上的数据，那么您可以立即访问服务器 B 上的数据。

小开

数据库许可证并不便宜，而且经常按每个 CPU 收费，因此通过分离网络服务器，可以降低数据库许可证的成本。

例如，如果你有一台服务器同时做网络和数据库，包含8个 CPU，你将不得不支付8个 CPU 许可证。但是，如果你有两台服务器，每台都有4个 CPU，并且在一台服务器上运行数据库，那么你只需要支付4个 CPU 的许可证费用

小开

我同意丹尼尔 · 埃尔维克的观点——安全问题有很多缺陷。

如果你有一个单一的盒子设置与一个网络服务器，只有该网络服务器上的数据库，如果该网络服务器是妥协的，你失去了既网络服务器，只有数据库为该特定的应用程序。

这与在两台服务器设置中丢失网络服务器的情况完全相同。你失去了 web 服务器，只有特定应用程序的数据库。

如果你有一个两台服务器的设置，那么“数据库服务器的其余部分的完整性得到了维护”这个论点是不相关的，因为在第一个场景中，与每个其他应用程序相关的每个其他数据库服务器(如果有的话)都不会受到影响，就像它们在其他地方托管一样。

类似地，对于 Kev 提出的问题“ DB 服务器上的所有其他数据库怎么办?”？你只丢失了一个数据库。'

如果您在一台服务器上托管应用程序和数据库，那么您将只在该服务器上托管与该应用程序相关的数据库。因此，与多个服务器设置相比，在单个服务器设置中不会丢失任何其他数据库。

相比之下，在一个2服务器的设置中，攻击者可以访问 Web 服务器，并通过代理，限制数据库服务器的权限(在最好的情况下) ，他们可以通过执行缓慢的，内存密集型查询或最大化数据库服务器上的可用存储空间，将其他应用程序的数据库置于危险之中。通过将应用程序分离成它们自己的关注点，非常类似于虚拟化，您还可以以积极的方式出于安全目的将它们隔离开来。

小开

好吧！事情是这样的，将数据库服务器安装在另一台机器上，将应用程序安装在 Web 服务器上会更安全。然后使用 Web 链接将应用程序连接到数据库。谢谢。

小开

认为在 Web 服务器上运行数据库服务器可以获得真正的性能提升是有缺陷的。

由于数据库服务器获取查询字符串并返回结果集，因此从数据服务器到 Web 服务器实际流动的数据相对较少，但是处理查询和生成结果集所需的马力相对较大。因此，围绕数据传输时间优化性能就是围绕错误的事情进行优化。

关于安全性，将数据服务器放在与 Web 服务器不同的机器上有一些好处。拥有这样的设置并不是安全的全部，但它是朝着正确方向迈出的一步。

关于可伸缩性，添加 Web 服务器并将其放入集群以处理增加的流量是容易且相对便宜的。添加数据服务器并将其集群化并不那么容易和便宜。此外，Web 服务器和数据服务器有不同的硬件需求，因此多个机箱有助于提高可伸缩性。

如果您从小型机器开始，并且只有一个机器，那么一个好的方法就是使用虚拟机。在一台主机上运行不同虚拟机中的 Web 服务器和数据服务器可以让您以一个大盒子的价格获得单独盒子的所有收益。

小开

这里没有提到的东西，我面临的原因是0停机部署。目前我在同一台机器上使用 DB/webserver，这使得更新非常痛苦。如果他们在一个独立的机器上，你可以执行 A/B 释放。例如:

DNS 当前指向 WebServerA
将软件更新应用到 WebServerB
将 DNS 更改为指向 WebServerB
在 WebServerA 上工作休闲为下一轮更新。

这在状态存储在数据库之前，在单独的服务器上进行。