关于Azure应用程序的一个简单问题。如果我有许多需要通信的Web和Worker角色，文档说要使用Azure队列服务。
但是，我刚刚读到新的.NET Service Bus现在也提供了队列。这些看起来更强大，因为它们似乎提供了更加详细的API。虽然.NSB看起来更有趣，但它有几个问题让我在分布式应用程序中使用它时会很谨慎。 （例如，Queue Expiration ...如果我不能保证队列将按时更新，我可能会失去它！）。
有没有人使用这两种技术中的任何一种都有经验，可以就何时选择其中一种技术给出任何建议。
我怀疑虽然服务总线看起来更强大，但我的用例实际上只是让Web / Worker角色能够相互通信，Azure Queue Service就是我所追求的。但是我真的只是想在确定自己的角色之前确认一下： - ）
提前致谢。
在休息时间阅读了两个系统。它看起来像.NET服务总线更专门用于集成系统，而不是提供通用的可靠消息系统。 Azure队列是分布式的，因此可靠且可扩展，其中.NSB队列不是，因此更适合Azure本身托管的代码。
感谢您的回复。
答案 0 :(得分：20)
以下是我在思考这个问题时所考虑的一些不同考虑因素的细分。
自去年11月存储中断以来，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 / 1消息* 1 TB / 1000000000K * $ .095 / 1 GB * 1000GB / 1 TB = $ 0.00000285 /第一次使用TB消息
1条消息/ ~30K * 1000000000K / 1 TB = 33333333 TB中的消息
33333333消息* $ 0.00000285 / message =〜$ TB $第一个TB
分散了一个月，我们可以做到每小时40,000条消息与第1 TB
很难估计这里的使用情况，但1亿次运营每月花费80美元
通过在检索邮件时指定邮件计数，存储可以批量最多包含32封邮件，而Service Bus允许队列客户端将多封邮件批量处理为单个发送操作。
因此，当服务总线批量发送时，存储是批量接收。
Azure Queues使您可以获取针对队列执行的所有事务的详细日志以及聚合度量标准。这种支持并不是随服务总线开箱的 - 但可能会在某处找到预建的解决方案。
Service Bus具有自动转发功能，缺少存储队列。
自动转发使数千个队列能够将其消息自动转发到单个队列，接收应用程序从该队列中消耗该消息。您可以使用此机制来实现安全性，控制流，并隔离每个邮件发布者之间的存储。
Service Bus队列支持的复制检测功能会根据MessageID属性的值自动删除发送到队列或主题的重复邮件。
存储队列消息可以在没有警告的情况下复制
Service Bus为您提供邮件标题+正文的2个部分。对于全球部署的基础架构，这是一个非常有用的功能。让你用区域名称和实例id之类的东西来装饰你的消息。队列消息是简单的字符串。另一方面，Azure存储队列以名称/值对的形式提供对可应用于队列描述的任意属性的支持。因此，您可以在Service Bus中修饰消息并使用存储队列装饰队列
服务总线提供至少一次和至少一次，而队列仅提供至少一次交付。如果并发订阅者遇到问题，这可能会限制我们使用队列的能力。
Azure存储队列提供10毫秒的延迟（在数据中心内），而服务总线提供20-25毫秒的延迟。服务总线确实提供长轮询，如果你需要它，它甚至会好于10ms。
存储队列使用主/辅助共享密钥，而服务总线通过Active Directory通过发件人/接收者/管理员角色提供RBAC。
答案 1 :(得分：10)
我建议您坚持使用Azure Queues在Web和辅助角色之间进行通信。使用队列是Azure流程之间通信的官方和制裁方式，我真诚地怀疑您是否会将自己编程到一个角落。 Service Bus（AppFabric）具有更高的开销，虽然非常适合与外部应用程序通信，但对于Azure应用程序中的快速和简单消息可能不是最佳选择。
答案 2 :(得分：0)
根据我的理解，服务总线（原来）已经排队了一段时间，但这些并不能保证传递信息 - 机会！
答案 3 :(得分：0)
Azure Queues接缝匹配，因为您的用例在基于REST的简单Get / Put / Peek界面中仍然是基本的。
最近更新了文档（2015年5月21日），它详细说明了使用这些文档时的常用功能（事务支持，队列和消息的大小，生存时间，......） ）：
答案 4 :(得分：0)
开发人员学习的与队列相关的模式可以同时应用于这两种模式。 两者都可以从可靠性和实现简便性的角度使用。
只有存储队列可以执行的操作 1）处理消息的工作人员崩溃。后续工作人员希望阅读消息的状态，以从先前工作人员的上一步退出。 2）您需要针对队列执行的所有事务的服务器端日志。
但是比较并不重要。如果我们需要自定义队列开发，那么请始终使用存储队列。它是Microsoft最早开发的。引入了复制BizTalk的服务总线，其目的是集成（混合），因此该行中具有高级功能：会话，事务，自动死信等。
This link提供了一个比较，this link也提供了一个比较。因此，根据上述规则，将很难分析一切并开始敏捷开发。
答案 5 :(得分：0)
为了清楚起见，这是由于不同原因在不同时间点创建的两个Azure组件之间的比较。
Storage queues and Service Bus queues - compared and contrasted
Azure支持两种队列机制：存储队列和服务总线 队列。
存储队列，它是Azure存储基础结构的一部分， 具有基于REST的简单GET / PUT / PEEK接口，提供 服务内部和服务之间可靠，持久的消息传递。
服务总线队列是更广泛的Azure消息传递的一部分 支持排队以及发布/订阅的基础架构，以及 更高级的集成模式。有关服务的更多信息 总线队列/主题/订阅，请参阅服务总线概述。
虽然两种排队技术同时存在，但存储队列 首先介绍，作为建立在其上的专用队列存储机制 Azure存储服务的顶部。服务总线队列建立在 旨在集成的更广泛的消息传递基础结构 可能跨越多个应用程序或应用程序组件 通信协议，数据合同，信任域和/或网络 环境。