Overview

Dapr provides a capability for defining and applying fault tolerance resiliency policies via a resiliency spec. Resiliency specs are saved in the same location as components specs and are applied when the Dapr sidecar starts. The sidecar determines how to apply resiliency policies to your Dapr API calls. In self-hosted mode, the resiliency spec must be named . In Kubernetes Dapr finds the named resiliency specs used by your application. Within the resiliency spec, you can define policies for popular resiliency patterns, such as:

Additionally, resiliency policies can be .

  1. apiVersion: dapr.io/v1alpha1
  2. kind: Resiliency
  3. metadata:
  4. name: myresiliency
  5. # similar to subscription and configuration specs, scopes lists the Dapr App IDs that this
  6. # resiliency spec can be used by.
  7. scopes:
  8. - app1
  9. - app2
  10. spec:
  11. # policies is where timeouts, retries and circuit breaker policies are defined.
  12. # each is given a name so they can be referred to from the targets section in the resiliency spec.
  13. policies:
  14. # timeouts are simple named durations.
  15. timeouts:
  16. general: 5s
  17. important: 60s
  18. largeResponse: 10s
  19. # retries are named templates for retry configurations and are instantiated for life of the operation.
  20. retries:
  21. pubsubRetry:
  22. policy: constant
  23. duration: 5s
  24. maxRetries: 10
  25. retryForever:
  26. policy: exponential
  27. maxRetries: -1 # retry indefinitely
  28. important:
  29. policy: constant
  30. maxRetries: 30
  31. someOperation:
  32. policy: exponential
  33. maxInterval: 15s
  34. largeResponse:
  35. policy: constant
  36. duration: 5s
  37. maxRetries: 3
  38. # circuit breakers are automatically instantiated per component and app instance.
  39. # circuit breakers maintain counters that live as long as the Dapr sidecar is running. They are not persisted.
  40. circuitBreakers:
  41. simpleCB:
  42. maxRequests: 1
  43. timeout: 30s
  44. trip: consecutiveFailures >= 5
  45. pubsubCB:
  46. maxRequests: 1
  47. interval: 8s
  48. timeout: 45s
  49. trip: consecutiveFailures > 8
  50. # targets are what named policies are applied to. Dapr supports 3 target types - apps, components and actors
  51. targets:
  52. apps:
  53. appB:
  54. timeout: general
  55. retry: important
  56. # circuit breakers for services are scoped app instance.
  57. actors:
  58. myActorType: # custom Actor Type Name
  59. timeout: general
  60. retry: important
  61. # circuit breakers for actors are scoped by type, id, or both.
  62. # when a breaker is tripped, that type or id is removed from the placement table for the configured `timeout` duration.
  63. circuitBreaker: simpleCB
  64. circuitBreakerScope: both ##
  65. circuitBreakerCacheSize: 5000
  66. components:
  67. # for state stores, policies apply to saving and retrieving state.
  68. statestore1: # any component name -- happens to be a state store here
  69. outbound:
  70. timeout: general
  71. retry: retryForever
  72. # circuit breakers for components are scoped per component configuration/instance. For example myRediscomponent.
  73. # when this breaker is tripped, all interaction to that component is prevented for the configured `timeout` duration.
  74. circuitBreaker: simpleCB
  75. pubsub1: # any component name -- happens to be a pubsub broker here
  76. outbound:
  77. retry: pubsubRetry
  78. circuitBreaker: pubsubCB
  79. pubsub2: # any component name -- happens to be another pubsub broker here
  80. outbound:
  81. retry: pubsubRetry
  82. circuitBreaker: pubsubCB
  83. inbound: # inbound only applies to delivery from sidecar to app
  84. timeout: general
  85. retry: important

Watch this video for how to use resiliency:

Next steps