linux系统上的Azure表/ blob /队列随机超时k8s .net core 3应用

问题描述

这是我的情况：

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

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

几天后，我注意到Linux系统中的行为有所不同。 很少有与Azure服务（blob，表，队列）交互的调用超时（子系统似乎失败，我尝试了具有相同结果的其他retry-police）。 在10,000个呼叫中，我会收到10到50个错误（或者很长的呼叫180秒，然后才更改超时）。在所有Azure服务中都会发生这种情况：表，blob和队列。

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

• 我在每次调用时实例化客户端（blobClient，TableClient..etc），或回收相同的客户端，但没有区别
• 我更改了所有超时以处理此行为。我使用ServerTimeout和MaximumExecutionTime进行工作，并使用重试机制将其放在顶层，这样可以最大程度地减少错误。现在，我只打了20秒（而不是2/3秒）的几个电话。
• 我尝试了在Stackoverflow：D上发现类似问题的所有解决方案，但暂时无济于事

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

因此，我得出的结论是，http客户端中的某些内容由azure sdk在内部使用，具体取决于您在其上运行代码的操作系统。 我认为几篇文章之后可能是Keep-Alive标头，所以我尝试在我的合成根目录上

ServicePointManager.SetTcpKeepAlive (true,120000,10000);

但没有任何改变。

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

解决方法

更新

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

ServicePointManager.DefaultConnectionLimit = 100;

这是转折点。

由于它过去是随机发生的，因此我仍然不确定100％是否解决了问题。 但是经过5万次通话之后，我还是很乐观的。显然，在生产中还会有另一种行为，但我已经料到了：）

更新2-产品发布后

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