拥有数据访问层/服务层对性能的影响？答案

【问题标题】：Performance impact of having a data access layer/service layer?拥有数据访问层/服务层对性能的影响？
【发布时间】：2011-03-26 09:35:22
【问题描述】：

我需要设计一个具有以下基本组件的系统：

在这样的系统中，有一个服务层来构建所有组件是否有意义？所有组件间的交互都将通过服务层。虽然这将使系统易于升级和维护，但由于我要处理如此多的流量，它不会对性能产生重大影响吗？

【问题讨论】：

【解决方案1】：

除非您提防，否则可能会发生这种情况。

在层之间的通信中，选择了某种格式，例如 XML。然后你构建它并运行它，发现性能并不令人满意。

然后你搞乱分析器这让你猜测问题是什么。

当我处理这样的问题时，我使用了stackshot technique 并很快找到了问题。你会认为它是 I/O。不是。将数据转换为 XML 并解析 XML 以恢复数据结构大约需要 80% 的时间。找到更好的方法来做到这一点并不难。结果 - 加速了 5 倍。

【讨论】：

我们正在考虑使用基于 REST 的 API 进行通信……是的，这可能是以后的问题。感谢您的提醒！
为什么服务层隐含 XML？或任何序列化。服务可以位于同一地点。区分物理部署决策（可能是层）和逻辑分离。例如，从技术上讲，您可以拥有一个具有本地接口（通过引用传递）和远程接口（通过序列化传递值）和 Web 服务接口的 EJB。
@djna：为什么它暗示 XML 或任何序列化？它没有。只是这就是倾向于建造的东西。真的没有办法提前告诉你这样的事情会是一个性能问题，但事后看来，确实是这样。

【解决方案2】：

您认为拥有一个单独的服务层的成本是多少？

这些成本与您必须承担的成本相比如何？在你的情况下，这似乎至少是

加上一些数据处理。

您想提供什么样的服务？也许

为什么开销比过程调用更多？服务不需要暗示“分离进程”或“Web 服务编组”。

我认为结构总是有价值的，应用程序中的关注点分离确实很重要。与数据库活动相比，一些过程调用很少会花费太多。

顺便说一句：原始数据的持久化可能最好在排队系统中完成。然后，如果需要，您可以通过在不同的机器上安装许多队列读取器来获得一些自然扩展。实际上，排队系统自然而然地引入了一些类似服务的概念。

【讨论】：

【解决方案3】：

个人觉得您在设计系统时可能过于关注底层实现细节。在查看如何布置组件、程序集或服务之前，您应该考虑如何构建系统。

您可以从以下高级语句开始，围绕这些语句构建您的系统架构：

显然，并非所有上述内容都符合您的具体情况，但我建议至少应该考虑一下。

祝你好运。

【讨论】：

【解决方案4】：

抽象和分层会引入延迟，但真正的问题是，您要获得什么才能使成本物有所值？松散耦合、治理、可扩展性、可维护性是物有所值的。

即使是设计最好的分层应用程序也会出现比直接与数据库对话的应用程序更多的延迟。了解原系统的用户会感觉到不同。他们可能不喜欢它，所以这可能是一个政治问题，也可能是技术问题。

【讨论】：