Question

我们有一个应用程序，我将其描述为复杂的。该应用程序是POS终端软件，最初只能在一台计算机上运行，但后来应该可以轻松扩展到许多具有中央（可能是云）存储的计算机：许多客户端终端，具有WCF服务的应用服务器，数据库服务器。

在MVC 4应用程序中，我们想要 A）通过将（业务）逻辑从控制器移动到服务，使控制器在应用程序中保持轻量级。这已经多次在书中写博客和书写，似乎是一种解决问题的“正确”方式。

步骤 B）将通过引入（内存中）应用程序总线来删除控制器与服务之间的耦合。我说在内存中因为我们现在不需要（想要）一个ESB。

因此控制器永远不会直接调用服务。代替：

例如，在LineItemController.cs：

ILineItemDetailService _service;
....
public void CreateLineItemDetail( DetailInfo d )
{
    _service.CreateLineItemDetail( d );
}

......会变得像：

IBus bus;
...
public void CreateLineItemDetail( DetailInfo d )
{
    _bus.Send( new LineItemDetailMessage( d ) );
}

此类LineItemDetailMessage的处理程序将接收该对象，然后调用LineItemDetailService。等等。

我们的要求是速度和可靠性（呃！），因为可以通过总线向服务发送大量数据（每分钟大于1000条消息），最终到达服务数据库中。

我的问题是，由于我们现在不想使用Azure或云服务，以后 Azure 可以轻松替换此类自定义应用程序总线 SB或 NSerivceBus ？

或者你建议“咬紧牙关”和立即行动，使用NServiceBus？

如果我们使用总线（松散耦合）而不是直接调用服务（紧耦合），我们在这里看性能如何？

之前有没有人这样做过，您使用应用程序总线模式的经历是什么？

编写自定义“总线”作为“占位符”以便将来迁移到Azure甚至可行是这样吗？

Answer 1

我建议立即开始使用ServiceBus Server（http://msdn.microsoft.com/en-us/library/dn282144.aspx） - 您可以在运行其他所有内容的同一个Windows框中安装它。

我喜欢Windows Service Bus的一件事是Azure Service Bus（云）和Service Bus Server（OnPremise）之间的对称性。安装ServiceBus服务器并为其设计和编写代码并使用它测试性能要求，然后如果您决定扩展并迁移到Azure Service Bus（在云端） - 只需更改命名空间连接字符串，您就在那里（还需要获取）最新的Service Bus Service SDK Nuget和rebuild - 您将看到零构建问题 - 因为它完全向后兼容）。

使用抽象绝对是一个非常好的主意并且足以用于概念证明 - 但是如果你真的想要查看/理清功能问题或决定性能（延迟和通过）数字，那么显然需要巨大的重新设计和代码流失 - 因为每个系统（总线）都有自己不同的产品形式 - 例如：每个队列的规模数量等。

谢谢！ SREE

Answer 2

NServiceBus提供了您正在谈论的那种IBus抽象。它还有一个单独的传输插件模型，因此您可以根据需要在内部本地运行它，也可以在MSMQ，SQL Server和Azure Service Bus之上运行。

让我重复一遍 - 您可以在NServiceBus下使用Azure Service Bus，只需对配置/初始化代码进行一些小的更改。

通过引入NServiceBus，您不会受到很大的性能影响。即使在完全持久的和事务性的基础架构上运行，您每秒最多可以获得数千条消息 - 远高于您设置的目标。

自定义内存中应用程序总线作为Azure Service Bus的占位符

2 个答案: