使用内部网络服务而不是直接访问数据库答案

【问题标题】：Use of an internal webservice instead of direct access to database使用内部网络服务而不是直接访问数据库
【发布时间】：2012-11-05 15:12:03
【问题描述】：

我正在设计网络的各个部分。我目前对未来软件项目设计的想法：

DMZ 中的网络服务器。这个网络服务器有一个穿过防火墙的洞（在 sql 端口上）与一个 MSSQL 数据库对话，该数据库是所有数据管理的内部。

问题：与其在防火墙中设置一个孔来与数据库服务器通信，不如让一个内部 Web 服务器托管 DMZ 中的应用程序可以使用的 Web 服务会更好/更安全，数据库逻辑在网络服务（一个只与该网络服务器对话的漏洞。）

Web 服务实现将只允许在一个地方更新任何 API 更改 - 这就是我考虑它的原因 - 尽管它可能会比直接数据库和查询访问要慢。

关于哪个更好的想法？

编辑：意识到除非我将所有应用程序/业务逻辑放在应用程序层中，否则我仍然需要在 sql 防火墙上打一个洞。由于我只想为 API 函数添加一个层（影响所有应用程序的那些 - 例如“GetEmployeeByName”），我仍然需要从 DMZ 访问数据库...

倾向于最佳答案是：托管 Web 服务的内部 Web 服务 API 服务器 - 这些服务可由 DMZ 中的所有 Web 服务器或通过 DMZ 中的代理服务器使用。（所以只有一台服务器需要一个通过防火墙的 ssl 端口。）（当然所有内部服务器都可以访问。）

【问题讨论】：

层不必对应于单独的机器。如果您正确设计应用程序，“应用程序层”是否在同一台机器上、是否通过 Web 服务横向扩展都无关紧要。
如果我选择其中一个、直接 db 访问或应用程序层（防火墙规则仅适用于其中一个），所有需要数据库的逻辑都必须位于单独的服务器上，因为只有数据库访问位于防火墙的另一端。
这是一个实施决策，而不是设计决策。设计您的应用程序，使任一实现都可以工作而无需重写。

【解决方案1】：

关于三层架构何时是更好的模型有很多讨论（here's one）。您应该可以在 Google 上找到更多信息。

简短回答：如果您的目标是安全性和可扩展性，那么使用应用层服务可能会更好。在开发所有层级和层级时，请务必关注defense in depth。

长答案：这取决于您的需求。

编辑以响应您的编辑：如果这样做有意义的话，我建议您将大部分业务逻辑放在应用程序层中。您的网络服务器应该主要用于演示。不过，无论您将业务逻辑放在哪里，都应该将所有数据访问权限放到服务中 - Web 层应该只与应用层对话。

Here 是一个开始搜索以深入研究三层方面。 Here 是关于分层和诸如此类的一个不错的介绍。

【讨论】：

谢谢。这取决于你，但如果你有意见，我不会介意根据我所做的编辑。您链接的文章很有帮助，因为谷歌搜索对我不起作用（我真的不知道要搜索什么）
@DFTR：已编辑以回答您的进一步问题。
我正在考虑复杂性，从必须编写服务和编写代码来使用它们，以及通过以 Web 服务的形式将整个业务层置于防火墙后面来请求时间。我必须进行一些测试，看看我喜欢什么 - 无论哪种方式，感谢您提供最有帮助的答案。
@DFTR：我通常发现为它创建 WCF 服务和客户端非常快。祝你好运！