mirror of https://github.com/dapr/docs.git
PR feedback
Signed-off-by: Nick Greenfield <nigreenf@microsoft.com>
This commit is contained in:
Nick Greenfield
parent
ef686fdfa1
commit
3f5b4887bb
|
|
@ -3,7 +3,7 @@ type: docs
|
|||
title: "Policies"
|
||||
linkTitle: "Policies"
|
||||
weight: 4500
|
||||
description: "Configure resiliency policies for timeouts, retries/backoffs and circuit breakers"
|
||||
description: "Configure resiliency policies for timeouts, retries and circuit breakers"
|
||||
---
|
||||
|
||||
### Policies
|
||||
|
|
@ -14,7 +14,7 @@ You define timeouts, retries and circuit breaker policies under `policies`. Each
|
|||
|
||||
Timeouts can be used to early-terminate long-running operations. If you've exceeded a timeout duration:
|
||||
|
||||
- The operation in progress will be terminated (if possible).
|
||||
- The operation in progress is terminated (if possible).
|
||||
- An error is returned.
|
||||
|
||||
Valid values are of the form `15s`, `2m`, `1h30m`, etc.
|
||||
|
|
@ -37,8 +37,8 @@ With `retries`, you can define a retry strategy for failed operations, including
|
|||
| Retry option | Description |
|
||||
| ------------ | ----------- |
|
||||
| `policy` | Determines the back-off and retry interval strategy. Valid values are `constant` and `exponential`. Defaults to `constant`. |
|
||||
| `duration` | Determines the time interval between retries. Default: `5s`. Only applies to the `constant` `policy`. Valid values are of the form `200ms`, `15s`, `2m`, etc. |
|
||||
| `maxInterval` | Determines the maximum interval between retries to which the `exponential` back-off `policy` can grow. Additional retries will always occur after a duration of `maxInterval`. Defaults to `60s`. Valid values are of the form `5s`, `1m`, `1m30s`, etc |
|
||||
| `duration` | Determines the time interval between retries. Default: `5s`. Only applies to the `constant` policy. Valid values are of the form `200ms`, `15s`, `2m`, etc. |
|
||||
| `maxInterval` | Determines the maximum interval between retries to which the `exponential` back-off policy can grow. Additional retries always occur after a duration of `maxInterval`. Defaults to `60s`. Valid values are of the form `5s`, `1m`, `1m30s`, etc |
|
||||
| `maxRetries` | The maximum number of retries to attempt. `-1` denotes an indefinite number of retries. Defaults to `-1`. |
|
||||
|
||||
The exponential back-off window uses the following formula:
|
||||
|
|
@ -74,11 +74,11 @@ Circuit breakers (CBs) policies are used when other applications/services/compon
|
|||
| Retry option | Description |
|
||||
| ------------ | ----------- |
|
||||
| `maxRequests` | The maximum number of requests allowed to pass through when the CB is half-open (recovering from failure). Defaults to `1`. |
|
||||
| `interval` | The cyclical period of time used by the CB to clear its internal counts. If set to 0 seconds, this will never clear. Defaults to `0s`. |
|
||||
| `interval` | The cyclical period of time used by the CB to clear its internal counts. If set to 0 seconds, this never clears. Defaults to `0s`. |
|
||||
| `timeout` | The period of the open state (directly after failure) until the CB switches to half-open. Defaults to `60s`. |
|
||||
| `trip` | A Common Expression Language (CEL) statement that is evaluated by the CB. When the statement evaluates to true, the CB trips and becomes open. Default is `consecutiveFailures > 5`. |
|
||||
| `circuitBreakerScope` | Specify whether circuit breaking state should be scoped to an individual actor ID, all actors across the actor type, or both. Possible values include `id`, `type`, or `both`|
|
||||
| `circuitBreakerCacheSize` | Specify a cache size for the number of circuit breakers to keep in memory. Prvovide an integer value, for example `5000`. |
|
||||
| `circuitBreakerCacheSize` | Specify a cache size for the number of CBs to keep in memory. The value should be larger than the expected number of active actor instances. Provide an integer value, for example `5000`. |
|
||||
|
||||
Example:
|
||||
```yaml
|
||||
|
|
|
|||
|
|
@ -104,7 +104,7 @@ spec:
|
|||
duration: 5s
|
||||
maxRetries: 3
|
||||
|
||||
# circuit breakers are automatically instantiated per component and app endpoint.
|
||||
# circuit breakers are automatically instantiated per component and app instance.
|
||||
# circuit breakers maintain counters that live as long as the Dapr sidecar is running. They are not persisted.
|
||||
circuitBreakers:
|
||||
simpleCB:
|
||||
|
|
@ -124,7 +124,7 @@ spec:
|
|||
appB:
|
||||
timeout: general
|
||||
retry: important
|
||||
# circuit breakers for services are scoped per endpoint (e.g. hostname + port).
|
||||
# circuit breakers for services are scoped app instance.
|
||||
# when a breaker is tripped, that route is removed from load balancing for the configured `timeout` duration.
|
||||
circuitBreaker: simpleCB
|
||||
|
||||
|
|
|
|||
|
|
@ -7,16 +7,16 @@ description: "Apply resiliency policies to apps, components and actors"
|
|||
---
|
||||
|
||||
### Targets
|
||||
Named policies are applied to targets. Dapr supports 3 target types that cover all Dapr building blocks, except observability:
|
||||
Named policies are applied to targets. Dapr supports three target types that apply all Dapr building block APIs:
|
||||
- `apps`
|
||||
- `components`
|
||||
- `actors`
|
||||
|
||||
Fault tolerance behaviors might differ between target types, as some targets may already include resilient capabilities; for example, [service invocation with built-in retries]({{< ref "service-invocation-overview.md#retries" >}}).
|
||||
|
||||
#### Apps
|
||||
|
||||
With the `apps` target, you can apply `retry`, `timeout`, and `circuitBreaker` policies to service invocation calls between Dapr apps. Under `targets/apps`, policies are applied to each target service's `app-id`. The policies are invoked when a network failure occurs in communication between sidecars (as pictured in the diagram above).
|
||||
With the `apps` target, you can apply `retry`, `timeout`, and `circuitBreaker` policies to service invocation calls between Dapr apps. Under `targets/apps`, policies are applied to each target service's `app-id`. The policies are invoked when a failure occurs in communication between sidecars, as shown in the diagram below.
|
||||
|
||||
> Dapr provides [built-in service invocation retries]({{< ref "service-invocation-overview.md#retries" >}}), so any applied `retry` policies are additional.
|
||||
|
||||
<img src="/images/resiliency_svc_invocation.png" width=1000 alt="Diagram showing service invocation resiliency" />
|
||||
|
||||
|
|
@ -32,13 +32,12 @@ specs:
|
|||
circuitBreaker: general
|
||||
```
|
||||
|
||||
> Dapr provides [built-in service invocation retries]({{< ref "service-invocation-overview.md#retries" >}}), so any applied `retry` policies are additional.
|
||||
|
||||
#### Components
|
||||
|
||||
With the `components` target, you can apply `retry`, `timeout` and `circuitBreaker` policies to component operations.
|
||||
|
||||
Policies can be applied for `outbound` operations (calls to the Dapr sidecar) and/or `inbound` (the sidecar calling your app). At this time, *inbound* only applies to PubSub and InputBinding components.
|
||||
Policies can be applied for `outbound` operations (calls to the Dapr sidecar) and/or `inbound` (the sidecar calling your app).
|
||||
|
||||
##### Outbound
|
||||
|
||||
|
|
@ -48,9 +47,9 @@ Policies can be applied for `outbound` operations (calls to the Dapr sidecar) an
|
|||
- Publishing a message.
|
||||
- Invoking an output binding.
|
||||
|
||||
<img src="/images/resiliency_outbound.png" width=1000 alt="Diagram showing service invocation resiliency">
|
||||
> Some components may have built-in retry capabilities and are configured on a per-component basis.
|
||||
|
||||
Some components have built-in `retry` capabilities and are configured on a per-component basis.
|
||||
<img src="/images/resiliency_outbound.png" width=1000 alt="Diagram showing service invocation resiliency">
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
|
|
@ -58,8 +57,8 @@ spec:
|
|||
components:
|
||||
myStateStore:
|
||||
outbound:
|
||||
retry: pubsubRetry
|
||||
circuitBreaker: pubsubCB
|
||||
retry: retryForever
|
||||
circuitBreaker: simpleCB
|
||||
```
|
||||
|
||||
##### Inbound
|
||||
|
|
@ -67,12 +66,12 @@ spec:
|
|||
`inbound` operations are calls from the sidecar to your application, such as:
|
||||
|
||||
- Subscriptions when delivering a message.
|
||||
- Inbound bindings.
|
||||
- Input bindings.
|
||||
|
||||
> Some components may have built-in retry capabilities and are configured on a per-component basis.
|
||||
|
||||
<img src="/images/resiliency_inbound.png" width=1000 alt="Diagram showing service invocation resiliency" />
|
||||
|
||||
Some components have built-in `retry` capabilities and are configured on a per-component basis.
|
||||
|
||||
```yaml
|
||||
spec:
|
||||
targets:
|
||||
|
|
@ -106,7 +105,7 @@ spec:
|
|||
|
||||
#### Actors
|
||||
|
||||
With the `actors` target, you can apply `retry`, `timeout`, and `circuitBreaker` policies to actor operations. Policy assignments are optional.
|
||||
With the `actors` target, you can apply `retry`, `timeout`, and `circuitBreaker` policies to actor operations.
|
||||
|
||||
When using a `circuitBreaker` policy, you can specify whether circuit breaking state should be scoped to:
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue