后端：远程与本地sql数据库

Question

如果您想拥有可处理约200个同时请求的可伸缩后端，那么在与应用程序服务器相同的计算机上拥有（关系）数据库的立场是什么？

我看到大多数人不赞成这种方法，主要有以下几个论点：

• 可扩展性更加棘手
• 安全性（与AppServer和DB在同一环境中一样）
• DB和AppServer的资源竞争
• 单点故障

但是，通过将两者都放在同一服务器上的方法，我仍然看到了很多优点，

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

从我看来，将数据库放置在远程服务器上的问题可能简化了事情并提高了安全性，但是我也看到了其他方法的许多优点，例如出站传输成本。因此，可以肯定地说这是非常实际的情况并且基于您的实际项目需求吗？

（我本来就不会提及Google，AWS，MS Azure的多合一SOA架构，因为它们的成本根本无法使其成为一种选择）。

Answer 1

根据我的理解，这是我在这个问题上的两分钱

在应用程序是新的并且体积和大小都较小之前，可以将数据库与应用程序服务器放在同一盒子上。但是，随着时间的流逝，在此设置中出现了几个问题。您所提到的要点是有效的，但是，从长远来看，在单独的服务器上使用db的好处可能会超过单个服务器的设置。

• 可以通过增加服务器的容量来垂直扩展系统。但是，正如我们所知，在某一点之后，每台硬件成本获得的容量减少了，这意味着与单台机器的硬件成本增加相比，获得的容量增加很少。因此，为了获得具有成本效益的可扩展性，只有横向解决方案是唯一的解决方案。现在，水平运行时，假设添加了更多计算机，并且它们在同一框中包含应用服务器和数据库服务器（具有不同的VM或容器），那么在扩展时，应用服务器和数据库服务器都可以轻松满足不同的扩展需求。需要一个具有更高容量的盒子来处理应用程序和数据库负载。假设添加了另一组盒子来增加容量，但是这会导致提供这些更高容量的盒子，这是浪费的，因为假设仅需要缩放应用服务器，而db很好，反之亦然。相反，如果应用程序服务器和数据库服务器位于不同的盒子上，则可以分别管理扩展。

• 如问题中所述，安全性是另一个问题。应用程序服务器通常面向外部环境，并且更容易受到攻击，如果db位于同一盒子上，它将不必要地面临相同的风险。相反，如果db位于单独的盒子中，则它可以位于防火墙后面，并且根本不暴露于Internet。

• 如果应用服务器或数据库服务器中的任何一个导致系统崩溃，则两个组件都将不可用（单点故障）。

• 每当需要更改系统配置时，都会涉及一些风险，并且如果app和db都在同一盒子上，即使系统更改是组件之一需要。

• app和db组件的I / O，CPU和其他硬件容量要求可能非常不同。并且即使应用了容器化，也可能无法以最佳方式拆分包装箱的资源。相反，如果两个组件分别部署，则进行容量规划要简单得多。

  

因此可以肯定地说这是非常实际的情况，并取决于您的实际项目需求吗？

任何部署都必须始终满足项目的特定需求。话虽这么说，但在大多数情况下，应用程序变得越来越大，以致于无法安装在单台计算机上，通常，根据我的理解，将应用程序和数据库层分开在不同的计算机上比起使用单个安装程序具有更多的实际优势。 >

希望有帮助！