标签: nservicebus

我想知道是否可以使用nServiceBus订阅所有类型的消息而不指定发布者的终点.

背景为此,是一种分布式算法,它使用nServiceBus的分发器infra结构将子问题委托给网络上的分布式工作者.

任务完成后,工作人员应发送消息通知发件人.

我可以使用IBus.Reply()来通知它,但我也有一些监视和日志记录服务,它们也对这些消息感兴趣.使发送者重新发布所有收到的回复都听起来不对.

我可以在nServiceBus中订阅来自多个发布者的消息吗？

我知道它可以从MSMQ 3.0开始使用,是否可以通过任何.NET ESB获得？这可能与其他MQ传输(ActiveMQ等)有关吗？

谢谢,E.

有没有理由不在IMessagesaga数据中重用NServiceBus消息()？我的意思是有这样的消息:

public class Order : IMessage
{
   public virtual List<TillOrderLine> OrderLines { get; set; }
}

public class TillOrderLine : IMessage { ... }

然后在像这样的传奇和传奇数据中使用它:

public class OrderProcessingSaga : 
    Saga<OrderProcessingSagaData>, 
    IAmStartedByMessages<Order> { ... }

public class OrderProcessingSagaData : ISagaEntity
{
   public virtual Guid Id { get; set; }
   public virtual string Originator { get; set; }
   public virtual string OriginalMessageId { get; set; }

   // The message data is stored by the saga here.
   public virtual Order Order …

我们最近将NServiceBus从Community升级到Commercial,并获得2核许可.当我查看示例和在线时,我只看到1个工作线程的配置.

商业NServiceBus的每个核心工作线程的建议数是多少？或者是否有多个工作线程给定系统内存/处理器资源的数量？或者这是我需要调整的东西,直到找到"甜蜜点"？

我正在尝试将我们的大球体系结构中的一些部分分离,并确定了几个明显可以选择使用CQRS来提供更具弹性和可扩展性的解决方案的边界.

典型示例:当客户下订单时,我们在订单提交付款时批准其线程,由销售系统批准等等.

这可以全部异步处理 - 允许我们在支付处理系统不可用时接受和排队订单等 - 但我不确定如何管理客户的UI数据.

换句话说 - 他们下订单.他们的订单排在队列中.如果他们在五秒钟后重新登录帐户并点击"查看订单" - 会发生什么？

• 如果我从中央仓库(或从基于该仓库更新的缓存)中抽取它,那么用户将不会看到他们的订单并且可能会尝试再次放置它 - 或者给我们打电话和恐慌.
• 如果我从本地数据库中绘制它,那么我有维护另一个订单数据库的开销- 这需要在负载均衡的环境中同步,并且似乎破坏了CQRS的许多优点.

我想在很多地方做这件事 - 而且并非所有这些行动都像确认订单一样重要; 在某些情况下,它就像客户更改电话号码一样简单 - 所以他们并不是所有我只能说"非常感谢,我们会向您发送确认电子邮件"的情况 - 因为发送确认电子邮件每次修改记录的邮件都让我觉得有些过分.

我应该看看任何模式或解决方案来帮助解决这个问题？

我需要允许多个客户端(winforms应用程序)通过Internet(远程位置)连接到服务器,并启动双工通信,有时会发送大量流量.

目前,我们通过netTcpBinding与WCF使用双工通信,使用我们自己的证书在传输层上进行保护.虽然这有效,但我关注的是一些事情:

• 设置很麻烦 - 我们为每个客户端创建一个证书,以便与服务器进行识别,并且需要在客户端计算机和服务器上为每个客户端注册证书
• 因为我们在特定端口上使用tcp,所以我们依赖于在客户端打开的那部分,以便它可以通过tcp启动通信.有些客户位置不喜欢这样.
• 我们需要能够保证理想的交付

作为替代方案,我想知道使用wsDualHttpBinding,使用单个SSL证书来保护它,并让每个客户端发送某种标识符来标识自己.这会解决防火墙问题,并且它会比http而不是tcp足够高效吗？据我所知,如果你使用http(因为http不支持双向通信),WCF将创建2个频道而不是一个 - 所以听起来它可能会导致一些性能问题.

我的问题是,这个解决方案是否更好,还是有其他解决方案(如NServiceBus)可以使这更容易并解决这些问题？

编辑

我已经知道wsDualHttpBinding不适合我,因为:This binding requires that the client has a public URI that provides a callback endpoint for the service.这对我来说是不可能的.

在此配置中使用NSB 4:

Configure.With()
    .DefaultBuilder()
    .XmlSerializer()

给出此错误警告

'NServiceBus.ConfigureXmlSerializer.XmlSerializer(NServiceBus.Configure, string, bool)' 
is obsolete: 'Please use 'Configure.Serialization.Xml()' instead. Will be treated as an 
error from version '5.0'. Will be removed in version '6.0'.'

该怎么Configure.Serialization.Xml()用？

我正在尝试找到一种方法来按照发件人发送的顺序处理邮件,因为NServiceBus不保证邮件将按特定顺序处理.

发件人是一个发布createOrder和reviseOrder命令的订单系统.发件人允许用户向同一订单提交多个修订版,因此队列中可以同时包含修订版4和修订版3.每个修订版都有一个与之关联的修订号和原因代码,这些代码驱动了一些业务逻辑,因此我们不能忽略任何修订或至少部分原因.

我有几个想法如下 -

1. 将修订号存储在目标记录中.发件人在每个修订消息中发送其修订号.处理程序比较发件人和目标修订号,如果匹配,则更新记录,否则将消息放在队列末尾.使用此方法,如果修订版2消息失败并进入错误队列,则永远不会处理修订版3.

2. 发件人发送每个修订消息的所有修订的所有原因代码的历史记录.因此,如果修订版2消息失败,则修订版3消息将具有所有原因代码.这些原因代码将记录在目标中,但可能不会出现与先前修订原因代码相关联的任何业务逻辑.

我们如何为这种情况设计？
还有关于如何处理失败的修订消息的任何想法？

一些指导非常感谢.

谢谢.

当前设置

我们有一个UI(超过1个UI,但这不相关),我们有2个负载均衡的应用服务器.这样的UI将与别名对话,后面是2个负载均衡器应用服务器.应用服务器也是自托管NServiceBus端点.处理当前请求的应用服务器(可能是App Server 1或App Server 2)能够使用自托管的NServiceBus执行以下操作:

• 在本地发送消息(这是一个可以随时运行的计算,无论谁触发它,它只是一个触发器来进行计算)
• 在辅助服务盒上向发布者发送命令(发布者将新事件推送到工作者1和工作者2)
• 直接在辅助服务框上向Worker 1发送命令
• 直接在辅助服务框上向Worker 2发送命令

"App Server(s)"当前的App.Config

因此,每个应用服务器的App.Config都有这样的东西

  <UnicastBusConfig ForwardReceivedMessagesTo="audit">
    <MessageEndpointMappings>
      
      <add Assembly="Messages" Type="PublisherCommand" Endpoint="Publisher" />
      <add Assembly="Messages" Type=" Worker1Command" Endpoint="Worker1" />
      <add Assembly="Messages" Type=" Worker2Command" Endpoint="Worker2" />
      <!-- This one is sent locally only -->
      <add Assembly=" Messages" Type="RunCalculationCommand" Endpoint="Dealing" />
    </MessageEndpointMappings>
  </UnicastBusConfig>

"发布者"当前的App.Config

目前是"发布者"App.Config

<UnicastBusConfig ForwardReceivedMessagesTo="audit">
  <MessageEndpointMappings>
  </MessageEndpointMappings>
</UnicastBusConfig>

"工人"当前的App.Config

目前工作者App.Configs目前只需要订阅另一个端点"Publisher",他们的配置文件如下所示:

<UnicastBusConfig ForwardReceivedMessagesTo="audit">
  <MessageEndpointMappings>
    <add Assembly="Messages" Type="SomeEvent" Endpoint="Publisher" />
  </MessageEndpointMappings>
</UnicastBusConfig>

现在,所有其他发送给工作人员的消息都直接来自其中一个应用服务器,如上面App.Config中针对应用服务器所示.

这一切都正常.

事情是我们有一个单点的失败,如果"辅助服务盒"死了,我们就塞满了.

所以我们想知道我们是否可以使用多个"辅助服务盒(每个都有一个Publishers/Worker1/Worker2)".理想情况下,它们将完全按照上述方式工作,如上图所示.如果"辅助服务箱1"可用,则使用,否则我们使用"辅助服务箱2"

我已经阅读了有关分销商(但没有使用它),如果我说的正确,我们可以在AppServer本身使用,我们将每个AppServer视为分销商和工人(对于案例)在哪里我们需要执行SendLocal命令(RunCalculationCommand)我们需要运行).

如果"辅助服务箱"必须为每个包含的端点使用分销商:

所以我们最终会得到这样的结论:

有人可以帮助我知道我是否正在考虑这种方式,或者我是否离开了.

基本上我想知道的是:

• 经销商是否使用正确的方法？ …

我有一个场景,其中我需要一个nservicebus消息处理程序,以防止同一个saga的多个消息同时被执行.

为了论证的处理程序做这样的事情(在这个例子中过于简化的方式(

信息:

public class MyMessage : IMessage {
  public int OrderId {get;set;}
  public int NewQuantityLevel {get;set;}
}

佐贺:

public void Handle(MyMessage message)
{
    // call remote service to get current order quantity
    // do some logic and update remote service with difference between original and new quantity

    Bus.Send(new MyOtherMessage())
}

现在我是我的流程我可以随时收到2条或更多这些消息,我不想让它们检索可能已经在其他地方更新或修改过程中的订单数量.

我考虑了一些解决方案:

1. 获取订单的互斥锁(目前我们只在一台机器上运行一个工人实例,但将来有可能有多个,在这种情况下我们可能会使用redis锁或类似的东西)
2. 在服务中使用sql锁定对行/数据进行序列化锁定(不确定这是否会起作用)

这些都不是真的看起来最优,而且确实感觉我正在反对这个框架