1 - Dapr 边车(daprd)概述

Dapr 边车进程概述

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 注解的关联方式。

示例

  1. 通过指定唯一 ID 在应用旁边启动边车。

    注意: --app-id 是必填字段,且不能包含点。

    daprd --app-id myapp
    
  2. 指定应用正在监听的端口

    daprd --app-id myapp --app-port 5000
    
  3. 如果您使用多个自定义资源并希望指定资源定义文件的位置,请使用 --resources-path 参数:

    daprd --app-id myapp --resources-path <PATH-TO-RESOURCES-FILES>
    
  4. 如果您将组件和其他资源(例如,弹性策略、订阅或配置)组织到单独的文件夹或共享文件夹中,可以指定多个资源路径:

    daprd --app-id myapp --resources-path <PATH-1-TO-RESOURCES-FILES> --resources-path <PATH-2-TO-RESOURCES-FILES>
    
  5. 运行应用时启用 Prometheus 指标收集

    daprd --app-id myapp --enable-metrics
    
  6. 仅监听 IPv4 和 IPv6 回环地址

    daprd --app-id myapp --dapr-listen-addresses '127.0.0.1,[::1]'
    

2 - Dapr Operator 控制平面服务概述

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 服务概述

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。

用例

placement 表 API 可用于检索当前的 placement 表,其中包含在所有命名空间中注册的所有 actors。这对于调试和允许工具提取并呈现有关 actors 的信息很有帮助。

HTTP 请求

GET http://localhost:<healthzPort>/placement/state

HTTP 响应代码

代码描述
200返回 Placement 表信息
500Placement 无法返回 Placement 表信息

HTTP 响应体

Placement 表 API 响应对象

名称类型描述
tableVersionintPlacement 表版本
hostListActor 主机信息[]已注册 actor 主机信息的 json 数组。

Actor 主机信息

名称类型描述
namestringactor 的 host:port 地址。
appIdstringapp id。
actorTypesjson string array它托管的 actor 类型列表。
updatedAttimestampactor 注册/更新的时间戳。

示例

 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 托管页面

相关链接

了解有关 Placement API 的更多信息。

4 - Dapr Scheduler 控制平面服务概述

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 数据库中。

显示 Scheduler 控制平面服务和 Jobs API 的架构图

默认情况下,Etcd 内嵌于 Scheduler 服务中,这意味着 Scheduler 服务会运行其自己的 Etcd 实例。 有关如何配置 Scheduler 服务的更多信息,请参阅 Scheduler 服务标志

作业位置性

默认作业行为

当 Scheduler 服务触发作业时,它们会被发送回调度该作业的同一应用 ID 的单个副本,以随机负载均衡的方式进行。 这会在应用程序的副本之间提供基本的负载均衡,适用于大多数不需要严格位置性的用例。

使用 Actor Reminders 实现完全位置性

对于需要完全作业位置性(让作业在创建它们的同一主机上触发)的用户,actor reminders 提供了一种解决方案。 要为作业强制执行完全位置性:

  1. 创建一个 actor 类型,其中包含一个特定副本独有的随机 UUID
  2. 使用此 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 文档中找到有关这些标志作用的更深入理解。

--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 服务概述

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 控制平面服务概述

Dapr sidecar 注入器流程概述

Kubernetes 模式 下运行 Dapr 时,会创建一个运行 Dapr Sidecar Injector 服务的 Pod,该服务会查找使用 Dapr 注解 初始化的 Pod,然后在该 Pod 中为 daprd 服务 创建另一个容器。

运行 sidecar 注入器

sidecar 注入器服务作为 dapr init -k 的一部分部署,或通过 Dapr Helm 图表部署。有关在 Kubernetes 上运行 Dapr 的更多信息,请访问 Kubernetes 托管页面