Dapr - actors之构建块(2)

How it works

工作原理

The Dapr sidecar provides the HTTP/gRPC API to invoke actors. This is the base URL of the HTTP API:

Dapr 挎斗提供了用于调用Actor 的 HTTP/gRPC API。 这是 HTTP API 的基 URL：

http://localhost:<daprPort>/v1.0/actors/<actorType>/<actorId>/

• <daprPort>: the HTTP port that Dapr listens on.
• <daprPort>： Dapr 侦听的 HTTP 端口。
• <actorType>: the actor type.
• <actorType>：执行组件类型。
• <actorId>: the ID of the specific actor to call.
• <actorId>：要调用的特定Actor的 ID。

The sidecar manages how, when and where each actor runs, and also routes messages between actors. When an actor hasn't been used for a period of time, the runtime deactivates the actor and removes it from memory. Any state managed by the actor is persisted and will be available when the actor re-activates. Dapr uses an idle timer to determine when an actor can be deactivated. When an operation is called on the actor (either by a method call or a reminder firing), the idle timer is reset and the actor instance will remain activated.

挎斗管理每个Actor 的运行时间和位置，以及在Actor之间路由消息的方式。 如果一段时间未使用某个Actor，则运行时将停用该执行组件，并将其从内存中删除。 Actor 所管理的任何状态都将被保留，并在Actor 重新激活时可用。 Dapr 使用空闲计时器来确定何时可以停用Actor。 当在Actor 上调用操作时 (通过方法调用或提醒触发) ，会重置空闲计时器，并保持激活执行组件实例。

The sidecar API is only one part of the equation. The service itself also needs to implement an API specification, because the actual code that you write for the actor will run inside the service itself. Figure 11-1 shows the various API calls between the service and its sidecar:

挎斗 API 只是公式的一部分。 服务本身还需要实现 API 规范，因为你为Actor 编写的实际代码将在服务本身内运行。 图11-1 显示了服务和它的挎斗之间的各种 API 调用：

Figure 11-1. API calls between actor service and Dapr sidecar.

图 11-1。 actor服务和 Dapr 挎斗之间的 API 调用。

To provide scalability and reliability, actors are partitioned across all the instances of the actor service. The Dapr placement service is responsible for keeping track of the partitioning information. When a new instance of an actor service is started, the sidecar registers the supported actor types with the placement service. The placement service calculates the updated partitioning information for the given actor type and broadcasts it to all instances. Figure 11-2 shows what happens when a service is scaled out to a second replica:

为了提供可伸缩性和可靠性，将在Actor服务的所有实例中对actor进行分区。 Dapr placement  服务负责跟踪分区信息。 启动Actor 服务的新实例时，挎斗会将支持的Actor 类型注册到placement 服务。 placement 服务计算给定Actor 类型的更新分区信息，并将其广播给所有实例。 图11-2 显示了将服务扩展到第二个副本时发生的情况：

igure 11-2. Actor placement service.

1. On startup, the sidecar makes a call to the actor service to get the registered actor types as well as actor configuration settings.
2. The sidecar sends the list of registered actor types to the placement service.
3. The placement service broadcasts the updated partitioning information to all actor service instances. Each instance will keep a cached copy of the partitioning information and use it to invoke actors.

1. 启动时，挎斗调用actor服务以获取注册的Actor类型和Actor的配置设置。
2. 挎斗将注册的Actor类型的列表发送到placement 服务。
3. placement 服务会将更新的分区信息广播到所有Actor服务实例。 每个实例都将保留分区信息的缓存副本，并使用它来调用Actor。