将策略定义与执行分开时了解Polly策略的语义

问题描述

使用 Polly 我想要我的策略定义和该策略在两个不同的语句中的执行情况，例如:

With Polly I'd like to have my policy definition and the execution of that policy in two different statements, as in:

// Policy definition
var policy = Policy
   .HandleResult<IRestResponse>(predicate)
   .Retry(2);

// Policy execution
policy.ExecuteAndCapture(() =>
{
    DoSomethingAndReturnAnIRestResponse();
};

我想这样做，以便更好地重用我的重试策略，例如用于依赖项注入.

I want to do it this way so I can get better reuse of my retry policies, e.g. for use in dependency injection.

我试图了解以这种方式拆分策略和执行时是否有任何考虑事项，例如是否存在可能不包含在policy中的任何状态"(由于缺乏更好的用语)从策略定义到执行的对象.

I'm trying to understand if there's any considerations when splitting up the policy and the execution in this way, for example if there's any "state" (for lack of a better term) that might not carry in the policy object from policy definition to execution.

沿这些行，我注意到当我以上述方式使用Polly的ExecuteAndCapture()时，某些属性(与捕获最终异常/结果相关的属性，与ExecuteAndCapture()相关联)未显示在对象.根据文档(此处和)，例如，完成以下政策后:

Along these lines I'm noticing that when I use Polly's ExecuteAndCapture() in the above fashion that certain properties (those related to capturing the final exception/outcome, associated with ExecuteAndCapture()) aren't showing on the policy object. Per the documentation (here and here), upon completion of a policy such as the below:

var policy = Policy
   .HandleResult<IRestResponse>(predicate)
   .Retry(2)
   .ExecuteAndCapture(() =>
    {
       DoSomethingAndReturnAnIRestResponse();
    });

...您应该回来:

PolicyResult.Outcome
PolicyResult.FinalException
PolicyResult.ExceptionType
PolicyResult.Result

这确实发生了，然后ExecuteAndCapture()与策略定义在同一语句中.但是，将策略定义与执行分开时，这些属性不可用.我天真地假定它们会出现在现有的policy对象上，但它们不会:

This indeed is happening then the ExecuteAndCapture() is in the same statement as the policy definition. However, when separating the policy definition from the execution those properties aren't available. I naively assumed they'd show up on the existing policy object, but they don't:

似乎我需要创建一个新的变量赋值才能访问这些属性:

It seems I need to create a new variable assignment in order to access to those properties:

这里有人担心吗?

推荐答案

不用担心.将策略与用法分开配置，并将其注入到用法站点是我们在生产中广泛使用的一种常见模式.

No concerns. Configuring policies separate from their usage, and injecting them into sites of usage, is a common pattern which we use extensively in production.

所有Polly策略都是线程安全的，可以同时在多个独立的呼叫站点中使用.

All Polly policies are thread-safe and may be used across multiple independent call-sites concurrently.

两种Polly策略线程安全地维护调用之间的内部状态，以执行其设计的功能.如果您在呼叫站点之间共享这些策略实例，则会导致特定的(预期的)效果.

Two kinds of Polly policy thread-safely maintain internal state across calls, to carry out their designed functions. This leads to specific (intended) effects if you share those policy instances across call sites.

存在的理由是根据通过策略发出的呼叫中的成功/失败指标来计数并采取行动.每个单个策略实例都在内部为其自身维护此状态.

The raison-d'etre is to count and act according to success/fail metrics across calls placed through the policy. Each single policy instance maintains this state for itself internally.

(预期的)功能后果是，如果您在多个呼叫站点中共享一个CircuitBreakerPolicy实例，则这些多个呼叫站点将共享电路状态，如此处所述.

The (intended) functional consequence of this is that if you share a CircuitBreakerPolicy instance in multiple call sites, those multiple call sites will share circuit state, as discussed here.

• 当您希望这些呼叫站点共同中断时(例如，它们具有共同的下游依赖性)，请在呼叫站点之间共享相同的中断策略实例.
• 当您希望这些呼叫站点具有独立的电路状态并独立中断时，请不要在这些呼叫站点之间共享断路器实例.

存在的理由是限制通过它发出的呼叫的并发性.每个BulkheadPolicy实例都在内部维护状态以对其进行跟踪.

The raison-d'etre is to limit concurrency of calls placed through it. Each single BulkheadPolicy instance maintains state internally to track that.

(预期的)功能后果是，当您在呼叫站点之间共享BulkheadPolicy实例时，这些呼叫站点将共享它们之间的隔板容量.

The (intended) functional consequence of this is that when you share a BulkheadPolicy instance across call-sites, those call-sites share the bulkhead capacity between them.

当您希望呼叫站点在它们之间共享舱壁容量时，
• 在多个呼叫站点之间共享相同的BulkheadPolicy实例.
如果您希望
• 多个呼叫站点具有独立的舱壁容量，请不要在多个呼叫站点之间共享同一BulkheadPolicy实例.

• Share the same BulkheadPolicy instance across multiple call sites when you want call sites to share the bulkhead capacity between them.
• Don't share the same BulkheadPolicy instance across multiple call sites when you want them to have independent bulkhead capacity.

没有其他种类的Polly策略会在整个执行过程中维持策略实例的内部状态.

在问题的两个案例中，.ExecuteAndCapture(...)调用的结果都不在 的policy上.在这两种情况下(在一条语句中定义和执行;或分开)， .ExecuteAndCapture(...)调用的结果是新的 PolicyResult 实例.

The result of an .ExecuteAndCapture(...) call is not on the policy in either of the cases in the question. In both cases (definition and execution in one statement; or separated), the result of the .ExecuteAndCapture(...) call is a fresh PolicyResult instance.

每次执行都会返回一个新的PolicyResult实例. PolicyResult永远不会作为状态存储在策略实例上(这将使策略不是线程安全的，并且无法在调用站点之间重复使用).

Each execution returns a fresh PolicyResult instance. PolicyResult is never stored as state on a policy instance (that would make policies not thread-safe and re-useable across call sites).

在每个代码位置将var更改为实际类型(Policy或PolicyResult)，这可能更清楚一些.

Change var to the actual type (Policy or PolicyResult) in each code location, and this may be clearer to see.

这篇关于将策略定义与执行分开时了解Polly策略的语义的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！