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

Question

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

• 一个Web服务器，它将获得~100个请求/秒。 Web服务器只需要将数据转储到原始数据存储库中。
• 原始数据存储库，其中包含一个从Web服务器获取100行/秒的表。
• 原始数据处理单元（简单处理，不多。删除无效原始数据，将丢失的组件插入损坏的原始数据等）。
• 已处理的数据存储库

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

Answer 1

除非你防范它，否则会发生什么。

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

然后你弄乱了分析器，让你猜测问题是什么。

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

Answer 2

您认为拥有单独服务层的成本是什么？

这些费用与必须招致的费用相比如何？在你的情况下，似乎至少

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

加上一些数据。

您有什么样的服务？也许

• saveRawData（）
• getNextRawData（）
• writeProcessedData（）

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

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

顺便说一句：原始数据的持久性最好是对排队系统进行。然后，如果需要，可以在不同的计算机上安装许多队列读取器，从而获得一些自然扩展。实际上，排队系统自然会引入一些类似服务的概念。

Answer 3

在设计系统时，个人觉得您可能过于关注低级别的实现细节。在研究如何布置组件，组件或服务之前，您应该考虑如何构建系统。

您可以从以下高级语句开始，从中构建系统体系结构：

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

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

祝你好运。

Answer 4

抽象和分层会引入延迟，但真正的问题是，你有什么收益才能使成本值得？松耦合，治理，可扩展性，可维护性是值得的。$。

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