我正在使用 postgre (AWS RDS) 作为我的数据库，并使用节点 (AWS EC2) 作为服务器端。我刚刚开始，所以我没有太多背景知识。我一直使用其他第三方软件，如 Parse for DB，所以我的应用程序通过 Parse API 访问数据库。所以我想我会对 Postgres 做同样的事情。我读得越多，越多的人说我需要一个中间服务器来防止客户端应用程序直接链接到数据库，以保证安全。我理解这一点，因此有了节点服务器。
但后来当我使用节点库时，我意识到从服务器到数据库建立连接非常繁重。在稳定范围内，我一次只能建立 20 个连接。因此，如果我从客户端应用程序直接连接到数据库，那么对于数据库来说，这将过于繁重。
除了安全原因之外，这是人们建议在客户端应用程序和数据库之间使用中间服务器层的主要原因吗？
或者是否存在我不知道的其他技术原因？
答案1
应用程序不能直接连接到数据库的原因很简单：应用程序是您发布的代码，它在您无法控制的地方运行，因此不能信任数据库凭据。
代码可以被逆向工程，凭证可以被发现，现在攻击者可以完全访问您的数据库，并可以执行应用程序有权执行的任何操作。
中间层创建并强制执行一个关键边界：与数据库对话的实体是可以信任的，可以访问数据库，因为除非存在设计缺陷，否则它不会主动对数据库做任何不该做的事情，也不会允许任何人要求它。
所有其他考虑因素本质上都是次要的，因为即使你解决了它们，这个问题仍然存在，迫在眉睫。
答案2
数据库可以位于任何后端服务器上，包括 Web 服务器或任何其他在线服务。
由于Parse不支持PostGres，您将不得不寻找另一个系统来管理您的后端，这也可能会对前端交互产生相当大的影响。
你不应该做的是尝试让前端直接连接到数据库。这样做会给数据库带来巨大的负载，同时也会带来严重的安全问题。
答案3
这可能是一种误解。如今的 Web 应用程序并非简单的两层设置。即使是老牌的 XAMPP、WAMPP 也是控制器（模型-视图-控制器）。
用户不会直接与应用程序的数据库后端交互，他们看到的是 UI，即视图层。后端工作流逻辑是您的代码，即控制器。而您则通过控制器连接到数据库模型。
但是，如果你在视图中引入了一些数据库查询功能，那么你必须清理它们。无论你引入多少“中间层”。
除非你需要高可用性，让你透明地切换后端数据库服务器、负载平衡应用服务器、功能队列服务、服务器扩展等，否则没有理由引入不必要的中间件层。每个中间件都会引入额外的单点故障。
只有在您需要中间件时才引入它们，而不是因为有人说您想要它们。
中间件示例 1：当您有需要与不同数据源通信的复杂逻辑时，使用中间件及其触发逻辑流的规则逻辑比在应用程序内部编写逻辑更好。
中间件示例 2：使用消息队列系统将任务、消息和信息汇集并分发给服务器堆栈，以进行多处理或分布式处理。因此，如果该特定应用程序支持 MQ，那么您甚至不需要连接到数据库，只需连接到 MQ 服务器即可。完成后，您的应用程序将信息发送到另一个队列以通知结果，并让另一个应用程序处理逻辑。
将数据库模型从应用程序控制器逻辑中移开听起来很酷，但有一个最佳平衡点。您需要了解您的业务需求。