使用 NServiceBus 和 REST API 的应用架构答案

【问题标题】：App architecture with NServiceBus and REST API使用 NServiceBus 和 REST API 的应用架构
【发布时间】：2016-07-10 22:29:54
【问题描述】：

我们正在努力替换使用 SQL 后端的旧 VB6 系统。大多数业务逻辑都在存储过程和触发器中。我们目前有一些 NServiceBus 功能，通过使用数据库中的触发器将消息放入队列 (SQLTransport)。

我想构建一个新的干净 api，它在后台使用所有相同的表和存储过程。一旦所有的应用程序和服务都使用了新的 api 和消息系统，那么我们就可以开始清理后端了。

新的前端将调用 REST api 来检索数据。我正在努力解决的问题是执行创建/更新/删除数据的操作的最佳实践。对于不需要立即响应的自动化流程，他们只需通过总线发送命令即可。但是，对于将使用该应用程序的最终用户，他们期望立即获得结果。如果某事导致消息转到 FLR/SLR，那么客户坐在那里期待某事发生显然是不可接受的。

一个想法是有一个库来处理对数据库的所有调用，API 和任何 NServiceBus 消息处理程序都可以使用它。我看到的问题是操作何时需要发布事件。从消息处理程序中，可以简单地发布消息。如果我正在处理来自 REST api 的简单命令，我不能只发布相同的事件（因为没有任何东西订阅 REST api，它可能是。

一种解决方案可能是让 REST api 向端点（其他端点订阅的那个）发送（而不是发布）一条消息，然后将事件发布给所有订阅者。

其他人是如何实现这样的？我正在考虑的主要用例是简单的创建/更新/删除操作，客户端期望从这些操作中获得实时结果，但后端可能需要发布一个事件来指示发生了某些事情。

【问题讨论】：

docs.particular.net/nservicebus/hosting/…
谢谢，我已经读了好几遍了。它谈到了我提到的“鉴于这些事实，传统观点认为，在 Web 应用程序的上下文中，最好只将命令发送到后端服务端点，然后该端点可以发布类似的事件。”但它还谈到的另一个选择是能够拥有一个单独的订阅管理器端点，并且 Web 应用程序共享相同的订阅存储。

标签： asp.net-web-api architecture nservicebus

【解决方案1】：

您所描述的是一个挑战，我不会在这里尝试提供解决方案，但是，有几个指针......

同步通信（同一通道上的请求/响应）与消息传递是正交的，消息传递的通信方式是一劳永逸。

CQS (Command Query Separation) 的概念通过状态更改操作不回复已更改状态的数据，因此读取操作在单独的通道上完成，这对于使用消息传递构建系统是一个很好的指南。

另外，我会避免将消息用于读取操作（使用直接 ADO）。

CRUD 操作是一种味道（我知道这是遗留代码库），因为这些操作隐藏了任何意图或业务价值。

您最终会得到的解决方案可能是消息传递和同步通信的混合（我假设您此时没有尝试从头开始重写）

我很乐意进行更深入的讨论（给我发电子邮件至 special.net 的 sean.farmar）

【讨论】：

谢谢，肖恩。我会伸出援手。我同意消息传递不适合读取操作，REST api 将简单地使用 ADO 从数据库中读取。我试图弄清楚对于需要触发和忘记的后端服务以及期望实时结果的用户来说，一切如何发挥得很好。
我想强调 Sean 他的论点：避免将消息用于读取操作，如果调用方是 UI 或阻塞操作，则不要对消息进行查询。这是一个非常常见的坑。尽可能原生查询，添加将 JSON 转换为 SQL 的 API 只是添加了转换层。层数越少越好。