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

Question

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

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

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

Answer 1

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

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

然后你乱用分析器，让你猜测问题出在哪里。

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

Answer 2

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

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

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

加上一些数据处理。

你有什么样的服务理念？也许

• 保存原始数据（）
• 获取下一个原始数据（）
• writeProcessedData()

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

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

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

Answer 3

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

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

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

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

祝你好运。

Answer 4

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

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