我需要在Azure Service Bus和RabbitMQ(在Azure上部署)之间为企业级应用程序做出决定,我的主要用途是主题(具有持久存储).我发现,与RabbitMQ相比,服务总线具有更多功能,如Retries Count,TTL,会话和事务等.但我不确定哪一个最适合高可用性,可扩展性,存储和吞吐量.服务总线对存储大小有一些限制(非分区队列最大为5 GB,分区队列最大为80 GB),吞吐量为2000 msgs/sec/queue.如果在服务总线的情况下我需要更多这些限制怎么办？

RabbitMQ的限制尚不清楚,因为它取决于集群.如果有人能帮我决定哪一个在我的情况下是最好的？

我们想为服务总线消息触发器编写单元测试。我们正在使用Azure.Messaging.ServiceBus nuget 包

     [FunctionName("serviebustrigger")]
  public async Task Run ([ServiceBusTrigger("xxxxtopic", "xxxxsubscription", Connection = "Abs-Connection", AutoCompleteMessages = false)] ServiceBusReceivedMessage message, ServiceBusMessageActions messageActions)

    {
        _logger.LogInformation($"{nameof(Run)} execution started for MessageId:{{MessageId}}", message.MessageId);
        try
        {
                //some code
             await messageActions.CompleteMessageAsync(message);
        }
        catch (Exception ex)
         {
             await messageActions.DeadLetterMessageAsync(message);
         }
    }

现在我想为上面的代码编写单元测试。但我无法模拟ServiceBusReceivedMessage 和 ServiceBusMessageActions ，因为它们具有内部构造函数。有人可以建议我更好的方法来编写单元测试

我们在项目中使用服务总线队列.当管理员选择清除队列时,我们需要一种功能来从队列中删除所有消息.我在网上搜索但找不到任何在QueueClient课堂上做这个的功能.

我是否必须逐个弹出所有消息,然后将它们标记为完成以清除队列或者有更好的方法吗？

QueueClient queueClient = _messagingFactory.CreateQueueClient(
                              queueName, ReceiveMode.PeekLock);

BrokeredMessage brokeredMessage = queueClient.Receive();

while (brokeredMessage != null )
{
    brokeredMessage.Complete();
    brokeredMessage = queueClient.Receive();
}

我了解Azure Service Bus具有重复的邮件检测功能,该功能将删除它认为与其他邮件重复的邮件.我想使用此功能来帮助防止一些重复传递.

我很好奇的是服务如何确定两条消息实际上是重复的:

• 考虑了哪些消息属性？
• 是否考虑了消息的内容？
• 如果我发送两条具有相同内容但不同消息属性的消息,它们是否被视为重复？

我有一个Azure辅助角色,负责检查4个服务总线队列.目前,我只是循环方法来手动检查队列.

while(true)
{
    //loop through my queues to check for messages
}

Azure SDK 2.0具有监听消息而不是轮询消息的能力.但是我见过的每个例子都使用Console.ReadKey()的控制台应用程序.有没有办法让工作者角色坐下来等待消息呢？

我试过了:

