数据访问层/服务层对性能有何影响？

Question

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

• 每秒收到约 100 个请求的 Web 服务器。网络服务器只需将数据转储到原始数据存储库中。
• 原始数据存储库有一个表，每秒从网络服务器获取 100 行。
• 一个原始数据处理单元（简单处理，不多。删除无效的原始数据，将丢失的组件插入损坏的原始数据等）
• 处理后的数据存储库

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

Answer 1

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

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

1. 网络读取请求
2. 数据库写入原始数据
3. 数据库读取原始数据
4. 处理数据的数据库写入

再加上一些数据修改。

您想要什么样的服务？也许

• 保存原始数据()
• 获取下一个原始数据()
• 写处理数据()

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

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

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

Answer 2

除非你加以防范，否则可能会发生以下情况。

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

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

当我解决这样的问题时，我使用了 堆栈拍摄技术 并很快发现了问题所在。您可能会认为这是 I/O。不是。大约 80% 的时间都花在将数据转换为 XML 以及解析 XML 以恢复数据结构上。找到更好的方法并不难 那. 。结果 - 速度提升 5 倍。

Answer 3

个人认为在设计系统时可能过于关注底层的实现细节。在考虑如何布局组件、组件或服务之前，您应该考虑如何构建系统。

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

1. 确认开发团队和运营/支持团队的技术技能。
2. 商定将集成到您的服务的系统的初始有限列表、它们支持的协议和一些 SLA。
3. 决定消息传递策略。
4. 了解您将如何部署您的服务/系统。
5. 决定选择中间件（ESB、消息代理等）、数据库（SQL、Oracle、Memcache、DB2 等）和第 3 方框架/工具。
6. 决定您的缓存和数据延迟策略。
7. 将您的应用程序分解为业务职责的各个领域 - 这将使您能够分解工作，并在开发/测试和实施过程中更轻松地沟通里程碑。
8. 根据需要设计每个组件以满足职责范围。职责范围应该自动引导您决定如何设计组件、组件或服务。

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

祝你好运。

Answer 4

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

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