只是一个关于Azure应用程序的快速问题 . 如果我有许多需要通信的Web和Worker角色，文档说要使用Azure队列服务 .
但是，我刚刚读到新的.NET Service Bus现在也提供了队列 . 这些看起来更强大，因为它们似乎提供了更加详细的API . 虽然.NSB看起来更有趣，但它有几个问题让我在分布式应用程序中使用它时会很谨慎 . （例如，Queue Expiration ...如果我不能保证队列将按时更新，我可能会失去它！） .
有没有人有任何经验使用这两种技术中的任何一种，并且可以提供何时选择其中一种的建议 .
我怀疑虽然服务总线看起来更强大，但我的用例实际上只是让Web / Worker角色能够相互通信，Azure Queue Service就是我所追求的 . 但是我真的在寻找确认之前，然后自己进入角落:-)
提前致谢 .
更新
在休息时间读了两个系统 . 它看起来像.NET服务总线更专门用于集成系统，而不是提供通用的可靠消息系统 . Azure队列是分布式的，因此可靠且可扩展，其中.NSB队列不是，因此更适合Azure本身托管的代码 .
谢谢你的回复 .
6 回答
我建议您坚持使用Azure Queues在Web和辅助角色之间进行通信 . 使用队列是Azure流程之间通信的官方和制裁方式，我真诚地怀疑您是否会将自己编程到一个角落 . Service Bus（AppFabric）具有更高的开销，虽然非常适合与外部应用程序通信，但对于Azure应用程序中的快速和简单消息可能不是最佳选择 .
存储队列与服务总线
以下是我在思考这个问题时所考虑的一些不同考虑因素的细分 .
可用性
自去年11月Azure存储中断以来，Azure承诺永远不会再将代码部署到所有区域 - 将其构建到系统中以使其无法实现 . https://azure.microsoft.com/en-us/blog/final-root-cause-analysis-and-improvement-areas-nov-18-azure-storage-service-interruption/
这是msdn关于可用性的说法：
如果您已经在使用Azure存储Blob或表并开始使用队列，则可以保证99.9％的可用性 . 如果使用带有Service Bus队列的Blob或表，则可用性较低 .
Azure队列旨在支持应用程序组件的分离，以提高可扩展性和故障容忍度 .
发展
就个人而言，我对存储API感到满意，并且已经需要在大多数应用程序的其他区域中使用blob存储 . 存储队列使用与存储blob完全相同的sdk . Azure队列在队列，表和BLOB之间提供统一且一致的编程模型
成本
Service Bus支持的接收和删除模式提供了减少消息传递操作计数（和相关成本）的能力，以换取降低的传输保证 .
似乎有一些关于服务总线成本控制的工具，如果你必须开始保持预算来运行你的应用程序，你可以利用它 - 我试图打破下面的潜在存储队列成本:) . 每个月不到一百美元，GRS每小时超过40,000个队列 . 考虑到我们的剩余存储成本，我认为在这里专注于削减成本并不会有好处 . （两者的带宽相同，比较时取消）
存储定价
您可以获得无限的免费队列和操作 - 您需要支付空间费用
假设30K消息大小为平均值
假设MB中的1000K而不是1024
假设您不会达到1TB以上的分级定价
30K / 1消息* 1 TB / 1000000000K * $ .095 / 1 GB * 1000GB / 1 TB = $ 0.00000285 /第一个使用TB的消息
1条消息/ ~30K * 1000000000K / 1 TB = 33333333 TB中的消息
第一个TB的33333333消息* $ 0.00000285 / message =〜$ 95美元
分散了一个多月，我们可以做到每小时40,000条消息与第一TB一样
服务 Bus 定价
每月10美元基价
按操作付费（任何api调用都是操作） - 添加队列/接收队列/监视队列/等
你每月获得1250万免费操作
支付百万后的操作那
很难估计这里的使用情况，但1亿次运营每月花费80美元
批量接收
通过在检索消息时指定消息计数，存储可以最多批量处理32条消息，而Service Bus允许队列客户机将多条消息批处理为单个发送操作 .
因此，存储是批量接收，而服务总线是批量发送 .
监测
通过Azure队列，您可以获取针对队列执行的所有事务的详细日志以及聚合度量标准 . 这种支持并不是随服务总线开箱的 - 但可能会在某处找到预建的解决方案 .
转发
Service Bus具有缺少存储队列的自动转发功能 .
自动转发使数千个队列能够将其消息自动转发到单个队列，接收应用程序从该队列中消耗该消息 . 您可以使用此机制来实现安全性，控制流，并隔离每个消息发布者之间的存储 .
重复
Service Bus队列支持的复制检测功能会根据MessageID属性的值自动删除发送到队列或主题的重复邮件 .
存储队列消息可以在没有警告的情
元数据
Service Bus为您提供邮件头部的两部分 . 对于全球部署的基础架构，这是一个非常有用的功能 . 让你用区域名称和实例id之类的东西来装饰你的消息 . 队列消息是简单的字符串 . 另一方面，Azure存储队列以名称/值对的形式提供对可应用于队列描述的任意属性的支持 . 因此，您可以在Service Bus中修饰消息并使用存储队列装饰队列
交货保证
Service Bus提供At-Most-Once和至少一次，而Queue仅提供至少一次交付 . 如果并发订阅者一直是个问题，这可能会限制我们使用队列的能力 .
表现
Azure存储队列提供10毫秒的延迟（在数据中心内），而服务总线提供20-25毫秒的延迟 . 服务总线确实提供长轮询，如果你需要它，它甚至会好于10ms .
安全
存储队列使用主/辅助共享密钥，而服务总线通过Active Directory通过Sender / Receiver / Admin角色提供RBAC .
参考
https://msdn.microsoft.com/en-us/library/azure/hh767287.aspx
http://azure.microsoft.com/en-us/pricing/details/storage/
http://azure.microsoft.com/en-us/pricing/details/service-bus/
https://alexandrebrisebois.wordpress.com/2013/10/20/windows-azure-storage-queues-vs-windows-azure-service-bus-queues/
根据我的理解，服务总线（原来）有一段时间的排队，但这些并不能保证传递信息 - 机会！
Azure Queues接缝匹配，因为您的用例仍然是基本的基于REST的Get / Put / Peek接口的基础 .
最近（2015年5月21日）更新了文档，它详细说明了使用其中一个或者其他常用功能（事务支持，队列和消息的大小，生存时间......）：
https://azure.microsoft.com/en-us/documentation/articles/service-bus-azure-and-service-bus-queues-compared-contrasted/
开发人员学习的队列相关模式可以应用于两者 . 从可靠性和实现容易性的角度来看，两者都可以使用 .
仅限事物存储队列可以做1）处理消息的工作人员崩溃 . 后来的 Worker 希望 read the status of the message 继续从前 Worker 离开的地方继续 . 2）您需要对队列执行的所有事务的服务器端日志 .
但比较并不重要 . 如果 custom queue development 是我们需要的，那么总是使用存储队列 . 这是微软首次开发的产品 . 服务总线被引入复制BizTalk，目的是集成（混合），因此这一行有高级功能：会话，事务，自动死信等 .
This link提供了比较，this link也是如此 . 分析所有内容并从敏捷开发开始将难以实现上述规则 .
为了清楚起见，这是两个Azure组件之间的比较，这些组件是在不同的时间点创建的，原因各不相同 .
Storage queues and Service Bus queues - compared and contrasted