为什么不build议将数据库和Web服务器放在同一台机器上？
听着Scott Hanselman对Stack Overflow团队的采访（ 第1部分和第2 部分 ），他坚持认为SQL服务器和应用程序服务器应该在不同的机器上。 这只是为了确保如果一台服务器被攻破，两个系统都不可访问？ 安全问题是否超过了两台服务器的复杂性（额外的成本，两者之间的专用networking连接，更多的维护等），特别是对于一个小型应用程序，哪个部件都没有使用太多的CPU或内存？ 即使有两台服务器，一台服务器被攻破，攻击者仍然可能会造成严重的破坏，无论是删除数据库，还是搞乱应用程序代码。
如果性能不是问题，为什么会这么大？
- 安全。 您的Web服务器位于DMZ中，可供公共互联网访问，并从匿名用户处获取不可信的input。 如果您的Web服务器受到威胁，并且您至less在连接到数据库时遵循了特权规则，那么您的应用程序可以通过数据库API执行的操作的最大风险是最大的。 如果您之间有一个业务层，则攻击者和您的数据之间还有一步。 另一方面，如果您的数据库位于同一台服务器上，则攻击者现在可以对您的数据和服务器进行根访问。
- 可扩展性。 保持Web服务器无状态可以让您轻松地水平扩展Web服务器。 水平扩展数据库服务器非常困难。
- 性能。 2个盒子= CPU的2倍，RAM的2倍，磁盘访问的主轴的2倍。
所有这一切，我当然可以看到合理的情况下，这些点都不重要。
这并不重要（你可以在同一台机器上用Web /数据库运行你的站点），这只是缩放中最简单的一步。
这正是StackOverflow所做的 – 从运行IIS / SQL Server的单机开始，然后当它开始负载过重时，又购买了第二台服务器，并将SQL服务器移到该服务器上。
如果性能不是问题，不要浪费钱购买/维护两台服务器。
另一方面，参考不同的博客Scott（Telligent的Watermasyck） – 他们发现，大多数用户可以通过将数据库放在与网站相同的机器上来加速网站（使用Telligent的社区服务器）。 但是，在他们的客户的情况下，通常db和web服务器是该机器上唯一的应用程序，并且网站并没有那么紧张的机器。 那么，不需要通过networking发送数据的效率就越多，弥补了增加的压力。
我认为最重要的因素就是performance。 Web服务器/应用程序代码和SQL Server都会caching内存中通常请求的数据，并通过在相同的内存空间中运行它们来消除高速caching的性能。
汤姆对此是正确的。 其他一些原因是这不符合成本效益，并且存在额外的安全风险。
Web服务器具有与数据库服务器不同的硬件要求。 数据库服务器有更多的内存和更快的磁盘arrays，而Web服务器只需要足够的内存来caching文件和频繁的数据库请求（取决于您的设置）。 就成本效益而言，两台服务器的价格并不一定比较便宜，但是性能/成本比率应该更高，因为您不需要为不同的应用程序争夺资源。 出于这个原因，你可能将不得不花费更多的服务器，迎合两者，并提供相当于2个专业的性能。
安全方面的担忧是，如果单台机器遭到破坏，networking服务器和数据库都将受到攻击。 有了两台服务器，第二台服务器仍然是安全的（至less有一段时间），你有一些喘息的空间。
此外，还有一些可扩展性的好处，因为您可能只需要维护一些不同的Web应用程序使用的一些数据库服务器。 通过这种方式，您可以减less应用升级或修补程序以及执行性能调整的工作量。 我相信有一些服务器pipe理工具可以让这些任务变得更简单（在单机情况下）。
还没有提到的一个因素是负载平衡。 如果您开始将Web服务器和数据库视为独立的机器，则可以针对较less的networking往返进行优化，并且随着需求的增加，可以更容易地添加第二台Web服务器或第二台数据库引擎。
安全是一个主要关切。 理想情况下，您的数据库服务器应位于防火墙后面，只需要打开执行数据访问所需的端口。 您的Web应用程序应该使用一个SQL帐户连接到数据库服务器，该帐户只有足够的权限才能运行应用程序。 例如，您应该删除允许删除对象的权限，而且绝对不应该使用诸如“sa”之类的帐户进行连接。
如果您将web服务器丢到劫持状态（即将权限全面升级为pipe理员权限），则最糟糕的情况是您的应用程序的数据库可能会受到损害，但不是整个数据库服务器（如果数据库服务器和Web服务器是同一台机器）。 如果你已经encryption你的数据库连接string，并且黑客没有足够的能力来解密它们，那么你所失去的就是Web服务器。
我可以从第一手的经验说，把Web服务器和数据库放在不同的机器上通常是一个好主意。 如果您的应用程序需要大量资源，则很容易导致机器上的CPU周期达到峰值，从而导致机器停机。 但是，如果您的应用程序对数据库的使用有限，让它们共享服务器可能没什么大不了的。
我同意Daniel Earwicker的观点 – 安全性问题有很多缺陷。
如果您的networking服务器只有一个设置，并且只有该networking服务器的数据库，那么如果该networking服务器遭到破坏，您将丢失该networking服务器以及该特定应用程序的数据库。
这与如果在双服务器设置上丢失Web服务器时发生的情况完全相同。 你失去了Web服务器，只是该特定应用程序的数据库。
有两台服务器设置的情况下，“剩余的数据库服务器的完整性得以维护”的说法是不相关的，因为在第一种情况下，与其他每个应用程序相关的其他数据库服务器（如果有的话）也不受影响 – 就像它们在其他地方一样。
同样，对于Kev提出的问题，DB服务器上所有其他数据库的情况如何？ 你失去的只有一个数据库。
- 如果您在一台服务器上托pipe应用程序和数据库，则只能在该服务器上托pipe与该应用程序相关的数据库。 因此，与多服务器设置相比，您不会在单个服务器设置中丢失任何其他数据库。
相反，在服务器设置中，攻击者可以访问Web服务器，并通过代理向数据库服务器提供有限的权限（在最好的情况下），他们可以通过携带其他应用程序的数据库进行缓慢的内存密集型查询或最大化数据库服务器上的可用存储空间。 通过将应用程序分离到自己的问题中，非常类似于虚拟化，为了安全起见，您也要以正面方式将它们隔离开来。
这取决于应用和目的。 当高可用性和性能不重要时，不要分开数据库和Web服务器。 特别是考虑到性能的提高 – 如果应用程序进行大量的数据库查询，则可以通过将所有数据保留在同一个系统上来消除大量的networking负载，从而保持较低的响应时间。
哇，没有人提出这样的事实，如果你真的以5k钱购买SQL服务器，你可能想要使用它比你的Web应用程序更多。 如果你使用快递，也许你不在乎。 我看到SQL服务器运行20到30个应用程序的数据库，所以把它放在networking服务器上不会很聪明。
其次，取决于服务器是谁。 我为金融公司和政府工作。 所以我们在使用sprocs和限制从web服务器到SQL的端口的ass方法中使用了一个疯狂的痛苦。 所以如果Web应用程序被黑客入侵。 黑客可以做的唯一事情就是调用sprocs，因为Web服务器上的用户帐户被locking，只能看到/调用数据库上的sprocs。 所以现在黑客必须弄清楚如何进入数据库。 如果它在Web服务器上很好，那么它很容易获得。
我认为这是因为这两台机器通常需要以不同的方式进行优化。 除此之外，我不知道，我们运行与服务器数据库在同一台机器上的所有应用程序 – 我们没有公开面对 – 但我们没有任何问题。
我无法想象有太多的人关心一台机器同时受到攻击，因为如果不是数据库内的模式，Web应用程序通常几乎不受限制地访问数据。
对别人可能会说的话感兴趣。
我听了那个播客，这很有趣，但是安全性的争论对我来说是没有意义的。 如果您已经损害了服务器A，并且该服务器可以访问服务器B上的数据，则您可以立即访问服务器B上的数据。
数据库许可证不是很好，每个CPU通常都要收费，因此通过分离您的Web服务器，可以降低数据库许可证的成本。
例如，如果您有一台服务器同时执行包含8个CPU的Web和数据库，您将需要为8个CPU许可证付费。 但是，如果您有两台服务器，每台服务器都有4个CPU，并在一台服务器上运行数据库，则只需支付4个CPU许可证
另一个值得关注的问题是，数据库喜欢占用所有可用内存，并在需要时使用它。 您可以强制它限制内存，但这可能会显着减慢数据访问。
认为通过在Web服务器上运行数据库服务器会带来真正的性能提升，这是一个有缺陷的观点。
由于数据库服务器接收查询string并返回结果集，实际从数据服务器stream向Web服务器的数据量相对较小，但处理查询和生成结果集所需的马力相对较大。 因此，围绕数据传输时间优化性能正在优化错误的事情。
关于安全性，将数据服务器放在与Web服务器不同的盒子上是有好处的。 build立这样的安全并不是所有的安全措施的总和，而是朝着正确的方向迈出的一步。
关于可伸缩性，添加Web服务器并将其放入群集以处理增加的stream量很容易且相对便宜。 添加数据服务器并对其进行群集并不是那么容易又便宜。 另外，Web服务器和数据服务器有不同的硬件需求，所以多个盒子可以提供可伸缩性。
如果你从小开始，只有一个盒子，那么一个好方法就是使用虚拟机。 在一个主机上运行不同虚拟机中的Web服务器和数据服务器，可以以一个大的盒子价格为您提供单独的盒子的所有收益。
操作系统是另一个考虑。 虽然数据库可能需要更大的内存空间，因此需要UNIX，因此，您的Web服务器（或者更具体地说是您的应用程序服务器，因为您只提及两层）可能是基于.Net的，因此需要Windows。
好！ 这是事情，你的数据库服务器安装在另一台机器和你的应用程序在Web服务器上更安全。 然后，使用Web链接将应用程序连接到数据库。 感谢它。
