.Net 应用程序中的系统架构设计答案

【问题标题】：System architecture design in .Net Application.Net 应用程序中的系统架构设计
【发布时间】：2017-07-10 13:09:28
【问题描述】：

请在下面找到我的一位客户为项目提出的架构图。项目规模很大，目前它使用 SOA 和 ADO.Net（存储过程）进行数据库操作。

我不太愿意使用消息服务，因为它会增加额外的层并可能会产生额外的性能问题。

请在我的以下查询中提供您的意见

(1) 我们当前架构面临的主要问题 - 当一个长时间运行的停止程序正在运行时，它也会减慢其他操作。这就是我们将一个大数据库分成多个数据库的原因。 - 由于应用程序逻辑非常复杂，目前我们有具有复杂查询的存储过程。

(1) 是否可以使用 EF 并完全替换 ADO.Net。如何替换包含大约 20 个表的复杂（或大）查询的存储过程。

(2) 当我们有多个数据库时如何维护横断面，我觉得这会很困难。

(3) 如果可能的话，请您向我推荐一些使用类似架构的示例或应用程序，以便我可以创建一个试点应用程序并使用我当前的数据库对其进行测试。

相反，我更喜欢下面的架构，这是一种微服务架构，其中每个应用程序使用通用存储库和 EF 将数据写入其数据库，并且当应用程序想要相互通信时（即插入/更新/获取数据），然后它将使用消息服务。请告诉我哪种方法更好。

【问题讨论】：

【解决方案1】：

根据我的经验，消息服务实际上已经解决了您在 1) 中遇到的许多问题，这些问题需要长时间运行。

我在之前的大型项目中使用过ActiveMQ 和RabbitMQ 作为消息传递服务。

在一种情况下，我能够通过使用消息传递服务来消除阻塞。因此，业务逻辑没有调用存储过程，而是将作业转储到可以稍后处理的队列中。

在另一种情况下，我能够通过将业务逻辑拆分为相同的工作人员来再次改进这一点。使用消息服务以循环方式将工作分配给每个工人。它实际上是Competing Consumers Pattern 的实现。下面给出了很好的解释：

【讨论】：

【解决方案2】：

项目规模很大，目前正在使用 SOA

这里的关键字很大。大型应用程序往往会在一段时间后变得混乱（紧密耦合），因此分离很重要。

您将如何做到这一点取决于您的团队所知道的和习惯的。

根据我的经验，多年来基于消息传递和 CQRS 构建应用程序往往会站稳脚跟，因为您在物理上分离了业务域，并且 API 比消息传递服务合同更细粒度。

恕我直言，将业务层暴露给 MVC 应用程序是一个错误，因为它可以很容易地将它们紧密耦合。而是从它们调用服务。

服务名声不好，主要是因为人们忘记了他们也应该有一个好的设计。不要让他们成长或成为无所不能的神级。保持它们小而明确。我更喜欢定义业务操作而不是 CRUD 操作的服务，特别是如果您想保护业务层并在数据存储中具有更好的一致性。

【讨论】：