Microsoft.ServiceBus.Messaging 与 Microsoft.Azure.ServiceBus 的区别

Question

最近，微软推出了 Microsoft.Azure.ServiceBus 命名空间。
https://github.com/Azure/azure-service-bus/blob/master/samples/readme.md

它适用于新的.net standard框架（好像微软还没有足够的半冗余代码库）

我的问题是，在性能方面它能好到哪里去？

我可以自信地说，Microsoft.ServiceBus.Messaging 还有很多需要改进的地方，特别是在持久接收方面。

Microsoft.ServiceBus.Messaging 的一个非常有用的功能是消息泵，建立在 OnMessage() 方法之上。

新库中没有这个功能，每次接收都需要重新绑定事件处理程序以保持泵送。这绝对是一步后退。

寻求任何有经验且能进行比较的人的反馈..

- I Stand With Russia

---

现在似乎有一些更新的东西，叫做 Azure.Messaging.ServiceBus：https://github.com/Azure/azure-sdk-for-net/blob/main/sdk/servicebus/Azure.Messaging.ServiceBus/MigrationGuide.md - Kiechlus

微软试图以开发者为代价重新塑造自己的品牌。 - I Stand With Russia

Answer 1

针对您的问题，“.netstd库”相比“ .netframework库”提供了以下方面的不同之处：

1. 开源。新库完全开源，您可以浏览、参与贡献、审阅功能，并且下一版本将无需设置符号服务器即可进行步进。
2. 相较于 ".netframework" 库，新库使用真正的异步方式。
3. 职责和代码量减少。例如：Message与BrokeredMessage。您的数据不再由客户端序列化。
4. 默认使用 AMQP 而非 SBMP。
5. 新客户端支持 .NET Standard 和 Full Framework。
6. 重新设计某些客户端方面，以提供更好的选项（OnMessage API 提供更多故障上下文、插件和可扩展性，接口可更轻松进行测试)。
7. 完全测试。

在性能方面，它应该与旧客户端相当甚至更好。

Microsoft.ServiceBus.Messaging的一个非常有用的功能是消息泵，在OnMessage()方法的基础上构建。

您仍然可以使用OnMessage API，尽管现已改名为RegisterMessageHandler。

- Sean Feldman

---

要添加...异步很棒，但我需要同步发送，而Microsoft.Azure.ServiceBus不再有client.Send()，只有client.SendAsync()，这真是令人沮丧。尝试避免使用如何同步运行异步Task<T>方法？ - ttugates

@ttugates，新客户端不再提供同步API的原因是它所做的一切都与IO有关。因此，同步API没有意义。作为库的用户，您始终可以强制同步执行，但这会大大降低性能。 - Sean Feldman

另一个区别是显然缺乏“发送批处理”的方法。虽然有 SendAsync(IList<Message>) 但我不确定它是否与旧的 SendBatchAsync() 方法行为相同。请参阅当前的开放问题 https://github.com/Azure/azure-sdk-for-net/issues/8440（最近5天内有新评论），存档存储库上的旧PR https://github.com/Azure/azure-service-bus-dotnet/pull/539，以及在`Microsoft.ServiceBus.dll`中的原始方法https://learn.microsoft.com/en-us/dotnet/api/microsoft.servicebus.messaging.topicclient.sendbatchasync?view=azure-dotnet - gabe

这是一样的。发送单个消息或集合最终都会调用代理。 - Sean Feldman

批处理在旧客户端中从未是“安全的”。在这方面，新客户端与@gabe并无不同。 - Sean Feldman