我的专用端点经历了严重的网络故障。在多个不同的 Azure 平台中观察到这些故障。失败的场景通常涉及来自 SaaS（例如 Power BI、ADF 或 Synapse）的连接。这些服务托管自己的 VNET（又名“托管 vnet”）和自己的专用端点（又名“托管专用端点”）。
故障是间歇性的，但在我的数据工程工作负载中每天可能会发生数十次。失败总是作为传统套接字异常公开（即IOException -“连接由对等方重置”）。诚然，对于每一个失败的连接，我都建立了数百个“成功”的连接。但即便如此，根据我的工作负载的大小，失败仍然是有问题且不可避免的。到目前为止，我还没有在这些间歇性故障中发现任何模式。故障发生率比我所使用的 TCP/IP 有线协议所预期的要高得多。 我有几个与 CSS（Microsoft 专业支持）相关的支持案例。我的一个案件已经悬而未决/正在进行两年多了。其他案件是新开的，但我认为它们不会比第一个更有成效。
鉴于我对这些专用端点的体验始终是在“
托管 vnets”的背景下进行的，因此其他一些类型的专用端点可能没有问题，并且问题可能特定于“托管私有端点”。端点”（仅在托管 vnet 中找到）。需要注意的一件事是，这些问题不适用于我的具有 可公开路由的 IP 地址的服务。 我的问题场景总是涉及连接到同一区域（美国东部）的资源，该资源与我的客户端代码非常接近（~0 毫秒延迟）。即使我连接到世界其他地方的资源，遇到我正在处理的高级网络故障“仍然是不合理的”。对于任何类型的 Azure 资源（Entra 身份服务、ADLS、SQL、REST API 等），失败的可能性似乎都相同
当我与 CSS 支持组织合作时，他们似乎并不担心网络问题，他们解释说他们的政策是要求客户启用多次“重试”。这些重试的要求意味着我的管道必须一遍又一遍地执行，才能达到理想的结果。确实，在对同一 Azure 资源进行五次或更多次连接尝试后，网络操作成功的概率将会增加。然而，在我看来，客户不应该被迫在每次网络交互中引入这种解决方法。客户也不应该为所有额外的周期和重复的连接尝试支付成本。
是否有其他人观察到此类“仅”发生在 Azure VNET 中的网络问题？或者在私人端点中？或者在托管专用端点中？是否有可能涉及对基础设施进行调整的解决方案？我并不急于继续对每个网络交互进行重试。我遇到这些套接字错误的场景之一是在 Power BI 的“Azure 托管 VNET 网关”中。下面的答案
仅适用于Power BI（不一定适用于我在ADF和Synapse中持续存在的问题）
Microsoft Azure 网络团队表示他们该错误已修复，但尚未推出。网络团队承诺将于 2024 年初推出。 以 ...3810 结尾的错误：PE-NC 流混合
我不确定这是什么意思，但标题意味着什么。与此同时，我希望有一个临时的解决方法，因为几年来我一直遇到 Power BI 网关故障。我并不完全相信这个错误会按照公布的时间表得到修复。不过，我正在祈祷，并将继续要求更新，直到我的网络问题最终得到解决。