几周前，我们将MassTransit从7.2.0（两年）迁移到8.0.11，然后很快迁移到8.0.16。
供参考：

• 我们有大约5 - 6个不同的“生产”环境，它们的部署方式并不完全相同（K8S /经典虚拟机Windows和/或Linux）。每个环境都有1到10个专用的Rabbit示例（Linux VM或Docker）
• 它是一个多租户解决方案;每个租户在其中一个Rabbit上都有一个专用的vhost
• 每个dotnet进程可以处理多个租户;因此有多个MassTransit示例（每个租户1个;连接到特定Rabbit示例上的特定vhost）。

在我们的开发和QA环境中，我们没有看到这一点，因为它没有生产的工作负载，但在每个生产环境中，我们都遇到了大量的性能损失。
我们设法找到了导致这一点的MassTransit的变化：在版本8中默认禁用BatchPublish。启用此设置几乎恢复了我们之前的性能。

var busControl = Bus.Factory.CreateUsingRabbitMq(cfg =>
{
    cfg.ConfigureJsonSerializerOptions(opts => opts.AddCustomConfigurations());
    
    cfg.ConnectBusObserver(new BusLoggerObserver(_serviceProvider.GetService<ILogger<BusLoggerObserver>>()));

    var connectionName = _configuration.GetApplicationName();
    cfg.Host(options.Hosts.First(), vhostName, connectionName, h =>
    {
        if (options.Hosts.Length > 0)
        {
            h.UseCluster(c =>
            {
                foreach (var host in options.Hosts)
                {
                    c.Node(host);
                }
            });
        }
        h.Username(options.Username);
        h.Password(options.Password);
        h.ContinuationTimeout(options.ContinuationTimeout);
        h.ConfigureBatchPublish(c =>
        {
            c.Enabled = options.BatchPublishEnabled;
            c.MessageLimit = options.BatchPublishMessageLimit;
            c.Timeout = options.BatchPublishTimeout;
        });
    });
});

在MassTransit文档和论坛中，据说这不是必需的，如果是，可能是由RabbitMQ上的延迟造成的。有人对此有什么见解吗？
然而，自从我们迁移以来，真实的问题是我们经常遇到的一个例外：The channel was closed: AMQP close-reason, initiated by Application, code=500, text=''Channel unusable due to continuation timeout'', classId=0, methodId=0 1
当此异常发生时; MassTransit示例似乎已锁定，我们无法再发送或接收任何内容;由于该应用程序完全依赖于MassTransit / RabbbitMQ ;这是一个死过程。我们必须重新启动该过程以恢复可用性。我们试图增加价值，但我们仍然有例外。
这让我做噩梦，有没有人有同样的问题和/或有解决这种情况的办法？
谢谢