mirror of https://github.com/dapr/docs.git
updates per Mark
Signed-off-by: Hannah Hunter <hannahhunter@microsoft.com>
This commit is contained in:
parent
2a7d3221be
commit
4bc2739b47
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
type: docs
|
||||
title: "Actors features and concepts"
|
||||
linkTitle: "Features and concepts"
|
||||
title: "Actor runtime features"
|
||||
linkTitle: "Runtime features"
|
||||
weight: 20
|
||||
description: "Learn more about the features and concepts of Actors in Dapr"
|
||||
aliases:
|
||||
|
@ -24,12 +24,19 @@ An actor is automatically activated (causing an actor object to be constructed)
|
|||
|
||||
## Distribution and failover
|
||||
|
||||
To provide scalability and reliability, actors instances are distributed throughout the cluster and Dapr automatically migrates them from failed nodes to healthy ones as required.
|
||||
To provide scalability and reliability, actors instances are distributed throughout the cluster and Dapr automatically migrates them from failed nodes to healthy ones as required.
|
||||
|
||||
Actors are distributed across the instances of the actor service, and those instance are distributed across the nodes in a cluster. Each service instance contains a set of actors for a given actor type.
|
||||
|
||||
### Actor placement service
|
||||
The Dapr actor runtime manages distribution scheme and key range settings for you. This is done by the actor `Placement` service. When a new instance of a service is created, the corresponding Dapr runtime registers the actor types it can create and the `Placement` service calculates the partitioning across all the instances for a given actor type. This table of partition information for each actor type is updated and stored in each Dapr instance running in the environment and can change dynamically as new instance of actor services are created and destroyed. This is shown in the diagram below.
|
||||
|
||||
The Dapr actor runtime manages distribution scheme and key range settings for you via the actor `Placement` service. When a new instance of a service is created:
|
||||
|
||||
1. The sidecar makes a call to the actor service to retrieve registered actor types and configuration settings.
|
||||
1. The corresponding Dapr runtime registers the actor types it can create.
|
||||
1. The `Placement` service calculates the partitioning across all the instances for a given actor type.
|
||||
|
||||
This partition data table for each actor type is updated and stored in each Dapr instance running in the environment and can change dynamically as new instances of actor services are created and destroyed.
|
||||
|
||||
<img src="/images/actors_background_placement_service_registration.png" width=600>
|
||||
|
||||
|
@ -37,12 +44,14 @@ When a client calls an actor with a particular id (for example, actor id 123), t
|
|||
|
||||
<img src="/images/actors_background_id_hashing_calling.png" width=600>
|
||||
|
||||
This simplifies some choices but also carries some consideration:
|
||||
This simplifies some choices, but also carries some consideration:
|
||||
|
||||
* By default, actors are randomly placed into pods resulting in uniform distribution.
|
||||
* Because actors are randomly placed, it should be expected that actor operations always require network communication, including serialization and deserialization of method call data, incurring latency and overhead.
|
||||
- By default, actors are randomly placed into pods resulting in uniform distribution.
|
||||
- Because actors are randomly placed, it should be expected that actor operations always require network communication, including serialization and deserialization of method call data, incurring latency and overhead.
|
||||
|
||||
Note: The Dapr actor Placement service is only used for actor placement and therefore is not needed if your services are not using Dapr actors. The Placement service can run in all [hosting environments]({{< ref hosting >}}), including self-hosted and Kubernetes.
|
||||
{{% alert title="Note" color="primary" %}}
|
||||
Note: The Dapr actor Placement service is only used for actor placement and therefore is not needed if your services are not using Dapr actors. The Placement service can run in all [hosting environments]({{< ref hosting >}}), including self-hosted and Kubernetes.
|
||||
{{% /alert %}}
|
||||
|
||||
## Actor communication
|
||||
|
||||
|
|
|
@ -24,12 +24,14 @@ Every actor is defined as an instance of an actor type, identical to the way an
|
|||
|
||||
## Dapr actors vs. Dapr Workflow
|
||||
|
||||
Dapr actors and [Dapr Workflow]({{< ref workflow-overview.md >}}) are two different Dapr components that provide different features for building distributed applications.
|
||||
Dapr actors builds on the state management and service invocation APIs to create stateful, long running objects with identity. [Dapr Workflow]({{< ref workflow-overview.md >}}) and Dapr Actors are related, with workflows building on actors to provide a higher level of abstraction to orchestrate a set of actors, implementing common workflow patterns and managing the lifecycle of actors on your behalf.
|
||||
|
||||
Dapr actors are designed to provide a way to encapsulate state and behavior within a distributed system. An actor can be activated on demand by a client application. When an actor is activated, it is assigned a unique identity, which allows it to maintain its state across multiple invocations. This makes actors useful for building stateful, scalable, and fault-tolerant distributed applications.
|
||||
|
||||
On the other hand, Dapr Workflow provides a way to define and orchestrate complex workflows that involve multiple services and components within a distributed system. Workflows allow you to define a sequence of steps or tasks that need to be executed in a specific order, and can be used to implement business processes, event-driven workflows, and other similar scenarios.
|
||||
|
||||
As mentioned above, Dapr Workflow builds on Dapr Actors managing their activation and lifecycle.
|
||||
|
||||
### When to use Dapr actors
|
||||
|
||||
As with any other technology decision, you should decide whether to use actors based on the problem you're trying to solve. For example, if you were building a chat application, you might use Dapr actors to implement the chat rooms and the individual chat sessions between users, as each chat session needs to maintain its own state and be scalable and fault-tolerant.
|
||||
|
@ -63,23 +65,11 @@ An actor's state outlives the object's lifetime, as state is stored in the confi
|
|||
|
||||
To provide scalability and reliability, actors instances are throughout the cluster and Dapr distributes actor instances throughout the cluster and automatically migrates them to healthy nodes.
|
||||
|
||||
#### Actor placement service
|
||||
|
||||
The Dapr actor runtime manages distribution scheme and key range settings for you via the actor `Placement` service.
|
||||
|
||||
<img src="/images/actors_background_placement_service_registration.png" width=600>
|
||||
|
||||
When a new instance of a service is created:
|
||||
|
||||
1. The sidecar makes a call to the actor service to retrieve registered actor types and configuration settings.
|
||||
1. The corresponding Dapr runtime registers the actor types it can create.
|
||||
1. The `Placement` service calculates the partitioning across all the instances for a given actor type.
|
||||
|
||||
[Learn more about Dapr actor placement.]({{< ref "actors-features-concepts.md#actor-placement-service" >}})
|
||||
|
||||
#### Actor communication
|
||||
### Actor communication
|
||||
|
||||
You can interact with Dapr to invoke the actor method by calling HTTP/gRPC endpoint, like the example in the diagram below.
|
||||
You can invoke actor methods by calling them over HTTP, as shown in the general example below.
|
||||
|
||||
<img src="/images/actors_background_placement_service_registration.png" width=600>
|
||||
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
type: docs
|
||||
title: "Actor runtime configuration parameters"
|
||||
linkTitle: "Runtime configuration"
|
||||
weight: 40
|
||||
weight: 30
|
||||
description: Modify the default Dapr actor runtime configuration behavior
|
||||
---
|
||||
|
||||
|
|
|
@ -2,7 +2,7 @@
|
|||
type: docs
|
||||
title: "Actors timers and reminders"
|
||||
linkTitle: "Timers and reminders"
|
||||
weight: 30
|
||||
weight: 40
|
||||
description: "Setting timers and reminders and performing error handling for your actors"
|
||||
aliases:
|
||||
- "/developing-applications/building-blocks/actors/actors-background"
|
||||
|
|
|
@ -28,7 +28,7 @@ Alternatively, you can use [Dapr SDKs to use actors]({{< ref "developing-applica
|
|||
|
||||
You can interact with Dapr via HTTP/gRPC endpoints to save state reliably using the Dapr actor state mangement capabaility.
|
||||
|
||||
To use actors, your state store must support multi-item transactions. This means your [state store component](https://github.com/dapr/components-contrib/tree/master/state) must implement the [`TransactionalStore`](https://github.com/dapr/components-contrib/blob/master/state/transactional_store.go) interface.
|
||||
To use actors, your state store must support multi-item transactions. This means your state store component must implement the `TransactionalStore` interface.
|
||||
|
||||
[See the list of components that support transactions/actors]({{< ref supported-state-stores.md >}}). Only a single state store component can be used as the state store for all actors.
|
||||
|
||||
|
|
Loading…
Reference in New Issue