以可持续的方式使用天蓝色的瞬态故障处理

Question

Azure文档缺乏,文章经常过时.

我已经读过Azure服务的" 瞬态故障处理 "(TFH)(ServiceBus,FileStorage ...)现在已经完全管理.现在似乎没有什么可以在客户端实现.过去,我们可以使用企业库来管理这些目的,但它已经退役.为了访问SQL数据库,为Entity Framework实现了一个策略(https://msdn.microsoft.com/en-us/data/dn456835.aspx).

这是我的问题:

• 是否有必要在ServiceBus和FileStorage上使用Azure SDK 以从现在在Azure上实施的策略中受益？
• 在使用非EF的数据访问数据时,如何管理TFH？

我们需要确保我们的组件(使用WebClient,原始ADO.NET ......)能够以可维护的方式正确运行.

Answer 1

我已经读过Azure服务的"瞬态故障处理"(TFH)(ServiceBus,FileStorage ...)现在已经完全管理.现在似乎没有什么可以在客户端实现.

这是不正确的.该服务本身不会处理瞬态错误.客户有责任处理瞬态错误.如果您查看Storage Client Library(> =版本2.0),您将在那里找到重试策略,您可以使用该策略指示客户端代码处理瞬态错误.

现在回答你的问题:

是否有必要在ServiceBus和FileStorage上使用Azure SDK以从现在在Azure上实施的策略中受益？

当然没有必要使用SDK来处理瞬态错误,但它们可以使您的工作更轻松.SDK提供了各种方法来处理瞬态错误(此外,您可以扩展SDK中可用的功能以提出您自己的瞬态处理策略).详细说明一下,让我们考虑一下Storage Client库,它是Azure Storage REST API的包装器.现在,此库已定义哪些错误应被视为瞬态(HTTP状态代码500+)以及哪些错误不应视为瞬态(HTTP状态代码400-499).此外,它还带有不同类型的重试逻辑 - 指数(默认),线性或无.作为开发人员,您可以决定在出现瞬态错误时应使用哪种重试逻辑并将其烘焙到您的代码中.如果您没有使用这些SDK,那么一切都需要由您从错误应该被视为瞬态以及如何实现重试开始.SDK只会让您的工作更轻松.

在使用非EF的数据访问数据时,如何管理TFH？

如果您正在使用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/.