public override void Run()
{
    _queueProcessors.ForEach(x => x.OnMessage(Process);
}

其中_queueProcessors是QueueClients的列表,而Process是处理消息的私有方法.但是,worker角色会注册它们然后重新启动.

所以任何人都知道如何让队列客户端坐下来等待消息？

我试着去谷歌.Microsoft Connect不接受Service Bus的错误.Azure门户发送到MS论坛或StackOverflow - 所以我在这里.

问题实际上在标题中:如何报告服务总线的错误？
(不是Azure版本,而是您在本地安装的版本)

这是问题所在:

1. Microsoft.Cloud.ServiceBus.dll有参考Microsoft.Cloud.Common.AzureStorage.dll.它使用该程序集中的一种类型 - 即StorageAccountInfo.它是配置部分(即NamespacePolicyDataStoreFactorySection.Parameters.BlobStorageAccountInfo)的一部分,但显然只在Azure环境中有意义,并且从未在内部部署场景中使用过.
2. 但这里有一个问题:Microsoft.Cloud.Common.AzureStorage.dll服务总线1.1实际上没有附带.我试图在各种SDK和Azure工具包,样本和诸如此类(我有很多)以及在线等方面找到它 - 并找到有关该DLL的zippo信息或从何处获取它.这是我发现它的唯一地方.
3. 虽然它本身就是一个WTF,但DLL的缺失并不能真正阻止任何工作:该类型实际上并没有被内部部署的任何代码所触及,因此没有任何抱怨.
4. 但这是第二个问题:mscorlib.dllv4.6.7.0(与VS2015 CTP5一起提供)与之前的版本4.0.30319.34014相比略有变化System.Attribute.InternalGetCustomAttributes(PropertyInfo,Type,bool),更确切地说,这一行.这条线在以前的版本中不存在mscorlib,一切都很好.但现在它确实存在,导致属性类型被触及,这导致加载DLL失败,因为DLL不存在.
5. 所以整个过程从加载配置部分开始,其NamespacePolicyDataStoreFactorySection工作原理如下:

  ConfigurationManager.GetSection -> 
  ... -> 
  BaseConfigurationRecord.GetSectionRecursive -> 
  ... -> 
  BaseConfigurationRecord.CallCreateSection -> 
  MgmtConfigurationRecord.CreateSection -> 
  ConfigurationElement.Reset -> 
  ConfigurationElement.get_Properties -> 
  ConfigurationElement.PropertiesFromType -> 
  ConfigurationElement.CreatePropertyBagFromType -> 
  Attribute.GetCustomAttribute (for property BlobStorageAccountInfo of type StorageAccountInfo) ->
  ... ->
  Attribute.InternalGetCustomAttributes(PropertyInfo) ->
  Attributes.GetIndexParameterTypes ->
  RuntimePropertyInfo.GetIndexParameters ->
  ... -> …

是否有办法从 Azure 门户中的 Azure 服务总线队列中删除/清除活动/死信消息？目前，我们已经向队列发送了几条消息，而活动消息和一些死信消息都毫无意义地保留在那里，并且我们的服务总线订阅者没有以某种方式触发，因此我们想删除这些消息以使我们的队列又干净了。为了等到服务总线在过期后删除这些消息，我们可以自己手动删除它们吗？

我们在使用有速度问题Azure的服务总线中继既netTcpRelayBinding和basicHttpRelayBinding.对于小消息大小(10K),中继以低延迟(100ms)运行,但随着消息大小增加(100K),我们经历看似随机的响应时间(600ms-1000ms).我们希望改善较大邮件的延迟成本.

是否正在使用通过服务总线中继支持的消息压缩(gzip,protobuf-net等)？有没有人通过中继启用请求/响应压缩成功？通过IIS支持响应压缩是微不足道的,但我们希望支持请求压缩以提高延迟成本.由于我们无法用Fiddler来描述中继,我们如何知道消息在通过中继时仍然被压缩？

我们发现一个有趣的观点是,在后续消息中继(2s)之间引入延迟,我们可以获得更好的性能(100K - 200ms).可能是更大的消息被自动限制？知道触发限制条件的消息大小截止值会很高兴.

对于我们的测试 - 我们只是向服务中继发送一个随机消息字符串,并从服务器回送请求字符串.我们尝试了来自多个地理位置的此客户端/服务器(以排除防火墙/ Web过滤器问题)并遇到相同的延迟行为.

服务器端

public class ServiceRelayProfiler : IServiceRelayProfiler
{
    public string HelloProfiler(string name)
    {
        return string.Format("Hello {0}", name);
    }
}

客户端

ChannelFactory<IServiceRelayProfiler> channelFactory = new ChannelFactory<IServiceRelayProfiler>("helloProfilerTcp");
IServiceRelayProfiler channel = channelFactory.CreateChannel();
string message = RandomString(100000); // 100K
for (int i = …

我们已经开始研究使用Windows Azure Service Bus作为我们当前队列的替代品,因为我们正朝着面向服务的架构迈进.

大多数文件都很清楚; 但是我很难确定哪种类型的序列化BrokeredMessage在提供身体时使用.

例如,假设我实例化一个BrokeredMessage对象如下:

ICommand sendMessageCommand = new SendMessageCommand
{
    Title = "A new message title",
    Body = "A new message body"
};

BrokeredMessage brokeredMessage = new BrokeredMessage(sendMessageCommand);

queueClient.Send(brokeredMessage); 

SendMessageCommand是一个标有[Serializable]属性的简单DTO ; 在我们的旧队列中,这是二进制序列化的,因此它可以更快地存储并保留其元数据.这对我们很重要,因为我们使用队列使用此处概述的模式发送命令,接收工作者角色使用泛型和动态类型的混合反序列化命令.

但是根据这篇文章,正文传递给了BrokeredMessage"Binary XML Serialized" 的构造函数.我的假设是,这是标准的XML序列化,然后通过二进制格式化器,是正确的吗？

除此之外; 这是否意味着如果我要使用默认的BrokeredMessage邮件正文功能; 我必须确保所有对象都是XML Serializable,包括所有出现的问题？(私有字段丢失,没有使用泛型反序列化的元数据,xml序列化属性)

最后; 如果是这样的话; 有一个简单的方法吗？我正在考虑做我们自己的二进制序列化,然后将byte[]属性存储在BrokeredMessage.

我已经开始使用Azure中的Azure Service Bus了.通过Internet浏览了一些引用,似乎人们在Microsoft.ServiceBus.Messaging中使用BrokeredMessage类而不是在Microsoft.Azure.ServiceBus中使用Message类.

• BrokeredMessage类:https://docs.microsoft.com/en-us/dotnet/api/microsoft.servicebus.messaging.brokeredmessage?view=azure-dotnet
• 消息类:https://docs.microsoft.com/en-us/dotnet/api/microsoft.azure.servicebus.message？view = azure-dotnet

我可以将两种消息"类型"发送到Azure Service Bus,也可以通过Azure Service Bus使用它们.此外,两者都可用于异步操作.这两种类型的主要区别是什么？

[更新]本文介绍了在交换代理消息时的Azure Service Bus的最佳实践(https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-performance-improvements).我不确定它是否也被引用到Microsoft.Azure.ServiceBus中的Message.