dapr
/
docs
mirror of https://github.com/dapr/docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

PR feedback 

Signed-off-by: Nick Greenfield <nigreenf@microsoft.com>
This commit is contained in:
Nick Greenfield 2022-04-06 15:22:47 -07:00
parent ef686fdfa1
commit 3f5b4887bb
3 changed files with 21 additions and 22 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
daprdocs/content/en/operations/resiliency/policies.md
View File

@ -3,7 +3,7 @@ type: docs
title: "Policies" title: "Policies"
linkTitle: "Policies" linkTitle: "Policies"
weight: 4500 weight: 4500
description: "Configure resiliency policies for timeouts, retries/backoffs and circuit breakers" description: "Configure resiliency policies for timeouts, retries and circuit breakers"
--- ---
### Policies ### 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: 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. - An error is returned.
Valid values are of the form `15s`, `2m`, `1h30m`, etc. 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 | | Retry option | Description |
| ------------ | ----------- | | ------------ | ----------- |
| `policy` | Determines the back-off and retry interval strategy. Valid values are `constant` and `exponential`. Defaults to `constant`. | | `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. | | `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 | | `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`. | | `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: 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 | | 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`. | | `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`. | | `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`. | | `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`| | `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: Example:
```yaml ```yaml

4
daprdocs/content/en/operations/resiliency/resiliency-overview.md
View File

@ -104,7 +104,7 @@ spec:
duration: 5s duration: 5s
maxRetries: 3 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. # circuit breakers maintain counters that live as long as the Dapr sidecar is running. They are not persisted.
circuitBreakers: circuitBreakers:
simpleCB: simpleCB:
@ -124,7 +124,7 @@ spec:
appB: appB:
timeout: general timeout: general
retry: important 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. # when a breaker is tripped, that route is removed from load balancing for the configured `timeout` duration.
circuitBreaker: simpleCB circuitBreaker: simpleCB

27
daprdocs/content/en/operations/resiliency/targets.md
View File

@ -7,16 +7,16 @@ description: "Apply resiliency policies to apps, components and actors"
--- ---
### Targets ### 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` - `apps`
- `components` - `components`
- `actors` - `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 #### 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" /> <img src="/images/resiliency_svc_invocation.png" width=1000 alt="Diagram showing service invocation resiliency" />
@ -32,13 +32,12 @@ specs:
circuitBreaker: general circuitBreaker: general
``` ```
> Dapr provides [built-in service invocation retries]({{< ref "service-invocation-overview.md#retries" >}}), so any applied `retry` policies are additional.
#### Components #### Components
With the `components` target, you can apply `retry`, `timeout` and `circuitBreaker` policies to component operations. 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 ##### Outbound
@ -48,9 +47,9 @@ Policies can be applied for `outbound` operations (calls to the Dapr sidecar) an
- Publishing a message. - Publishing a message.
- Invoking an output binding. - 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 ```yaml
spec: spec:
@ -58,8 +57,8 @@ spec:
components: components:
myStateStore: myStateStore:
outbound: outbound:
retry: pubsubRetry retry: retryForever
circuitBreaker: pubsubCB circuitBreaker: simpleCB
``` ```
##### Inbound ##### Inbound
@ -67,12 +66,12 @@ spec:
`inbound` operations are calls from the sidecar to your application, such as: `inbound` operations are calls from the sidecar to your application, such as:
- Subscriptions when delivering a message. - 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" /> <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 ```yaml
spec: spec:
targets: targets:
@ -106,7 +105,7 @@ spec:
#### Actors #### 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: When using a `circuitBreaker` policy, you can specify whether circuit breaking state should be scoped to: