Clean up overview

Signed-off-by: Nick Greenfield <nigreenf@microsoft.com>
This commit is contained in:
Nick Greenfield 2022-04-06 13:04:56 -07:00
parent 788726afc4
commit 6914f9b184
3 changed files with 8 additions and 50 deletions

View File

@ -6,28 +6,13 @@ weight: 4500
description: "Configure resiliency policies for timeouts, retries/backoffs and circuit breakers"
---
Resiliency is currently a preview feature. Before you can utilize a resiliency spec, you must first [enable the resiliency preview feature]({{< ref preview-features >}}).
#### Enablethe resiliency:
```yaml
apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
name: featureconfig
spec:
features:
- name: Resiliency
enabled: true
```
### Policies
You define timeouts, retries and circuit breaker policies under `policies`. Each policy is given a name so you can refer to them from the `targets` section in the resiliency spec.
#### Timeouts
Timeouts can be used to early-terminate long-running operations. If you've exceeded timeout:
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).
- An error is returned.

View File

@ -5,28 +5,12 @@ linkTitle: "Overview"
weight: 4500
description: "Configure Dapr retries, timeouts, and circuit breakers"
---
Resiliency is currently a preview feature. Before you can utilize a resiliency spec, you must first [enable the resiliency preview feature]({{< ref preview-features >}}).
#### Enable resiliency:
```yaml
apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
name: featureconfig
spec:
features:
- name: Resiliency
enabled: true
```
## Introduction
{{% alert title="Note" color="primary" %}}
Resiliency is currently a preview feature. Before you can utilize a resiliency spec, you must first [enable the resiliency preview feature]({{< ref support-preview-features >}}).
{{% /alert %}}
Distributed applications are commonly comprised of many moving pieces, with dozens, even hundreds, of instances for any given service. With so many moving pieces, the likelihood of a system failure increases. For example, an instance can fail due to hardware failures, an overwhelming number of requests, application restarts/scale outs, or any other reason. These events can cause a network call between services to fail. Designing and implementing your application with fault tolerance (the ability to detect, mitigate, and respond to failures) allows your application to recover quickly to a functioning state.
## Overview
Dapr provides a mechanism for defining and applying fault tolerance/resiliency policies via a [resiliency spec]({{< ref "resiliency-overview.md#complete-example-policy" >}}). The resiliency spec is defined in the same location as components and is applied when the Dapr sidecar starts. The sidecar determines when and how to apply resiliency policies to your Dapr API calls. In self-hosted mode, the resiliency spec must be named `resiliency.yaml`. In Kubernetes Dapr scans all resiliency specs. Within the resiliency spec, you can define policies for popular resiliency patterns, such as:
- [Timeouts]({{< ref "policies.md#timeouts" >}})
@ -178,3 +162,7 @@ spec:
retry: important
circuitBreaker: pubsubCB
```
## Related links
- [Policies]({{< ref "policies.md" >}})
- [Targets]({{< ref "targets.md" >}})

View File

@ -6,21 +6,6 @@ weight: 4500
description: "Apply resiliency policies to apps, components and actors"
---
Resiliency is currently a preview feature. Before you can utilize a resiliency spec, you must first [enable the resiliency preview feature]({{< ref preview-features >}}).
#### Enablethe resiliency:
```yaml
apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
name: featureconfig
spec:
features:
- name: Resiliency
enabled: true
```
### Targets
Named policies are applied to targets. Dapr supports 3 target types that cover all Dapr building blocks, except observability:
- `apps`