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

Add documentation for generic resiliency policies 

This commit adds an overview of the generic policies, their keywords,
and a brief example of how they are chosen.

https://github.com/dapr/docs/issues/2664

Signed-off-by: Hal Spang <halspang@microsoft.com>
This commit is contained in:
Hal Spang 2022-10-06 17:40:43 -07:00
parent e6b57063b1
commit 30ba289976
1 changed files with 61 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -132,4 +132,64 @@ spec:
apps:
appB: # app-id of the target service
retry: retryForever
```
```
#### Utilize Generic Policies
Dapr Resiliency also lets you define policies that can have a broader scope than the standard ones defined above. This is done through the usage of keywords that let Dapr know when to apply the given policy. There are 3 base policies:
- DefaultRetryPolicy
- DefaultTimeoutPolicy
- DefaultCircuitBreakerPolicy
If these policies are defined, they would be used for every operation to a service, application, or component. They can also be modified to be more specific through the usage of additional keywords. The specific policies follow the following pattern, `Default%sRetryPolicy`. Where the `%s` is replaced by the new target of the policy. Below you can see a table of all possible default policy names.
| Keyword | Target Operation | Policy Name |
| ------------------------------ | ---------------------------------------------------- | ------------------------------------------- |
| App | Service invocation. | DefaultAppRetryPolicy |
| Actor | Actor invocation. | DefaultActorRetryPolicy |
| Component | All component operations. | DefaultComponentRetryPolicy |
| ComponentInbound | All inbound component operations. | DefaultComponentInboundPolicy |
| ComponentOutbound | All outbound component operations. | DefaultComponentOutboundPolicy |
| StatestoreComponentOutbound | All statestore component operations. | DefaultStatestoreComponentOutboundPolicy |
| PubsubComponentOutbound | All outbound pubusub (publish) component operations. | DefaultPubsubComponentOutboundPolicy |
| PubsubComponentInbound | All inbound pubsub (subscribe) component operations. | DefaultPubsubComponentInboundPolicy |
| BindingComponentOutbound | All outbound binding (invoke) component operations. | DefaultBindingComponentOutboundPolicy |
| BindingComponentInbound | All inbound binding (read) component operations. | DefaultBindingComponentInboundPolicy |
| SecretstoreComponentOutbound | All secretstore component operations. | DefaultSecretstoreComponentPolicy |
| ConfigurationComponentOutbound | All configuration component operations. | DefaultConfigurationComponentOutboundPolicy |
| LockComponentOutbound | All lock component operations. | DefaultLockComponentOutboundPolicy |
For all generic policies, they will only be used if the operation being executed matches the policy and if there is no more specific policy targeting it.
For example, we have a system with 3 applications, AppA, AppB, and AppC. The following resiliency configuration is applied to the cluster:
```yaml
spec:
policies:
retries:
DefaultRetryPolicy:
policy: constant
duration: 5s
maxRetries: 10
fastRetries:
policy: constant
duration: 1s
maxRetries: 3
retryForever:
policy: exponential
maxInterval: 15s
maxRetries: -1 # Retry indefinitely
targets:
apps:
appA:
retry: fastRetries
appB:
retry: retryForever
```
In this scenario, when AppA is called, the `fastRetries` policy will be used. For AppB, `retryForever` will be used. Finally, when calling AppC, `DefaultRetryPolicy` will be called even though it was never applied via a target.