.Net应用中的系统架构设计

Question

请找到下面的架构图，我的客户之一已经提出了一个项目。项目的规模相当大，目前它使用ADO.Net(存储过程)进行数据库操作。

​

​

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

请提供您对我以下问题的意见。

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

(1)用EF完全替代ADO.Net是否可行？如何替换包含大约20个表的复杂(或大型)查询的存储过程。

(2)当我们有多个资料库时，如何维持横断面，我认为这是很困难的。

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

相反，我更喜欢下面的体系结构，它是一种微服务架构，其中每个应用程序使用通用存储库和EF将数据写入其数据库，当应用程序希望彼此对话时(即插入/更新/获取数据)，则使用消息传递服务。请告诉我哪种方法更好。

​

​

Answer 1

根据我的经验，消息传递服务实际上解决了您在长时间运行过程中看到的许多问题。

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

在一个场景中，我能够通过使用消息传递服务来消除阻塞。因此，Business没有调用存储过程，而是将作业转储到一个队列中，该队列可以在稍后处理。

在另一个场景中，通过将Business分解为相同的工作人员，我再次改进了这一点。乔布斯被分发给每一个工人在轮回罗宾时尚使用信息服务。它实际上是Competing Consumers Pattern的一个实现。以下是一个很好的解释：

https://www.rabbitmq.com/tutorials/tutorial-two-python.html

Answer 2

项目规模相当大，目前使用的是SOA。

这里的关键词很大。大应用程序往往会在一段时间后变得混乱(紧密耦合)，因此分离非常重要。

你将如何做这取决于你的团队知道什么，并对什么感到舒服。

在我的经验中，在构建基于消息传递和CQRS的应用程序方面，随着业务域的物理分离，以及API比消息服务合同细得多，这些年来往往站不住脚。

将业务层暴露给MVC应用程序是一个错误，因为它使得将业务层紧密地连接在一起变得很容易。相反，从它们调用服务。

服务声誉不好，主要是因为人们忘记了他们也应该有一个好的设计。不要让他们成长，也不要成为能做任何事的神类。保持他们的小和明确的定义。我更喜欢定义业务操作的服务，而不是CRUD操作，特别是如果您希望保护业务层，并且在数据存储中具有更好的一致性。