标签: azureservicebus

我需要在发布服务器和订阅服务器之间建立双向通信.这是为了方便前端MVC3应用程序使用关联过滤器定义订阅,然后将消息放到主题上.最后,MVC3控制器调用SubscriptionClient上的BeginReceive(),并等待响应.

问题似乎是创建和删除这些Subscription对象.开销很大,并且会使应用程序变慢.这并不是说要解决的各种限制,例如主题上的订阅数量不超过2000个.

在发布者和订阅者之间建立这种双向通信的最佳实践是什么？我们希望MVC3应用程序发布消息,然后等待对该确切消息的响应(通过CorrelationId属性和CorrelationFilter).我们已经缓存了NamespaceManager和MessagingFactory,因为它们在资源方面也非常昂贵,并且还因为我们被告知Service Bus使用显式配置模型,我们需要在角色启动期间预先创建大部分这些内容.

因此,这给我们带来了将请求与响应相关联的挑战,以及创建和删除订阅的巨大开销.还有什么更好的做法？我们应该保留SubscriptionClient的缓存,并每次交换过滤器吗？其他人都做了什么？我需要通过Web角色群集获得每秒5到10,000个MVC3请求的请求吞吐量.我们已经在使用AsyncController并在SubscriptionClient上使用异步BeginReceive().它似乎是数以千计的订阅的创建和删除,此时系统正在窒息.

UPDATE1: 根据此处提供的好建议,我们更新了此解决方案,以便在每个Web角色实例上保留SubscriptionClient对象的缓存.此外,我们已迁移到面向MessageSession的方法.

但是,这仍然没有缩放.似乎AcceptMessageSession()是一个非常昂贵的操作.MessageSession对象是否也应该被缓存并重新使用？每个打开的MessageSession对象是否都使用与服务总线的连接？如果是这样,这是否与订阅的并发连接配额相对应？

非常感谢.我想我们到了那里.Web上的大多数示例代码显示:在客户端上创建Topic(),然后是CreateSubscription(),然后是CreateSubscriptionClient(),然后是BeginReceive(),然后拆除所有对象.我只能说,如果你在现实生活中这样做,你的服务器就会被粉碎,你最快就能连接起来了.

我们需要通过这个东西每秒发出数千个请求,很明显这些对象必须被高速缓存和重用.那么,MessageSession还有另一个要缓存的项目吗？我将获得有趣的缓存,因为我们必须实现一个引用计数机制,其中一次只能给出一个对MessageSession的引用,因为这是针对http请求特定的请求/响应,我们不能有其他订阅者同时使用MessageSession对象.

UPDATE2: 好的,将MessageSession缓存以供重用是不可行的,因为它们只与订阅时的LockDuration一样长.这是一个无赖,因为最大LockDuration是5分钟.这些似乎是短期的pub/sub,而不是长期运行的分布式进程.看起来我们需要回到轮询Azure表.

摘要/评论 我们试图建立Service Bus,因为它具有规模潜力及其持久性和交付语义.但是,似乎有些情况下,它们之间的大量请求/响应不适合它.发布部分工作得很好,并且在后端拥有竞争的消费者是很好的,但是有一个前端请求等待定义的单一消费者响应,根本不能很好地扩展,因为MessageSessions需要太长时间才能完成通过AcceptMessageSession()或BeginAcceptMessageSession()创建,因为它们不适合缓存.

如果有人有另一种观点,我很乐意听到.

我只是想知道是否有人曾经发送/发布过 100 万以上使用 MassTransit 向 Azure

目前，一次发送/发布一条消息的过程非常缓慢（大约 25K 条消息需要 10 分钟）。无论如何，我看不到批量发送消息，但我可能会丢失一些东西。

我确实看到Azure支持SendBatch，它的总体消息大小限制为256K，但是我们有很多小消息需要出去，我想知道是否有人扩展了MassTransit来支持此功能，或者有其他一些关于如何提高绩效的建议。

所有的建议都得到了极大的重视。

我正在尝试使用流量管理器来处理不同区域中的 2 个服务总线，以提供弹性，而不必向两个区域发送重复的消息，如https://learn.microsoft.com/en-us/azure/service-bus中所述-消息/服务总线中断灾难

我希望使用服务总线 REST API 使流量管理器查询 URL namespace.servicebus.windows.net/ 进行运行状况检查，因为它通常会返回 200，并且如果某个区域面临中断，可能会无法连接。

由于选择“Azure 终结点”时，流量管理器中的下拉菜单拒绝让我选择任意 URL，因此我尝试使用上述 URL 来选择“外部终结点”，但不会创建终结点。它失败并显示“无法将配置更改保存到流量管理器配置文件错误：域名 xxx 无效”。

如果 url xxx.servicebus.windows.net/ 可以从外部解析，为什么流量管理器不允许这样做？

我目前正在评估使用服务总线和 azure 函数来触发一些需要通过下游 api 调用完成的工作。这一切都是相当标准的，只是我没有很好地处理当下游系统过载和/或将标头返回到节流阀时会发生什么（即每分钟最大调用数/等）。我们似乎没有对队列触发器的强制限制进行任何动态控制。

