在 .NET 服务总线队列与 Azure 队列服务之间进行选择 [关闭]
https://stackoverflow.com/questions/1906244
-
19-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian题
这是一个有关 Azure 应用程序的简单问题。如果我有多个需要通信的 Web 和 Worker 角色，文档表明要使用 Azure 队列服务。
不过，我刚刚了解到新的 .NET 服务总线现在也提供队列。这些看起来更强大，因为它们似乎提供了更详细的 API。虽然 .NSB 看起来更有趣，但它有几个问题让我对在分布式应用程序中使用它持谨慎态度。（例如，队列过期...如果我不能保证队列会按时更新，我可能会失去所有！）。
有没有人有使用这两种技术中任何一种的经验，并且可以就何时选择其中一种技术提供任何建议。
我怀疑虽然服务总线看起来更强大，但我的用例实际上只是使 Web/Worker 角色能够相互通信，而 Azure 队列服务正是我所追求的。但在将自己编程到一个角落之前，我真的只是在寻找对此的确认:-)
提前致谢。
更新
在休息期间阅读了有关这两个系统的信息。看来 .NET 服务总线是专门为集成系统而设计的，而不是提供通用的可靠消息传递系统。Azure 队列是分布式的，因此可靠且可扩展，而 .NSB 队列则不然，因此更适合 Azure 本身托管的代码。
感谢您的回复。
解决方案
我建议你还是坚持使用Azure的队列为Web和辅助角色之间的通信。使用队列是Azure的过程，我真诚地相信，你将自己编程到一个角落之间沟通的官方和认可的方式。服务总线（AppFabric中）有交谈外部应用更高的开销，但真正的好，可能不是最优的为您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
- 假设 MB 为 1000K，而不是 1024
- 假设您不会达到 1TB 以上的分级定价
30K / 1 条消息 * 1 TB / 1000000000K * $.095 / 1 GB * 1000GB / 1 TB = $0.00000285 / 第一个 TB 使用的消息
1 条消息 / ~30K * 1000000000K / 1 TB = 1 TB 中有 33333333 条消息
33333333 条消息 * $0.00000285 / 消息 = 第一个 TB 约 95 美元
在一个月的时间内，我们可以利用第一个 TB 每小时处理 40,000 条消息
服务总线定价
- 基本价格为每月 10 美元
- 按操作付费（任何 api 调用都是操作）- 添加队列/接收队列/监视队列/等。
- 您每月获得 1250 万次免费操作
- 此后按每百万次操作付费
很难估计这里的使用情况，但 1 亿次操作每月花费 80 美元
批量接收
通过在检索消息时指定消息计数，存储最多可以批处理 32 条消息，而服务总线允许队列客户端将多个消息批处理到单个发送操作中。
所以存储是批量接收，而服务总线是批量发送。
监控
Azure 队列使您能够获取针对队列执行的所有事务的详细日志以及聚合指标。这种支持并不是随服务总线而来的，但可能可以在某处找到预构建的解决方案。
转发
服务总线具有存储队列缺少的自动转发功能。
自动转发使数千个队列能够将其消息自动转发到单个队列，接收应用程序从中使用消息。您可以使用此机制来实现安全性、控制流并隔离每个消息发布者之间的存储。
重复项
服务总线队列支持的重复检测功能会根据 MessageID 属性的值自动删除发送到队列或主题的重复消息。
存储队列消息可能会在没有警告的情况下重复。
元数据
服务总线为您提供消息头+正文的两部分。对于全球部署的基础设施来说，这是一个非常有用的功能。让您可以使用区域名称和实例 ID 等内容来装饰消息。队列消息是简单的字符串。另一方面，Azure 存储队列以名称/值对的形式提供对可应用于队列描述的任意属性的支持。所以可以在Service Bus中装饰消息，用存储队列装饰队列
交货保证
服务总线提供最多一次和至少一次交付，而队列仅提供至少一次交付。如果并发订阅者出现问题，这可能会限制我们使用队列的能力。
表现
Azure 存储队列提供 10 毫秒的延迟（数据中心内），而服务总线提供 20-25 毫秒的延迟。服务总线确实提供长轮询，如果您需要的话，它甚至会比 10 毫秒更好。
安全
存储队列使用主/辅助共享密钥，而服务总线通过具有发送者/接收者/管理员角色的 Active Directory 提供 RBAC。
参考
据我了解，在服务总线（象）已经拥有一段时间的队列，但这些都不能保证传递消息 - 苯教的机会
Azure 队列接缝匹配，因为您的用例仍然是基本的，具有简单的基于 REST 的 Get/Put/Peek 界面。
该文档最近已更新（05/21/2015），它详细介绍了使用其中一种或另一种的情况，以及常见功能（事务支持、队列和消息的大小、生存时间等）：
为了让事情变得非常清楚，这是两个 Azure 组件之间的比较，这两个组件是在不同的时间点、出于不同的原因创建的。
Azure 支持两种类型的队列机制：存储队列和服务总线队列。
存储队列是Azure存储基础架构的一部分，它具有简单的基于REST/PUT/PEEK接口，可提供可靠的，持续的服务内部和服务之间的消息。
服务总线队列是支持排队和发布/订阅以及更高级集成模式的更广泛的Azure消息基础架构的一部分。有关服务总线队列/主题/订阅的更多信息，请参见Service Bus的概述。
尽管这两种排队技术同时都存在，但首先引入了存储队列，作为建立在Azure存储服务顶部的专用队列存储机制。服务总线队列建立在更广泛的消息基础架构之上，旨在集成可能涵盖多个通信协议，数据合同，信任域和/或网络环境的应用程序或应用程序组件。
