Microsoft.ServiceBus.Messaging 与 Microsoft.Azure.ServiceBus

Posted 2023-02-16

【中文标题】Microsoft.ServiceBus.Messaging 与 Microsoft.Azure.ServiceBus

【英文标题】：Microsoft.ServiceBus.Messaging vs Microsoft.Azure.ServiceBus

【发布时间】：2018-02-03 00:39:36

【问题描述】：

MS 最近引入了 Microsoft.Azure.ServiceBus 命名空间。https://github.com/Azure/azure-service-bus/blob/master/samples/readme.md

它适用于新的 .net 标准 框架（好像 MS 没有足够的半冗余代码库）

我的问题是，它在性能方面能提高多少？

我可以自信地说，Microsoft.ServiceBus.Messaging 有很多不足之处，尤其是在持久接收方面。

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

新库没有这个，并且需要在每张收据上重新绑定事件处理程序以保持抽水。绝对是退步了。

寻求任何有这两种经验并可以比较的人的反馈..

【问题讨论】：

现在似乎还有更新的东西，叫做Azure.Messaging.ServiceBus:github.com/Azure/azure-sdk-for-net/blob/main/sdk/servicebus/…

MS 试图以牺牲开发人员为代价重塑自己

【参考方案1】：

为了解决您的问题，.netstd 库提供的 .netframework one 中没有：

Open Source。新库是完全开源的。您无需设置符号服务器即可浏览、进入（下一个版本）、贡献并简单地查看工作方式。 与 .netframework 库相比，新库真正异步。 减少了责任和代码大小。例如，Message 与 BrokeredMessage。您的数据不再由客户端序列化。 默认为 AMQP 而不是 SBMP。 新客户端以.NET Standard and Full Framework为目标。 重新设计了某些客户端方面以提供更好的选项（OnMessage API 可提供更多故障上下文、plugins 和 extensibility、interfaces 以便于测试）。 Fully tested。

性能方面，如果不是更好的话，它应该与老客户相提并论。

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

您仍然拥有 OnMessage API，但已重命名为 RegisterMessageHandler。

【讨论】：

添加.. Async 很棒，但我需要同步发送，Microsoft.Azure.ServiceBus 不再有client.Send() 只有client.SendAsync()，这很糟糕。尽量避免使用How would I run an async Task<T> method synchronously?

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

另一个区别是明显缺少“发送批处理”方法。有一个SendAsync(IList<Message>)，但我不清楚它的行为是否与旧的SendBatchAsync() 方法相同。请参阅当前未解决的问题github.com/Azure/azure-sdk-for-net/issues/8440（甚至 5 天前的新 cmets），存档 repo 上的旧 PR github.com/Azure/azure-service-bus-dotnet/pull/539，以及Microsoft.ServiceBus.dll 中的原始方法@docs.microsoft.com/en-us/dotnet/api/…

是一样的。发送单个消息或集合最终与调用代理相同。

对旧客户端进行批处理从来都不是“安全的”。 I. 在这方面，新客户也不例外，@gabe。