c# - Azure 服务总线监听器打开太多 TCP 连接(耗尽)

Question

我们有多个服务总线监听器在应用服务内作为连续的 Azure Webjobs 运行。总共有 12 个监听器 Web 作业在同一个 S1 应用服务计划上运行。环境很小，每天总共大约有~1000-10000条消息。最近，我们部署了一个新的监听器(一个定期向原始主题重新发送 DLQ 消息最多 24 小时和 10 次重试(指数退避)的监听器)，昨天我们在托管应用服务上收到一条 TCP/IP 耗尽错误消息。在 S1 上，这意味着 Web 作业总共打开了超过 2000 个 TCP 连接。
总而言之，我们无法解释为什么监听器如此渴望 TCP 连接。每个应用程序在其应用程序生命周期中都使用一个 Topic-/QueueReceiver，并且还使用一个单例 HttpClient 来连接到目标 API。从理论上讲，这应该意味着每个监听器永远不会同时打开超过 10 个 TCP 连接。

我分析了代码，但没有发现 TCP 连接需求高的原因。

所有监听器大致都是这样工作的(.NET 控制台应用程序，在应用服务中作为连续的 Azure Webjobs 托管):

public static async Task Main(string[] args)
{
    var configuration = GetConfiguration();

    // Setup dependencies (e.g. Singleton HttpClient)
    IServiceCollection serviceCollection = new ServiceCollection();
    ConfigureServices(serviceCollection, configuration);

    IServiceProvider serviceProvider = serviceCollection.BuildServiceProvider();
    var factory = serviceProvider.GetService<TopicReceiverFactory<Model>>();
    var receiver = await factory.CreateAsync();
    receiver.ReceiveMessages();

    Console.ReadLine();
}

// ctor of the receiver used above
public QueueReceiver(QueueConfiguration configuration, IHandler<T> handler, ILogger<IReceiver> logger)
        : base(logger, handler)
{
    this.configuration = configuration;

    this.Client = new QueueClient(
    this.configuration.ConnectionString,
    this.configuration.QueueName,
    this.configuration.ReceiveMode);
}

// The ReceiveMessages Method used in Main
public void ReceiveMessages()
{
    var messageHandlerOptions = new MessageHandlerOptions(this.HandleExceptionReceivedAsync)
    {
        MaxConcurrentCalls = this.configuration.MaxConcurrentCalls,
        AutoComplete = false
    };

    this.Register(messageHandlerOptions);
}

protected void Register(MessageHandlerOptions messageHandlerOptions)
{
    if (messageHandlerOptions == null)
    {
        throw new ArgumentNullException(nameof(messageHandlerOptions));
    }

    this.Client.RegisterMessageHandler(this.ProcessMessageAsync, messageHandlerOptions);
}

ProcessMessage大致有这样的逻辑:调用特定实体的处理程序(将消息发布到api)，如果成功:完成消息；如果出现严重异常(例如 JsonSerializerException 因为消息格式错误)而失败，则直接死信。轻微异常会导致内置重试(最多十次)。

预计 TCP 连接永远不会耗尽。环境中没有发生太多事情。

编辑:我发现从监听器到服务总线的出站连接是问题的根源。应用服务的“TCP 连接”分析器显示以下信息:

Answer 1

我们找到了问题的根源。考虑以下架构:具有多个主题和一个队列的服务总线命名空间。消息将发送到服务总线监听器接收和处理消息的主题。如果无法处理消息，它们将被转发到中央错误处理队列。在此队列上，一个监听器正在接收消息并读取消息上的 DeadLetterSource-Property。在此属性中包含有关原始主题的信息。

现在问题:目前我们正在为每条消息创建一个 TopicClient。发生这种情况是因为这个监听器不需要提前知道有哪些主题，从而降低了可重用性。然而，正如我们现在发现的那样，这是不可持续的，因为您会耗尽 TCP 连接。

解决方案:我们通过配置引入主题名称，以便该监听器可以为整个应用程序生活方式的每个主题创建一个 TopicClient。本质上有 n-Singleton TopicClient 实例同时运行。