您的位置: 首页  >  技术问答  >  将策略定义与执行分开时了解Polly策略的语义

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

分类: 技术问答 • 2022-03-31 22:37:00

将策略定义与执行分开时了解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上.在这两种情况下(在一条语句中定义和执行;或分开)， 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.

相关推荐