我知道我们可以手动设置最大并发数，但这不一定能解决问题，因为我们无法控制下游系统，并且需要考虑它随时可能离线或缓慢。

此外，我们可以创建消息，以便它们被安排以一定的速率流入，但下游系统仍然可能饱和或返回速率限制。

选项1：

假设消费计划，从解决方案的角度来看，这是我能想到的一种方法：

• 队列 1 - 全速或最大速度。如果我们开始受到速率限制，请设置一个缓存值。如果设置了缓存值，则不处理该消息，克隆它并放入queue2中
• Queue2 - 每个最大并发/预取计数较低。与上面相同的过程，但推入队列3。
• Queue3 - 每个最大并发/预取计数的最低值。我们只是慢慢地处理它们。

基本上，当下游系统饱和时，队列 1 成为队列 2 和队列 3 的控制器。

选项2：

我们可以克隆消息并在将来重新排队，并继续这样做，直到它们都是进程。保留一个队列并重新排队，直到我们处理完它。

选项 3：

假设我们有自己的应用程序计划，该计划是专用的而不是消耗的，我想我们可以Thread.Sleep在功能接近速率限制或下降时继续重试。这可能是最大并发数、实例和速率限制的计算。我不会在消费计划中考虑这一点，因为睡眠可能会大幅增加成本。

我想知道我是否缺少一些简单的方法来处理下游饱和或限制队列触发器（可能是服务总线或存储队列）

编辑：我想补充一点，我将 100 万条消息注入到发送时安排的服务总线队列中。我观察到 Azure Function（消耗计划）规模达到了大约 1500/秒，这提供了一个很好的指标。我不确定那些专注的人会表现如何。

看起来主机文件可以即时修改并且设置立即生效。尽管这适用于所有功能，但它可能适用于我的特定情况（更新设置并每隔一分钟左右再次检查一次，具体取决于速率限制）。

当功能团队实施时，这看起来可能是朝着正确方向迈出的一步，但即便如此，我们仍然需要一种方法来管理下游错误。

我希望能够控制Azure功能在运行时读取的服务总线队列或订阅的名称.

使用WebJobs(Azure Functions基于),您可以通过实现和配置自定义来执行此操作INameResolver,请参阅:如何为Web作业处理创建基于配置的队列名称？

但是,使用Azure功能,我无权连接JobHostConfiguration此自定义解析程序.

我还可以使用INameResolver,如果是这样的话怎么样？

是否可以使用 AZ CLI 获取 Azure 服务总线primaryConnectionString？

输入参数：

1. 资源组
2. 服务总线名称

我正在使用Azure 事件中心。我计划发送事件并使用SendBatchAsync。我看到事件中心的限制为256KB （无论是单独发送还是批量发送）

那么，如果我的数据 > 256KB ，处理此问题的最佳实践是什么？我们是否应该单独发送消息（这将保证消息小于 256KB）？

另外，如何将事件拆分为 256KB 块并将其发送到事件中心？我查看了 Azure 文档，发现他们建议使用EventHubClient.CreateBatch，但我没有看到足够的示例。有人可以提供一些模型或示例或步骤，以了解我们如何最终拆分为 256KB 和 SendBatchAsync

这是我所做的（但不考虑 256KB 限制）

await myEventHubClient.SendBatchAsync(
    events.Select( 
        iEvent =>
            new EventData(
                Encoding.UTF8.GetBytes(JsonConvert.SerializeObject( iEvent ) ) ) ) );

我尝试创建一个 ServiceBusTrigger 函数，就像在 .NET Framework 中一样：

C:\Users\foo\test2>func new --language C# --template ServiceBusTrigger --name MyServicebusTrigger
Select a language: C#
Select a template: ServiceBusTrigger
Can't find template "ServiceBusTrigger" in "C#"

我找不到任何有关包含哪些模板的文档。不是有吗？

我们在西欧地区使用 Azure 服务总线。

当我查看指标以调查重复问题时，我注意到我们存在大量“服务器错误”。这似乎占了请求的近 50%。

现在，微软关于服务器错误含义的信息并不多，除了说它是“内部服务总线错误”（参见https://learn.microsoft.com/en-us/azure/service-bus-messaging /service-bus-metrics-azure-monitor）

我的问题： 我需要担心吗？目前我在西欧仍然可以依赖 Service Bus（上个月该地区的 Service Bus 出现了一些问题）。

这是什么意思？我该如何解决？

提前谢谢

我参考此示例来使用Azure服务总线 https://github.com/Microsoft/azure-spring-boot/tree/master/azure-spring-boot-samples/azure-servicebus-spring-boot-sample

我能够让示例正常工作，没有任何问题。

1-作为它的扩展，我现在在同一服务总线命名空间中创建了多个队列。我想读取消息并将其发布到每个队列。通过 azure-servicebus-spring-boot-starter 项目，我如何指定要使用的多个队列。

2-我想每 10 秒听一次队列。对于同样的情况，我在 sprint 启动应用程序中启用了调度。在每 10 秒调度一次的组件方法中，现在我正在注册消息处理程序。

queueClient.registerMessageHandler(new MessageHandler(),options);

重复注册会有问题吗？如果是这样，如何编码相同。

谢谢