This is the multi-page printable view of this section. Click here to print.
Dapr 服务概述
1 - Dapr 边车(daprd)概述
Dapr 使用边车模式,这意味着 Dapr API 在一个单独的进程中运行和暴露,该进程称为 Dapr 边车,与您的应用并行运行。Dapr 边车进程名为 daprd,根据托管环境的不同,以不同的方式启动。
Dapr 边车暴露:
当应用在其配置的端口上可访问时,Dapr 边车将达到就绪状态。在应用启动/初始化期间,应用无法访问 Dapr 组件。

边车 API 通过本地 http 或 gRPC 端点从您的应用调用。

自托管模式下使用 dapr run
当 Dapr 以自托管模式安装时,daprd 二进制文件会被下载并放置在用户主目录下(Linux/macOS 为 $HOME/.dapr/bin,Windows 为 %USERPROFILE%\.dapr\bin\)。
在自托管模式下,运行 Dapr CLI 的 run 命令 会使用提供的应用可执行文件启动 daprd 可执行文件。这是在本地开发和测试等场景中运行 Dapr 边车的推荐方式。
您可以在 Dapr run 命令参考 中找到 CLI 暴露的用于配置边车的各种参数。
Kubernetes 集群中使用 dapr-sidecar-injector
在 Kubernetes 上,Dapr 控制平面包含 dapr-sidecar-injector 服务,该服务监视带有 dapr.io/enabled 注解的新 Pod,并在 Pod 内注入一个包含 daprd 进程的容器。在这种情况下,边车参数可以通过注解传递,如此表中的 Kubernetes 注解 列所述。
原生边车(Kubernetes 1.28+)
默认情况下,daprd 作为常规容器与您的应用一起注入。使用 Kubernetes 原生边车(KEP-753),daprd 改为作为带有 restartPolicy: Always 的初始化容器注入。有关行为和生命周期语义的详细信息,请参阅 Kubernetes 边车容器文档。
通过 Helm 全局启用原生边车:
dapr_sidecar_injector:
nativeSidecar: true
或通过注解按 Pod 启用:
annotations:
dapr.io/enabled: "true"
dapr.io/enable-native-sidecar: "true"
直接运行边车
在大多数情况下,您不需要显式运行 daprd,因为边车由 CLI(自托管模式)或 dapr-sidecar-injector 服务(Kubernetes)启动。对于高级用例(调试、脚本部署等),可以直接启动 daprd 进程。
有关所有可用参数的详细列表,请运行 daprd --help 或参阅此表,该表概述了 daprd 参数与 CLI 参数和 Kubernetes 注解的关联方式。
示例
通过指定唯一 ID 在应用旁边启动边车。
注意:
--app-id是必填字段,且不能包含点。daprd --app-id myapp指定应用正在监听的端口
daprd --app-id myapp --app-port 5000如果您使用多个自定义资源并希望指定资源定义文件的位置,请使用
--resources-path参数:daprd --app-id myapp --resources-path <PATH-TO-RESOURCES-FILES>如果您将组件和其他资源(例如,弹性策略、订阅或配置)组织到单独的文件夹或共享文件夹中,可以指定多个资源路径:
daprd --app-id myapp --resources-path <PATH-1-TO-RESOURCES-FILES> --resources-path <PATH-2-TO-RESOURCES-FILES>运行应用时启用 Prometheus 指标收集
daprd --app-id myapp --enable-metrics仅监听 IPv4 和 IPv6 回环地址
daprd --app-id myapp --dapr-listen-addresses '127.0.0.1,[::1]'
2 - Dapr Operator 控制平面服务概述
在 Kubernetes 模式下运行 Dapr 时,运行 Dapr Operator 服务的 Pod 管理 Dapr 组件 更新,并为 Dapr 提供 Kubernetes 服务端点。
运行 Operator 服务
Operator 服务作为 dapr init -k 的一部分部署,或通过 Dapr Helm charts 部署。有关在 Kubernetes 上运行 Dapr 的更多信息,请访问 Kubernetes 托管页面。
其他配置选项
Operator 服务包含其他配置选项。
注入器看门狗
Operator 服务包含 注入器看门狗 功能,该功能定期轮询 Kubernetes 集群中运行的所有 Pod,并确认 Dapr 边车已注入到具有 dapr.io/enabled=true 注解的 Pod 中。该功能主要用于处理 注入器服务 未能成功将边车(daprd 容器)注入到 Pod 的场景。
注入器看门狗在多种情况下都很有用,包括:
从完全停止的 Kubernetes 集群中恢复。当集群完全停止然后重新启动时(包括集群完全故障的情况),Pod 以随机顺序重启。如果应用程序在 Dapr 控制平面(特别是注入器服务)准备就绪之前重启,Dapr 边车可能无法注入到应用程序的 Pod 中,导致应用程序行为异常。
解决边车注入器潜在的随机故障,例如注入器服务内部的瞬时故障。
如果看门狗检测到应该有边车但没有边车的 Pod,它将删除该 Pod。然后 Kubernetes 将重新创建该 Pod,再次调用 Dapr 边车注入器。
注入器看门狗功能默认禁用。
您可以通过向 operator 命令传递 --watch-interval 标志来启用它,该标志可以采用以下值之一:
--watch-interval=0:禁用注入器看门狗(省略该标志时的默认值)。--watch-interval=<interval>:启用注入器看门狗,并按指定间隔轮询所有 Pod;间隔值的字符串包含时间单位。例如:--watch-interval=10s(每 10 秒)或--watch-interval=2m(每 2 分钟)。--watch-interval=once:注入器看门狗在 Operator 服务启动时仅运行一次。
如果使用 Helm,可以使用 dapr_operator.watchInterval 选项配置注入器看门狗,该选项与命令行标志具有相同的值。
在 HA(高可用)模式下运行 Operator 服务时(配置多个副本),注入器看门狗是安全可用的。在此情况下,Kubernetes 会自动选举一个"领导者"实例,这是唯一运行注入器看门狗服务的实例。
然而,在 HA 模式下,如果将注入器看门狗配置为仅"运行一次",当 Operator 服务实例被选为领导者时,看门狗轮询会实际启动。这意味着,如果 Operator 服务的领导者崩溃并选出新的领导者,将再次触发注入器看门狗。
观看此视频,了解注入器看门狗的概览:
3 - Dapr Placement 控制平面服务概述
Dapr Placement 服务用于计算和分发运行在自托管模式或 Kubernetes上的 Dapr actors 位置的分布式哈希表。哈希表按命名空间分组,将 actor 类型映射到 pod 或进程,以便 Dapr 应用程序可以与 actor 通信。每当 Dapr 应用程序激活 Dapr actor 时,Placement 服务会使用最新的 actor 位置更新哈希表。
自托管模式
Placement 服务 Docker 容器作为 dapr init 的一部分自动启动。如果您以 slim-init 模式 运行,也可以作为进程手动运行。
Kubernetes 模式
Placement 服务作为 dapr init -k 的一部分部署,或通过 Dapr Helm 图表部署。您可以在高可用(HA)模式下运行 Placement。了解有关在 Kubernetes 服务中设置 HA 模式的更多信息。
有关在 Kubernetes 上运行 Dapr 的更多信息,请访问 Kubernetes 托管页面。
Placement 表
有一个Placement 服务的 HTTP API /placement/state 用于暴露 placement 表信息。该 API 在 sidecar 上与 healthz 相同的端口上暴露。这是一个未经身份验证的端点,默认情况下被禁用。您需要将 DAPR_PLACEMENT_METADATA_ENABLED 环境变量或 metadata-enabled 命令行参数设置为 true 来启用它。如果您使用 helm,只需将 dapr_placement.metadataEnabled 设置为 true。
重要
当将 actors 部署到不同的命名空间时(https://docs.dapr.io/zh-hans/developing-applications/building-blocks/actors/namespaced-actors/),如果您想阻止从所有命名空间检索 actors,建议禁用metadata-enabled。metadata 端点作用于所有命名空间。用例
placement 表 API 可用于检索当前的 placement 表,其中包含在所有命名空间中注册的所有 actors。这对于调试和允许工具提取并呈现有关 actors 的信息很有帮助。
HTTP 请求
GET http://localhost:<healthzPort>/placement/state
HTTP 响应代码
| 代码 | 描述 |
|---|---|
| 200 | 返回 Placement 表信息 |
| 500 | Placement 无法返回 Placement 表信息 |
HTTP 响应体
Placement 表 API 响应对象
| 名称 | 类型 | 描述 |
|---|---|---|
| tableVersion | int | Placement 表版本 |
| hostList | Actor 主机信息[] | 已注册 actor 主机信息的 json 数组。 |
| 名称 | 类型 | 描述 |
|---|---|---|
| name | string | actor 的 host:port 地址。 |
| appId | string | app id。 |
| actorTypes | json string array | 它托管的 actor 类型列表。 |
| updatedAt | timestamp | actor 注册/更新的时间戳。 |
示例
curl localhost:8080/placement/state
{
"hostList": [{
"name": "198.18.0.1:49347",
"namespace": "ns1",
"appId": "actor1",
"actorTypes": ["testActorType1", "testActorType3"],
"updatedAt": 1690274322325260000
},
{
"name": "198.18.0.2:49347",
"namespace": "ns2",
"appId": "actor2",
"actorTypes": ["testActorType2"],
"updatedAt": 1690274322325260000
},
{
"name": "198.18.0.3:49347",
"namespace": "ns2",
"appId": "actor2",
"actorTypes": ["testActorType2"],
"updatedAt": 1690274322325260000
}
],
"tableVersion": 1
}
禁用 Placement 服务
可以使用以下设置禁用 Placement 服务:
global.actors.enabled=false
在 Kubernetes 模式下,使用此设置不会部署 Placement 服务。这不仅会禁用 actor 部署,还会禁用工作流,因为工作流使用 actors。但是,此设置仅适用于 Kubernetes 模式,而使用 --slim 初始化 Dapr 会阻止在自托管模式下部署 Placement 服务。
有关在 Kubernetes 上运行 Dapr 的更多信息,请访问 Kubernetes 托管页面。
相关链接
4 - Dapr Scheduler 控制平面服务概述
Dapr Scheduler 服务用于调度不同类型的作业,可在自托管模式或 Kubernetes上运行。
- 通过 Jobs API 创建的作业
- Actor reminder 作业(由 actor reminders 使用)
- 由 Workflow API 创建的 actor reminder 作业(使用 actor reminders)
不存在主 Scheduler 实例的概念。 所有 Scheduler 服务副本均被视为对等节点。 所有副本都会接收待调度的作业,并在可用的 Scheduler 服务副本之间进行分配,以实现触发事件的负载均衡。
下图展示了从应用程序调用时,如何通过 Jobs API 使用 Scheduler 服务。Scheduler 服务跟踪的所有作业都存储在 Etcd 数据库中。

默认情况下,Etcd 内嵌于 Scheduler 服务中,这意味着 Scheduler 服务会运行其自己的 Etcd 实例。 有关如何配置 Scheduler 服务的更多信息,请参阅 Scheduler 服务标志。
作业位置性
默认作业行为
当 Scheduler 服务触发作业时,它们会被发送回调度该作业的同一应用 ID 的单个副本,以随机负载均衡的方式进行。 这会在应用程序的副本之间提供基本的负载均衡,适用于大多数不需要严格位置性的用例。
使用 Actor Reminders 实现完全位置性
对于需要完全作业位置性(让作业在创建它们的同一主机上触发)的用户,actor reminders 提供了一种解决方案。 要为作业强制执行完全位置性:
- 创建一个 actor 类型,其中包含一个特定副本独有的随机 UUID
- 使用此 actor 类型创建一个 actor reminder
这种方法确保作业始终在创建它的同一主机上触发,而不是在副本之间随机分布。
作业触发
作业失败策略和暂存队列
当 Scheduler 服务触发作业时遇到客户端错误,默认情况下会以 1 秒间隔重试,最多重试 3 次。
对于非客户端错误,例如,在触发时无法将作业发送到可用的 Dapr 边车,它会被放置在 Scheduler 服务内的暂存队列中。作业会保留在此队列中,直到找到合适的边车实例,此时它们会自动发送到相应的 Dapr 边车实例。
自托管模式
Scheduler 服务 Docker 容器作为 dapr init 的一部分自动启动。如果您在 slim-init 模式下运行,也可以作为进程手动运行。
在自托管部署中,Scheduler 可以在高可用(HA)和非 HA 模式下运行。但是,不建议在生产环境中使用非 HA 模式。如果在非 HA 和 HA 模式之间切换,必须删除现有的数据目录,这会导致作业和 actor reminders 丢失。在进行此更改之前,请运行备份 以避免数据丢失。
Kubernetes 模式
Scheduler 服务作为 dapr init -k 的一部分或通过 Dapr Helm charts 部署。在 Kubernetes 部署中,Scheduler 始终以高可用(HA)模式运行。由于内嵌数据存储的性质,无法在不造成数据丢失的情况下扩展或缩减 Scheduler 服务副本。了解有关在 Kubernetes 服务中设置 HA 模式的更多信息。
当删除 Kubernetes 命名空间时,与该命名空间对应的所有 Job 和 Actor Reminders 也会被删除。
Docker Compose 示例
以下是在 Docker Compose 配置中为独立模式暴露 etcd 端口的方法。 在 HA 模式下运行时,只需暴露一个 scheduler 实例的端口以执行备份操作。
version: "3.5"
services:
scheduler-0:
image: "docker.io/daprio/scheduler:1.18.0"
command:
- "./scheduler"
- "--etcd-data-dir=/var/run/dapr/scheduler"
- "--id=scheduler-0"
- "--etcd-initial-cluster=scheduler-0=http://scheduler-0:2380,scheduler-1=http://scheduler-1:2380,scheduler-2=http://scheduler-2:2380"
ports:
- 2379:2379
volumes:
- ./dapr_scheduler/0:/var/run/dapr/scheduler
scheduler-1:
image: "docker.io/daprio/scheduler:1.18.0"
command:
- "./scheduler"
- "--etcd-data-dir=/var/run/dapr/scheduler"
- "--id=scheduler-1"
- "--etcd-initial-cluster=scheduler-0=http://scheduler-0:2380,scheduler-1=http://scheduler-1:2380,scheduler-2=http://scheduler-2:2380"
volumes:
- ./dapr_scheduler/1:/var/run/dapr/scheduler
scheduler-2:
image: "docker.io/daprio/scheduler:1.18.0"
command:
- "./scheduler"
- "--etcd-data-dir=/var/run/dapr/scheduler"
- "--id=scheduler-2"
- "--etcd-initial-cluster=scheduler-0=http://scheduler-0:2380,scheduler-1=http://scheduler-1:2380,scheduler-2=http://scheduler-2:2380"
volumes:
- ./dapr_scheduler/2:/var/run/dapr/scheduler
使用 Dapr CLI 管理作业
Dapr 提供了一个 CLI 用于检查和管理所有调度的作业,无论类型如何。 CLI 是查看、备份和删除作业的推荐方式。
Scheduler 管理着几种不同类型的作业:
app/{app-id}/{job-name}:通过 Jobs API 创建的作业actor/{actor-type}/{actor-id}/{reminder-name}:通过 Actor Reminders API 创建的 actor reminder 作业activity/{app-id}/{instance-id}::{generation-name}::{activity-index}:用于 Workflow Activity reminders 内部workflow/{app-id}/{instance-id}/{random-name}:用于 工作流 内部。
请参阅此处了解如何使用 CLI 专门管理 reminders。
列出作业
dapr scheduler list
示例输出:
NAME BEGIN COUNT LAST TRIGGER
actor/myactortype/actorid1/test1 -3.89s 1 2025-10-03T16:58:55Z
actor/myactortype/actorid2/test2 -3.89s 1 2025-10-03T16:58:55Z
app/test-scheduler/test1 -3.89s 1 2025-10-03T16:58:55Z
app/test-scheduler/test2 -3.89s 1 2025-10-03T16:58:55Z
activity/test-scheduler/xyz1::0::1 -888.8ms 0
activity/test-scheduler/xyz2::0::1 -888.8ms 0
workflow/test-scheduler/abc1/timer-0-TVIQGkvu +50.0h 0
workflow/test-scheduler/abc2/timer-0-OM2xqG9m +50.0h 0
要获取更多详细信息,请使用宽输出格式:
dapr scheduler list -o wide
NAMESPACE NAME BEGIN EXPIRATION SCHEDULE DUE TIME TTL REPEATS COUNT LAST TRIGGER
default actor/myactortype/actorid1/test1 2025-10-03T16:58:55Z @every 2h46m40s 2025-10-03T17:58:55+01:00 100 1 2025-10-03T16:58:55Z
default actor/myactortype/actorid2/test2 2025-10-03T16:58:55Z @every 2h46m40s 2025-10-03T17:58:55+01:00 100 1 2025-10-03T16:58:55Z
default app/test-scheduler/test1 2025-10-03T16:58:55Z @every 100m 2025-10-03T17:58:55+01:00 1234 1 2025-10-03T16:58:55Z
default app/test-scheduler/test2 2025-10-03T16:58:55Z 2025-10-03T19:45:35Z @every 100m 2025-10-03T17:58:55+01:00 10000s 56788 1 2025-10-03T16:58:55Z
default activity/test-scheduler/xyz1::0::1 2025-10-03T16:58:58Z 0s 0
default activity/test-scheduler/xyz2::0::1 2025-10-03T16:58:58Z 0s 0
default workflow/test-scheduler/abc1/timer-0-TVIQGkvu 2025-10-05T18:58:58Z 2025-10-05T18:58:58Z 0
default workflow/test-scheduler/abc2/timer-0-OM2xqG9m 2025-10-05T18:58:58Z 2025-10-05T18:58:58Z 0
获取作业详细信息
dapr scheduler get app/my-app/job1 -o yaml
删除作业
删除一个或多个特定作业:
dapr scheduler delete app/my-app/job1 actor/MyActor/123/reminder1
使用过滤器批量删除作业:
dapr scheduler delete-all all
dapr scheduler delete-all app/my-app
dapr scheduler delete-all actor/MyActorType
备份和恢复作业
在生产环境中,建议定期备份此数据,备份间隔应与您的恢复点目标保持一致。
Dapr CLI 提供了一个命令,用于将所有 Scheduler 数据导出到特定的二进制文件。
在 Kubernetes 模式下运行时,请使用 -k 标志。
dapr scheduler export -o scheduler-backup.bin
dapr scheduler export -k -o scheduler-backup.bin
要从备份文件恢复数据:
dapr scheduler import -f scheduler-backup.bin
dapr scheduler import -k -f scheduler-backup.bin
监控 Scheduler 的 etcd 指标
转发 Scheduler 实例的端口并使用以下命令查看 etcd 的指标:
curl -s http://localhost:2379/metrics
通过根据需要审查和配置 Scheduler 的 etcd 标志来微调内嵌的 etcd 以满足您的需求。
禁用 Scheduler 服务
如果您未使用任何需要 Scheduler 服务的功能(Jobs API、Actor Reminders 或 Workflows),可以通过设置 global.scheduler.enabled=false 来禁用它。
有关在 Kubernetes 上运行 Dapr 的更多信息,请访问 Kubernetes 托管页面。
标志调优
Scheduler 上暴露了许多 Etcd 标志,可用于针对您的部署用例进行调优。
外部 Etcd 数据库
可以将 Scheduler 配置为使用外部 Etcd 数据库,而不是 Scheduler 服务副本内部内嵌的数据库。 由于集群或环境的管理局以及所使用的存储后端,将存储卷与 Scheduler StatefulSet 或容器解耦可能是很有意义的。 也可能完全将持久存储移出 scheduler 运行时,或者有一些现有的 Etcd 集群提供者将被重用。 外部化 Etcd 数据库也意味着 Scheduler 副本可以随意水平扩展,但请注意,在扩展事件期间,作业触发将会暂停。 Scheduler 副本计数不需要与 Etcd 节点计数约束 匹配。
要使用外部 Etcd 集群,请将 --etcd-embed 标志设置为 false,并提供 --etcd-client-endpoints 标志以及您的 Etcd 集群的端点。
如果 Etcd 集群需要身份验证,还可以选择包括 --etcd-client-username 和 --etcd-client-password 标志。
--etcd-embed bool 启用时,Etcd 数据库内嵌于 scheduler 服务器中。如果为 false,scheduler 使用 --etcd-client-endpoints 标志连接到外部 Etcd 集群。(默认为 true)
--etcd-client-endpoints stringArray 要连接的 etcd 客户端端点的逗号分隔列表。仅在 --etcd-embed 为 false 时使用。
--etcd-client-username string etcd 客户端身份验证的用户名。仅在 --etcd-embed 为 false 时使用。
--etcd-client-password string etcd 客户端身份验证的密码。仅在 --etcd-embed 为 false 时使用。
Helm:
dapr_scheduler.etcdEmbed=true
dapr_scheduler.etcdClientEndpoints=[]
dapr_scheduler.etcdClientUsername=""
dapr_scheduler.etcdClientPassword=""
Etcd 领导者选举调优
为了在故障发生时提高救援节点的领导者选举速度,可以使用以下标志来加快选举过程。
--etcd-initial-election-tick-advance 是否在启动时快进初始选举 ticks 以加快选举。当它为 true 时,本地成员快进选举 ticks 以加速"初始"领导者选举触发。这有利于更大的选举 ticks 的情况。禁用此功能会减慢跨数据中心部署的初始引导过程。通过配置此标志,以缓慢的初始引导为代价来权衡。
Helm:
dapr_scheduler.etcdInitialElectionTickAdvance=true
存储调优
以下选项可用于根据您的部署需求调优内嵌的 Etcd 存储。 可以在 Etcd 文档中找到有关这些标志作用的更深入理解。
注意
更改这些标志会极大地改变 Scheduler 的性能和行为,因此在从 Dapr 设置的默认值修改它们时需要谨慎。 更改这些设置应始终先在测试环境中进行,并在应用于生产环境之前进行密切监控。--etcd-backend-batch-interval string 提交后端事务之前的最大时间。(默认 "50ms")
--etcd-backend-batch-limit int 提交后端事务之前的最大操作数。(默认 5000)
--etcd-compaction-mode string etcd 的压缩模式。可以是 'periodic' 或 'revision'(默认 "periodic")
--etcd-compaction-retention string etcd 的压缩保留。可以表示时间或修订数,取决于 'etcd-compaction-mode' 的值(默认 "10m")
--etcd-experimental-bootstrap-defrag-threshold-megabytes uint etcd 在引导期间考虑运行碎片整理所需释放的最小兆字节数。需要设置为非零值才能生效。(默认 100)
--etcd-max-snapshots uint 要保留的快照文件的最大数量(0 为无限制)。(默认 10)
--etcd-max-wals uint 要保留的预写日志的最大数量(0 为无限制)。(默认 10)
--etcd-snapshot-count uint 触发快照到磁盘的已提交事务数。(默认 10000)
Helm:
dapr_scheduler.etcdBackendBatchInterval="50ms"
dapr_scheduler.etcdBackendBatchLimit=5000
dapr_scheduler.etcdCompactionMode="periodic"
dapr_scheduler.etcdCompactionRetention="10m"
dapr_scheduler.etcdDefragThresholdMB=100
dapr_scheduler.etcdMaxSnapshots=10
相关链接
- 了解有关 Jobs API 的更多信息。
- [了解有关 Actor Reminders 的更多信息。]https://docs.dapr.io/zh-hans/developing-applications/building-blocks/actors/actors-features-concepts/#reminders)
5 - Dapr Sentry 控制平面服务概述
Dapr Sentry 服务管理服务之间的 mTLS 并充当证书颁发机构。它生成 mTLS 证书并将其分发到所有运行的边车。这使边车能够使用加密的 mTLS 流量进行通信。更多信息请阅读边车到边车通信概述。
自托管模式
Sentry 服务 Docker 容器不会作为 dapr init 的一部分自动启动。但可以按照设置双向 TLS的说明手动执行它。
如果你运行在 slim-init 模式下,它也可以作为进程手动运行。

Kubernetes 模式
Sentry 服务作为 dapr init -k 的一部分部署,或通过 Dapr Helm charts 部署。有关在 Kubernetes 上运行 Dapr 的更多信息,请访问 Kubernetes 托管页面。

延伸阅读
6 - Dapr Sidecar Injector 控制平面服务概述
在 Kubernetes 模式 下运行 Dapr 时,会创建一个运行 Dapr Sidecar Injector 服务的 Pod,该服务会查找使用 Dapr 注解 初始化的 Pod,然后在该 Pod 中为 daprd 服务 创建另一个容器。
运行 sidecar 注入器
sidecar 注入器服务作为 dapr init -k 的一部分部署,或通过 Dapr Helm 图表部署。有关在 Kubernetes 上运行 Dapr 的更多信息,请访问 Kubernetes 托管页面。