database - 后端:远程 vs 本地 sql 数据库

Question

如果您想要一个可以处理大约 200 个并发请求的可扩展后端，那么您对(关系)数据库与应用程序服务器位于同一台机器上的立场是什么？

我看到大多数人都反对这种方法，主要论点如下:

• 可扩展性更棘手
• 安全性(作为同一环境中的 AppServer 和 DB)
• DB和AppServer的资源竞争
• 单点故障

但是，我仍然看到将两者都放在同一台服务器上的方法有很多优势，例如:

• 成本:尤其是导出成本:为我的数据库配备单独的服务器将导致出站传输成本几乎翻倍(一次从数据库到应用服务器，一次从应用服务器返回客户端)。至少对于几乎所有提供商都是如此，他们对您服务器的出站流量收费。如果数据库只是在同一台服务器上，我就不会遇到这个问题。当然，您可以通过有效利用应用服务器的缓存来减少它，但主要问题仍然存在。
• 速度:即使您仍然通过 TCP 访问本地数据库，localhost 也会更快
• 可扩展性:真正的问题在哪里，我可以在自己的 VM 中运行数据库并通过升级硬件并将硬件分配给需要它的 VM 来扩展。或者使用新的 VM/K8s/任何实例水平扩展，即使我的 AppServers 和我的数据库都在同一台机器上
• 相同的资源:同样，通过将两者都放在自己的 VM 中，我可以将硬件资源分配到任何需要的地方 - 完全没有竞争？

在我看来，将数据库放在远程服务器上的问题可能会简化事情并提高您的安全性，但我也看到了其他方法的很多优势，例如出站传输成本。那么可以说它是非常有情境的并且基于您的实际项目需求吗？

(我有意不提及来自 Google、AWS、MS Azure 的一体式 SOA 架构，因为它们的成本根本无法让它们成为一种选择)。

Answer 1

根据我的理解，这是我对这个话题的两分钱:

当应用程序是新的并且直到它的体积和大小相对较小时，将数据库与应用程序服务器放在同一个盒子上是可以的。然而，随着时间的推移，此设置中出现了几个问题。您提到的要点是有效的，但是，从长远来看，将数据库放在单独的服务器上的好处可能超过单一服务器设置。

• 系统可以通过增加服务器的容量来垂直扩展。但正如我们所知，在某个时间点之后，每单位硬件成本获得的容量数量下降，这意味着与单台机器的硬件成本增加相比，实现了一点点容量增加。所以在某种程度上，为了实现具有成本效益的可扩展性，横向是唯一的解决方案。现在，当横向发展时，假设添加了更多机器并且它们将应用程序服务器和数据库服务器都包含在同一个盒子中(具有不同的虚拟机或容器)，当谈到扩展时，应用程序和数据库服务器很容易有不同的扩展需求.需要一个容量更大的盒子来处理应用程序和数据库负载。假设添加了另一组盒子以增加容量，但随后会导致配置这些更高容量的盒子，这将是一种浪费，因为假设只需要扩展应用程序服务器而数据库很好，反之亦然。相反，如果应用程序和数据库服务器位于不同的盒子上，则可以单独管理扩展。

• 如问题中所述，安全性是另一个问题。应用服务器一般都面向外界，更容易受到攻击，如果数据库在同一个盒子上，它会不必要地面临同样的风险。相反，如果数据库在一个单独的盒子上，它可以在防火墙后面，根本不会暴露在互联网上。

• 如果 App 或 DB 服务器中的任何一个导致系统崩溃，则两个组件都将变得不可用(单点故障)。

• 每当需要更改系统配置时，都会涉及一些风险，如果应用程序和数据库都在同一个盒子上，即使系统更改是其中一个组件需要。

• 应用程序和数据库组件的 I/O、CPU 和其他硬件容量要求可能大不相同。而且即使应用了容器化，也未必能够将盒子的资源以最优的方式进行拆分。相反，如果两个组件分别部署，则进行容量规划要简单得多。

So is it safe to say that it's very situational and based on your actual project needs?

任何部署都必须始终满足项目的特定需求。话虽如此，在大多数情况下，应用程序变得越来越大以至于无法安装在一台机器上，通常将不同机器上的应用程序和数据库层分开比根据我的理解进行单一设置具有更多的实际优势。

希望对您有所帮助!