Linux 系统上的 Azure 表/Blob/队列随机超时（k8s .net core 3 应用程序）

Question

这是我的场景：

Microsoft.Azure.Storage.Blob 11.2.0
Microsoft.Azure.Storage.Queue 11.2.0
Micorosoft.Azure.Cosmos.Table 1.0.7

我已经将很多代码从 Azure 函数转移到 Google k8s 和 Google Cloud，运行 Core .Net 应用程序，基本上使用 .net Standard 2.0 中内置的相同库，没有任何问题。

几天后，我注意到 Linux 系统中出现了不同的行为。与 Azure 服务（blob、表、队列）交互的调用很少会超时（子系统似乎失败了，我尝试了不同的重试策略，结果相同）。在 10,000 次调用中，我收到 10 到 50 个错误（或者在我更改超时之前很长的调用 180 秒）。这发生在所有 Azure 服务中：表、blob 和队列。

我尝试了不同的解决方案以找出原因：

• 我每次调用都会实例化客户端（blobClient、TableClient..etc），或者回收同一个客户端但没有区别
• 我更改了所有超时以处理此行为。我在 ServerTimeout 和 MaximumExecutionTime 上工作，并使用我的重试机制在顶部放置一个层，这样我就可以最大限度地减少错误。现在我“只有”几个 20 秒的调用（而不是例如 2/3 秒）。
• 我尝试了在 Stackoverflow 上发现类似问题的所有解决方案：D ...但没有任何效果（目前）

在 azure 函数上运行相同的 dll 代码没有任何问题。

所以我得出的结论是，azure sdk 在内部使用的 http 客户端中有一些东西，这取决于您运行代码的操作系统。我想在几篇文章之后它可能是 Keep-Alive 标题，所以我尝试在我的组合根上：

ServicePointManager.SetTcpKeepAlive (true, 120000, 10000);

但没有任何变化。

有什么想法或建议吗？...也许我走错了路，或者我错过了一些东西。

Answer 1

更新

在阅读了最后一条评论中 @KrishnenduGhosh-MSFT 链接的最后一篇文章后，我尝试更改此设置：

ServicePointManager.DefaultConnectionLimit = 100;

这是转折点。

由于它过去是随机发生的，所以我仍然不能 100% 确定问题是否得到解决。但经过 50,000 个电话之后，我相当乐观。显然在生产中会有另一种行为，但我已经预料到了:)

更新 2 - 在产品中发布后

最后，它不起作用:(我在评论中写过，但在这里更新似乎是公平的（更具可读性）。我仍然有很长的调用（缩写为MaximumExecutionTime），但我看不到曙光隧道的尽头。现在我正在考虑将一些 Azure 存储迁移到 Google 存储，但还没有完全放弃。