只是一个关于 Azure 应用程序的快速问题。如果我有许多需要通信的 Web 和 Worker 角色，文档说要使用 Azure 队列服务。
但是，我刚刚读到新的 .NET 服务总线现在也提供队列。这些看起来更强大，因为它们似乎提供了更详细的 API。虽然 .NSB 看起来更有趣，但它有几个问题让我对在分布式应用程序中使用它持谨慎态度。（例如，队列过期......如果我不能保证队列会按时更新，我可能会失去它！）。
有没有人有任何使用这两种技术的经验，并且可以就何时选择其中一种技术提供任何建议。
我怀疑虽然服务总线看起来更强大，因为我的用例实际上只是使 Web/Worker 角色能够相互通信，但我所追求的是 Azure 队列服务。但在将自己编程到角落之前，我真的只是在寻找确认:-)
提前致谢。
在休息期间阅读了有关这两个系统的信息。defo 看起来 .NET 服务总线更专为集成系统而设计，而不是提供通用的可靠消息传递系统。Azure 队列是分布式的，并且如此可靠和可扩展，而 .NSB 队列则不是，因此更适合托管在 Azure 本身内的代码。
感谢您的回复。
以下是我在思考这个问题时的一些不同考虑因素的细分。
自去年 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% 的可用性。如果将 Blob 或表与服务总线队列一起使用，则可用性会降低。
Azure 队列旨在支持应用程序组件的解耦，以提高可伸缩性和对故障的容忍度。
就个人而言，我对存储 API 很满意，并且在大多数应用程序的其他领域已经需要它的 blob 存储。存储队列使用与存储 blob 完全相同的 sdk。Azure 队列提供跨队列、表和 BLOB 的统一且一致的编程模型
服务总线支持的接收和删除模式提供了减少消息传递操作计数（和相关成本）以换取降低交付保证的能力。
似乎有一些围绕服务总线成本控制的工具，如果您必须开始保持预算来运行您的应用程序，您可以利用这些工具 - 我尝试在下面分解潜在的存储队列成本:)。GRS 每小时排队超过 40,000 条，每月花费不到 100 美元。与我们的其他存储成本一起，我认为专注于削减成本并没有什么好处。（两者的带宽相同，比较时会自行抵消）
您可以获得无限的免费队列和操作 - 您需要为空间付费
30K / 1 条消息 * 1 TB / 1000000000K * $.095 / 1 GB * 1000GB / 1 TB = $0.00000285 / 第一 TB 使用的消息
1 条消息 / ~30K * 1000000000K / 1 TB = 33333333 条消息在一个 TB 中
33333333 条消息 * 0.00000285 USD / 消息 = 第一个 TB 约 95 美元
分布在一个月内，我们可以用第一 TB 每小时处理 40,000 条消息
很难估计这里的使用量，但 1 亿次操作每月花费 80 美元
通过在检索消息时指定消息计数，存储最多可以批处理 32 条消息，而服务总线允许队列客户端将多条消息批处理到单个发送操作中。
所以存储是批量接收，而服务总线是批量发送。
Azure 队列使您能够获取针对队列执行的所有事务的详细日志以及聚合指标。这种支持并不是服务总线开箱即用的——但可能会在某处找到预构建的解决方案。
服务总线具有缺少存储队列的自动转发功能。
自动转发使数千个队列能够将它们的消息自动转发到单个队列，接收应用程序从该队列中消费消息。您可以使用此机制来实现每个消息发布者之间的安全性、控制流和隔离存储。
服务总线队列支持的重复检测功能会根据 MessageID 属性的值自动删除发送到队列或主题的重复消息。
存储队列消息可以在没有警告的情况下重复。
服务总线为您提供消息头+正文的 2 部分。对于全球部署的基础架构，这是一个非常有用的功能。让您使用区域名称和实例 ID 等内容来装饰您的消息。队列消息是简单的字符串。另一方面，Azure 存储队列以名称/值对的形式提供对可应用于队列描述的任意属性的支持。所以可以在Service Bus中装饰消息，用存储队列装饰队列
Service Bus 提供 At-Most-Once 和 At-Least-Once，而 Queues 仅提供 At-Least-Once 交付。如果并发订阅者成为问题，这可能会限制我们使用队列的能力。
Azure 存储队列提供 10 毫秒延迟（在数据中心内），而服务总线 20-25 毫秒延迟。服务总线确实提供了长轮询，如果您有需要，它甚至会超过 10 毫秒。
存储队列使用主要/次要共享密钥，而服务总线通过具有发送者/接收者/管理员角色的 Active Directory 提供 RBAC。
我建议您坚持使用 Azure 队列在 Web 角色和辅助角色之间进行通信。使用队列是 Azure 进程之间通信的官方认可的方式，我真诚地怀疑你会将自己编程到一个角落。服务总线 (AppFabric) 的开销较高，虽然非常适合与外部应用程序通信，但对于 Azure 应用程序中的快速和简单消息可能不是最佳选择。
据我了解，服务总线（原样）已经排队了一段时间，但这些不能保证传递消息 - 好机会！
开发人员学习的队列相关模式可以应用于两者。从可靠性和易于实施的角度来看，两者都可以使用。
只有存储队列可以做的事情 1) 处理消息的工作人员崩溃。后续工作人员希望读取消息的状态以从前一个工作人员停止的地方继续。2) 您需要针对您的队列执行的所有事务的服务器端日志。
但比较并不重要。如果自定义队列开发是我们需要的，那么总是使用存储队列。它是第一个由微软开发的。复制 BizTalk 引入了服务总线，目的是集成（混合），因此该行中有高级功能：会话、事务、自动死信等。
Azure Queues 无缝匹配，因为您的用例通过简单的基于 REST 的 Get/Put/Peek 界面保持基本。
该文档最近已更新（2015 年 5 月 21 日），它详细说明了使用其中一个或另一个时的详细信息，以及常见功能（事务支持、队列和消息的大小、生存时间……）：
为了清楚起见，这是两个 Azure 组件之间的比较，它们是在不同的时间点出于不同的原因创建的。
Azure 支持两种类型的队列机制：存储队列和服务总线队列。
存储队列是 Azure 存储基础结构的一部分，具有简单的基于 REST 的 GET/PUT/PEEK 接口，可在服务内部和服务之间提供可靠、持久的消息传递。
服务总线队列是更广泛的 Azure 消息传递基础结构的一部分，它支持排队、发布/订阅和更高级的集成模式。有关服务总线队列/主题/订阅的更多信息，请参阅服务总线概述。
虽然这两种队列技术同时存在，但首先引入了存储队列，作为建立在 Azure 存储服务之上的专用队列存储机制。服务总线队列构建在更广泛的消息传递基础架构之上，旨在集成可能跨越多个通信协议、数据合同、信任域和/或网络环境的应用程序或应用程序组件。