在不暴露后端的情况下在前端和后端站点之间进行有效通信答案

【问题标题】：Efficiently communicating between frontend and backend sites without exposing backend在不暴露后端的情况下在前端和后端站点之间进行有效通信
【发布时间】：2016-10-08 17:08:25
【问题描述】：

在进一步开发此设计之前，我正在尝试弄清楚我当前的方法是否会导致我在未来遇到性能问题，以及是否有更好的方法来做到这一点。如果我首先提供一些关于设计的背景信息，我认为这是最有意义的：

当前设计

我目前的环境设计有两个独立的服务器，我们称它们为前端和后端。

前端

此服务器向全世界开放。客户访问此网站以查看我们的产品、进行购买，并且很快就能查看他们的帐户相关信息。
后台

此服务器是所有信息都保存在数据库中的地方。

通讯

前端当前需要访问后端的唯一方法是用户使用他们的许可证进行身份验证并下载我们的产品。为此，前端调用 PHP 脚本，该脚本通过 curl_exec 向后端服务器发送 JSON 请求。来自后端的响应告诉前端如何处理该下载请求（例如许可证无效）。

推理

这种设计的原因是为了避免将后端细节暴露给用户。在客户端，用户看到的只是一个发送到前端服务器的请求。如果前端服务器遭到入侵，任何阅读前端如何构建的人都无法访问后端数据库，除非他们确切知道要发送到后端 API 的参数。即使这样，它也只能访问非常少的信息子集，具体取决于 API 公开的内容。

问题

这种跨服务器通信现在唯一发生的情况是用户尝试使用他们的许可详细信息下载我们的产品。相对来说，两台服务器之间通过这个API的流量比较低。

我担心的是我想构建一个用户“控制面板”。从这里，他们可以使用他们的许可证/帐户登录，他们可以查看他们的活动许可证，访问他们以前订单的详细信息等。这已经意味着所有这些信息只能通过后端获得，所以我需要通过 API 公开它们——这很好。这里的问题是用户通过控制面板发出的每个请求（即使只是刷新页面）都会在两个服务器之间建立大量流量。

问题

从这里开发人员的经验来看，这种通信设计是否可扩展？我担心我正在围绕瓶颈进行构建，这只会导致用户界面缓慢，因为前端最终会等待大量通过隧道传送到后端的请求。

你的想法是什么？有没有人遇到过类似的挑战？你是如何克服这个挑战的？实现这种要求的最佳实践是什么？我希望这个问题不会让人觉得太含糊。

【问题讨论】：

标签： php ajax database rest architecture

【解决方案1】：

我很想听到其他答案，但我会分享我的想法。

首先，让我们调用您的服务器：

应用服务器
数据库服务器

您似乎担心由于数据库查询量的增加而造成瓶颈。由于您提到这些查询将在页面刷新后执行，很明显您没有使用任何类型的缓存。如果您可以缓存数据库查询并仅在数据发生更改时使缓存无效（即用户的操作导致数据更改，因此应清除缓存），那么您将大大提高性能。

如果任何人获得对您的应用程序服务器的访问权，他们很可能能够以您允许应用程序服务器使用的用户访问数据库服务器。您应该尽可能少地授予该用户使用 API 所需的权限。不过，根据您的 API 允许的内容以及您在应用服务器上缓存的内容，他们可能能够访问很多内容。

查看Laravel's cache API，它允许您使用缓存代替数据库查询。如果缓存不存在，将执行并缓存数据库查询。然后，您将根据用户操作删除必要的缓存。您还可以异步重新缓存数据库请求，以便在响应不需要数据时不会阻止对客户端的响应。

我希望这会有所帮助。

更新：

在与您进一步讨论后，我更好地理解了您的困境。您正试图通过要求所有 API 调用在 POST 请求后执行额外的步骤来提高应用程序的安全性。我同意随着应用程序的扩展，这将成为一个瓶颈，因为您将无法利用缓存，并且每个页面请求都会导致数据库查询。

我在类似情况下所做的是将应用程序服务器和数据库服务器分开，除了数据库服务器实际上只是一个没有任何逻辑/脚本的数据库服务器。例如，PHP 甚至没有安装在数据库服务器上。数据库服务器和应用程序服务器只能通过私有网络连接，因此数据库服务器只能通过应用程序服务器访问。已设置安全用户来使用远程数据库。

由于我的数据库查询需要很多时间，所以我尽可能多地缓存。

还可以考虑使用https://cloudflare.com 它是应用服务器的反向代理，它在客户端（浏览器）和您的应用服务器之间添加了另一层。这样，只有 cloudflare 可以访问您的应用服务器，并且只有您的应用服务器可以通过您创建的安全数据库用户访问您的数据库服务器。

【讨论】：

首先感谢您的想法。我对瓶颈的关注不一定是数据库查询。更重要的是应用程序和数据库服务器之间的通信，通过两台服务器上的 PHP 脚本之间的 POST 请求。我的目标是不向应用服务器公开数据库详细信息，而是将其委托给数据库服务器上的脚本，应用服务器将“任务”发送到该脚本。
我担心从应用服务器脚本到数据库服务器脚本的这些 POST 请求将开始被数据库服务器的 Web 服务器持有或限制，因为这实际上意味着应用服务器的 IP 正在发送大量数据对数据库服务器的请求。这有意义吗？
这对我来说还没有意义。您是否还关心大量 POST 请求或其他类型的请求？缓存对 POST 请求没有帮助，但在我看来，您正在使用控制面板功能添加大量 GET 请求——这对缓存有很大帮助。
在我在这里遵循的设计中，来自控制面板功能的 GET 请求是对应用程序服务器上的 PHP 脚本的，但如果我想保持数据库服务器隔离，这个应用程序服务器 PHP 脚本然后会向数据库服务器的 PHP 脚本发出 POST 请求，以获取或放置它需要的信息。
这实际上是一个非常有趣的观点。这有效地掩盖了我的前端 Web 服务器的真实 IP。如果有人破坏服务器并尝试编写使前端与数据库通信的 PHP 脚本，我将需要研究是否可以使用权限来防止数据库转储或将行限制为最大数量。

【解决方案2】：

我不是数据库专家，但使用prepared statements 会对你有很大帮助，因为它更安全，而且最好的部分是..

“绑定参数最小化服务器带宽，因为您每次只需要发送参数，而不是整个查询”

希望对你有帮助！

【讨论】：

准备好的语句是我需要实现的一个很棒的概念。谢谢你。虽然如果我打开对前端服务器的直接后端数据库访问，我仍然担心如果前端受到破坏，并且找到了数据库凭证，有人可以通过在前端制作脚本/编辑一个脚本来转储整个数据库现有的。我需要研究如何进一步锁定它，以减少发生这种情况的可能性。