以可持续的方式使用 Azure 进行暂时性故障处理
本文关键字：Azure 暂时性 故障处理 方式使 | 更新日期: 2023-09-27 18:35:56
Azure 文档缺失，文章通常已经过时。
我已经读到Azure服务（ServiceBus，FileStorage...）的"暂时性故障处理"（TFH）现在是完全托管的。现在似乎没有什么可以在客户端实现的。过去，我们可以使用企业库来管理此类用途，但它已停用。为了访问 SQL 数据库，为实体框架 （https://msdn.microsoft.com/en-us/data/dn456835.aspx） 实施策略。
这是我的问题：
- 是否有必要在服务总线和文件存储上使用 Azure SDK，才能从现在在 Azure 上实现的策略中受益？
- 当使用非 EF 访问数据时，如何管理 TFH？
我们需要确保我们的组件（使用WebClient，原始 ADO.NET...）将以可维护的方式正确运行。
我已阅读 Azure 服务的"暂时性故障处理"（TFH） （ServiceBus， FileStorage...） 现在完全托管。现在似乎在那里 在客户端无需实现。
这是不正确的。服务本身不会处理暂时性错误。客户端负责处理暂时性错误。如果您查看存储客户端库（>= 版本 2.0），您将在其中找到重试策略，您可以使用这些策略指示客户端代码处理暂时性错误。
现在来回答您的问题：
是否有必要在服务总线和文件存储上使用 Azure SDK 来 从现在在 Azure 上实施的策略中受益？
当然没有必要使用 SDK 来处理暂时性错误，但它们会使您的工作更轻松。SDK 提供了多种处理暂时性错误的方法（此外，您还可以扩展 SDK 中可用的功能以提出自己的瞬态处理策略）。为了详细说明，让我们考虑存储客户端库，它是 Azure 存储 REST API 的包装器。现在，此库已定义哪些错误应被视为暂时性（HTTP 状态代码 500+），哪些错误不应被视为暂时性（HTTP 状态代码 400 - 499）。 此外，它还带有不同类型的重试逻辑 - 指数（默认）、线性或无。作为开发人员，您可以决定在发生暂时性错误时应使用哪种重试逻辑，并将其烘焙到代码中。如果未使用这些 SDK，则需要从哪些错误应被视为暂时性以及如何实现重试开始，完成所有操作。SDK 只是让你的工作更轻松。
使用某些东西访问数据时如何管理 TFH 那不是EF ？
如果您正在使用 ADO.Net 并且遇到异常，则可以查看服务返回的ErrorCode，并确定错误是否是暂时性的。有关 SQL 错误代码的列表，请参阅此链接：https://azure.microsoft.com/en-in/documentation/articles/sql-database-develop-error-messages/。我还强烈建议您阅读本文以及如何实现自己的TFH：https://azure.microsoft.com/en-in/documentation/articles/sql-database-connectivity-issues/。