企业官网建设流程全解析

Dapr 1.10 版本全解析：Workflow 预览、批量发布订阅、可插拔组件与稳定性里程碑

【免费下载链接】daprDapr is a portable runtime for building distributed applications across cloud and edge, combining event-driven architecture with workflow orchestration.项目地址: https://gitcode.com/GitHub_Trending/da/dapr

Dapr 1.10 是 Dapr 运行时在可观测性、开发体验与组件生态上的一个重要版本，首次引入 Dapr Workflows（alpha API）、批量发布订阅（bulk pub/sub）、可插拔组件 SDK 与 Multi-App Run 等全新能力，同时将 resiliency 策略正式转正为稳定特性。本文以官方发布说明 v1.10.0.md 为主体，结合当前仓库源码与配置示例，逐项拆解新特性背后的实现细节、组件变动、CLI 变更，以及从自托管到 Kubernetes 的完整升级路径，帮助你在实际项目中安全地规划与落地 Dapr 1.10。

一、版本亮点总览

Dapr 1.10 的核心亮点可以归纳为四大方向：

• 新能力（预览）：Dapr Workflows（alpha API）、Bulk publish/subscribe、可插拔组件 SDK、Multi-App Run 本地多应用编排。
• 稳定性里程碑：resiliency 策略自 v1.7.0 引入后，在本版本正式转正为 stable。
• 组件生态扩充：内置组件总数达到 111 个，新增 8 个组件，另有 7 个组件被认证为 stable、2 个组件进入弃用名单。
• 可观测性增强：支持对指标使用正则表达式处理高基数（high-cardinality）问题，并新增了服务调用（service invocation）维度的一整套指标。

下面分别深入展开。

二、Dapr Workflows（预览）：跨应用的长时运行编排

2.1 定位与价值

Dapr Workflows 在 1.10 中以新的 alpha API 形式随运行时提供，用于构建跨多个应用的长时运行（long-running）、持久化（persistent）流程或数据流。与其它 Dapr 构建块（building blocks）可以自由组合：一个工作流既可以调用另一个服务（service invocation），也可以触发绑定（binding）或获取密钥（secret），从而实现复杂的应用场景编排。

从当前仓库的源码结构可以看到，工作流引擎在运行时中是一个独立的子系统。入口位于 pkg/runtime/wfengine/wfengine.go，其设计包含：

• Interface：定义引擎对外暴露的注册（Registrar）、运行（Run）、gRPC 服务注册、TaskHub 客户端、运行时元数据等能力；
• Options：注入 AppID、命名空间、Actors、Workflow 配置（config.WorkflowSpec）、resiliency Provider、组件存储等运行时依赖；
• 后端实现分别位于pkg/runtime/wfengine/backends/actors与pkg/runtime/wfengine/inprocess，其中 actors 后端把工作流编排器/活动实现为 actor 目标（见 pkg/actors/targets/workflow/activity/factory.go 中通过ActivityActorType注册的 actor 类型），借助 actor 的持久化与生命周期管理来承载长时间运行的工作流状态。

值得注意的实现细节是ReservedWorkflowNamePrefix = "dapr.internal."：daprd 用它管理托管（in-process）工作流名称，Universal API 会拒绝用户以该前缀命名，而 gRPC 执行器则会把该前缀的请求路由到进程内执行器。这说明工作流命名空间是受控且内部隔离的。

2.2 API 形态

工作流 API 在 proto 定义中同时存在 Alpha1 与 Beta1 两组 RPC（见 dapr/proto/runtime/v1/dapr.proto），包括：

• StartWorkflow：启动一个新的工作流实例（可为实例指定 ID，为空时随机生成）；
• 查询实例详情（含workflow_name、创建/最后修改时间、状态枚举PENDING、RUNNING、SUSPENDED、COMPLETED、FAILED、TERMINATED等字段，见 dapr/proto/runtime/v1/workflow.proto）；
• TerminateWorkflow/PauseWorkflow/ResumeWorkflow：终止、暂停与恢复；
• RaiseEvent：向运行中的实例发送事件。

在 SDK 侧，官方文档说明中特别提到了 .NET SDK 对 Workflow 的全面支持（Workflow Management、Workflow Authoring 与 API 覆盖在 v1.10 中同步落地）。使用上通常需要：

1. 在工作流应用中引用对应 SDK 并编写编排器（orchestrator）与活动（activity）函数；
2. 通过StartWorkflowAPI 启动实例；
3. 通过实例 ID 查询、暂停、恢复或终止。

由于该能力在 1.10 中仍为 alpha 预览，生产环境使用前应关注后续版本对 API 的调整（仓库中已有workflow.proto的 Beta1 版本定义，说明演进方向明确）。

三、Bulk Publish / Bulk Subscribe（预览）：用更少的请求换更高吞吐

3.1 为什么需要批量消息

当应用需要发送或接收大量消息时，逐条请求会在 Dapr sidecar、应用与底层 pub/sub broker 之间产生大量往返。Bulk 操作把多条消息打包进单个请求，显著减少请求数量，从而提升整体吞吐。

3.2 运行时实现：优雅的降级设计

运行时对批量发布做了非常友好的兼容设计：在 pkg/runtime/pubsub/default_bulkpub.go 中，NewDefaultBulkPublisher(p)会把任意一个普通 PubSub 组件包装成BulkPublisher——即使底层组件本身没有实现批量接口，sidecar 也会用"并行逐条 Publish"的方式完成批量语义：

• 通过errgroup并行发送，最大并发限制为defaultBulkPublishMaxConcurrency = 100（见同文件第 25-27 行的常量定义）；
• 每个条目独立失败隔离，失败条目会被收集到BulkPublishResponseFailedEntry列表返回给调用方；
• 源码注释明确说明：不保证发送到 broker 的消息顺序与请求中的顺序一致，这是使用批量发布时需要注意的语义约束。

相应的批量订阅实现在 pkg/runtime/pubsub/default_bulksub.go，配合 pkg/runtime/pubsub/bulksubscribe_events.go 处理批量订阅的事件分发。

3.3 与 resiliency 的协同

仓库中还专门提供了批量发布的 resiliency 支持：pkg/runtime/pubsub/bulkpublish_resiliency.go 与其测试 pkg/runtime/pubsub/bulkpublish_resiliency_test.go。这意味着批量发布同样可以套用重试、超时、熔断等策略，而不必回到逐条发送的老路。

SDK 侧，v1.10 的 .NET SDK（Bulk Publish / Bulk Subscribe / Bulk State）、Java SDK（Bulk publish/subscribe 实现）与 Go SDK 均已跟进该能力。

四、可插拔组件 SDK（预览）：用任何语言编写私有组件

4.1 概念

Dapr 的内置组件（built-in components）编译在运行时内；而"可插拔组件"（pluggable components）是自托管的组件——可以是一个可执行文件（exe）或容器，用任意语言编写，通过 gRPC 协议"插入"Dapr。1.10 为 .NET、Java、Go 提供了预览版 SDK，让开发者用自己熟悉的语言快速创建组件。

4.2 从仓库看可插拔组件的落地形态

当前仓库中可插拔组件的使用方式是：在组件 YAML 中把type声明为形如state.redis-pluggable的类型，并在 scopes 中限定应用。例如 tests/config/dapr_redis_pluggable_state.yaml 展示了一个名为pluggable-statestore的可插拔状态存储组件，其type: state.redis-pluggable、version: v1，并通过secretKeyRef从密钥存储中解析redisHost。

在运行时侧，pkg/components/pluggable 目录承载了可插拔组件的接入实现，且 1.10 专门为 bindings 类可插拔组件增加了共享 gRPC 连接的支持（见发布说明 runtime 变更项），减少组件数量增多时的连接开销。

4.3 可插拔组件的典型使用流程

1. 使用 .NET / Java / Go 的组件 SDK 编写组件程序（实现对应组件接口）；
2. 将程序作为独立进程或容器运行（自托管）；
3. 在 Dapr 组件配置中声明type: <category>.<name>-pluggable并指定接入信息；
4. 应用像使用内置组件一样通过 Dapr API 调用它。

需要留意：由于该机制依赖 gRPC 通信与进程/容器生命周期管理，部署运维上比内置组件多一层"组件进程本身的高可用"考量。

五、Multi-App Run（预览）：一条命令拉起多个应用

5.1 解决的问题

在自托管模式下同时测试多个应用，过去需要逐个执行dapr run。Multi-App Run 允许通过一个模板文件+ 单条命令dapr run -f同时启动多个应用，体验上等价于"一次性执行多条 CLI run 命令"，显著改善本地多应用联调。

5.2 CLI 侧的配套能力

从发布说明的 Dapr CLI 变更清单可以看到，本版本围绕 Multi-App Run 补齐了大量工程细节：

• 新增"用于配置多个应用随dapr run启动"的模板能力（对应 CLI issue 1141）；
• 实现resources_dir在dapr run -f下的新优先级规则（1142）；
• 支持从一份 run 配置文件运行多个应用（1143）；
• dapr stop现在可以正确停止由dapr run -f拉起的应用（1165）；
• dapr list --output json增加相关 run 配置文件元数据（1153），并修复 JSON 输出不一致问题（1171）；
• dapr run会跟踪并显示运行命令的 PID（1191）。

这些配套改动让"模板定义 → 一键启动 → 统一停止 → 状态查看"形成了完整闭环，这也是 Multi-App Run 能显著改善本地开发体验的原因。

5.3 典型用法示意

dapr run -f ./dapr.yaml

其中模板文件描述每个应用的 app-id、端口、组件目录等启动参数，随后可用dapr list查看整体运行状态、用dapr stop统一收尾。

六、Resiliency 转正：从预览到稳定

6.1 稳定的含义

Resiliency 策略（超时、重试、熔断、背压等）自 v1.7.0 引入，历经多个版本打磨后，在 1.10 中正式标记为stable，意味着其 API 与行为已进入稳定承诺范围，可以放心用于生产。

6.2 1.10 中针对 resiliency 的修复与加固

稳定性不是简单的"盖个章"，发布说明中与之相关的修复相当密集，且大多能在源码侧得到印证：

• 修复maxRetries: 0解析问题（对应 runtime 变更"Resiliency not parsing maxRetries: 0"）；
• 修复启用 resiliency 时的竞态条件（race conditions）；
• 修复 resiliency 操作超时导致的 goroutine 泄漏；
• 修复 trace 与 resiliency 配合使用时的链路问题；
• 修复dapr_runtime_resiliency_loaded指标未上报的 bug；
• 行为调整：resiliency不再对 201-299 状态码重试——即只有真正失败的请求（如 5xx 或网络错误）才会触发重试逻辑，避免对"已成功"的请求做无意义重试。

配套的重试策略实现位于 pkg/resiliency/retry.go，策略解析与加载在 pkg/resiliency/resiliency.go；批量发布的 resiliency 协同（见上文）也是本版本为稳定化补齐的一环。

七、组件生态：111 个内置组件与生命周期状态变化

7.1 新增组件（8 个）

1. State store：SQLite 3 —— 轻量级嵌入式数据库，适合本地/边缘场景；
2. State store：Cloudflare Workers KV；
3. Binding：Cloudflare Queues；
4. Binding：KubeMQ；
5. PubSub：Azure Service Bus Queues；
6. PubSub：KubeMQ；
7. PubSub：Solace PubSub+（AMQP 协议）；
8. HTTP Middlewares：Router Alias。

7.2 晋升为 Stable 的组件（7 个）

7.3 弃用组件（2 个）

• Binding：Twitter—— 正式标记为 deprecated；
• PubSub：Hazelcast—— 自 1.9 起弃用，将在 1.11 中移除。

7.4 组件级破坏性变更

• Cron binding 变为仅输入（input-only）绑定：不能再用作输出绑定，只负责按 cron 表达式触发事件；
• Azure Event Grid binding：接收消息需要额外的配置项。

7.5 值得关注的组件功能增强（节选）

• RabbitMQ PubSub：支持 AMQPS（安全 AMQP，含 x509 认证）、原生消息 TTL、修复 content-type 处理；
• Kafka PubSub：恢复向订阅者传递 Kafka record headers；
• Redis 全系组件：新增对 Redis 7 的支持；Redis binding 支持 Delete/Get 操作；Redis Configuration Store 修复启动后新增 key 无法订阅的问题；
• 所有 PubSub 组件：consumer group 变为可选，运行时在未指定时自动注入组名；
• Postgres State Store：新增 First-Write 并发策略与 TTL 支持；
• MySQL State Store：修复事务处理问题，并完成对 MariaDB 的兼容验证；
• JetStream：支持 token 认证、domain/apiPrefix、更多元数据选项，以及基于Nats-Msg-Id的消息去重；
• HTTP binding：支持双向 SSL、token 认证、trace 头传播，并可将非 200 响应视为非错误；
• Azure Blob Storage / Azure Event Hubs：迁移到 Azure SDK "track 2"；
• MQTT 组件：重命名为 "MQTT3"（保留旧名作为别名），并改进了重连处理。

八、CLI 与运行时变更速查

8.1 新命令与标志

• --resources-path（新增，推荐）：用于指定 components、subscriptions、resiliency policies 等所有资源类型的加载路径，可多次传入。--components-path保留用于向后兼容（计划在未来版本移除），但已不推荐使用。

这一点在源码中可以得到直接印证：cmd/daprd/options/options.go 中--components-path被标记为fs.MarkDeprecated("components-path", "use --resources-path")，而--resources-path的定义说明为"Path for resources directory. If not specified, no resources will be loaded. Can be passed multiple times"。

• --no-health-check-api-logging：从 API 日志中省略健康检查的请求记录。
• --dapr-listen-addresses（dapr run）：补充了该缺失的 CLI 标志。
• --image-variant（mtls renew-certificate）：用于指定镜像变体。
• fish shell 补全：CLI 新增 fish 补全支持。
• dapr list --output json：输出包含 Dapr Compose 配置元数据与 PID 信息。

8.2 运行时重要变更

安全与加固：

• sidecar 容器默认启用runAsNonRoot与readOnlyRootFilesystem（Helm chart 侧）；
• 支持automountServiceAccountToken: false的 Pod——使用绑定令牌（bound tokens）承载 Dapr 身份；
• Helm chart 为每个控制平面服务分配独立的 service account。

API 与行为：

• 服务调用（service invocation）在 HTTP 头中新增调用方与接收方的 app-id；
• 支持在单个 YAML 文件中声明多条声明式订阅（declarative subscriptions）；
• gRPC 拉取订阅列表；metadata 端点响应中新增 PubSub 订阅列表；
• 支持通过 metadata 覆盖 CloudEvent 属性；
• 组件 metadata 值允许使用{appID}占位符；
• 自托管模式下禁止 app-id 包含点（dot）；
• 从 HTTP 响应中移除 "Server" 头；
• /healthz/outbound与/healthz一样受 API 访问规则约束（不再绕过）；
• Dapr 的关闭流程改为在宽限期（grace period）到期后触发；
• 修复 placement membership 心跳循环 panic；
• gRPC proxy 得到大量修复：优雅关闭期间可用、支持流式与 resiliency、修复 panic 与数据丢失等问题。

可观测性：

• 指标正则：允许对指标应用正则表达式，用于处理高基数指标导致的内存与出口流量（egress）成本问题——对应源码中"支持重写高基数路径标签，避免 Prometheus 过载"的变更；
• 新增服务调用指标（HTTP 与 gRPC 全覆盖），可配合 KEDA、Knative 等基于 Dapr 流量模式做扩缩容决策；
• API 日志新增obfuscateURLs选项：启用后 HTTP API 日志以路由名替代完整路径记录 URL，避免日志泄漏 PII（如路径中的用户标识）。该配置位于 Configuration CRD 的spec.logging.apiLogging下，仓库中 pkg/config/configuration.go 的APILoggingSpec定义了enabled、obfuscateURLs、omitHealthChecks三个字段，注释明确指出三者仅在 API 日志启用时生效。

配置 CRD：Dapr Config CRD 在.metrics之外同时支持.metric字段。

九、升级到 Dapr 1.10

升级前请确认：本版本包含破坏性变更与若干弃用项（详见下文），建议先在测试环境验证再升级生产。

9.1 自托管 / 本地机器

先卸载现有 Dapr（注意：这会删除默认$HOME/.dapr目录、二进制文件以及dapr_redis、dapr_placement、dapr_zipkin三个容器；Linux 下若 docker 需要 sudo，请加 sudo）：

dapr uninstall --all

安装最新的 dapr CLI 并初始化指定版本：

dapr init --runtime-version=1.10

等待初始化完成后，验证版本：

$ dapr --version CLI version: 1.10 Runtime version: 1.10

9.2 Kubernetes：从旧版本升级

支持使用 Helm 3 或 Dapr CLI 进行零停机升级。

方式一：CLI 升级

# 普通升级 dapr upgrade --runtime-version 1.10 -k # 高可用模式升级 dapr upgrade --runtime-version 1.10 --enable-ha=true -k

等待操作完成后，用dapr status -k检查状态。

方式二：Helm 升级

helm repo add dapr https://dapr.github.io/helm-charts/ helm repo update helm upgrade dapr dapr/dapr --version 1.10 --namespace=dapr-system --wait

注意：无论哪种方式，升级后都要重启业务 Deployment以加载新版本 sidecar。

9.3 Kubernetes：全新安装

Helm 方式：

helm repo add dapr https://dapr.github.io/helm-charts/ helm repo update kubectl create namespace dapr-system helm install dapr dapr/dapr --version 1.10 --namespace=dapr-system --wait

CLI 方式：

dapr init --runtime-version=1.10 -k

安装后验证：确认控制平面各 Pod 健康且版本为 1.10：

$ dapr status -k NAME NAMESPACE HEALTHY STATUS REPLICAS VERSION AGE CREATED dapr-dashboard dapr-system True Running 1 0.12.0 15s 2023-02-03 13:07.39 dapr-sidecar-injector dapr-system True Running 1 1.10 15s 2023-02-03 13:07.39 dapr-sentry dapr-system True Running 1 1.10 15s 2023-02-03 13:07.39 dapr-operator dapr-system True Running 1 1.10 15s 2023-02-03 13:07.39 dapr-placement dapr-system True Running 1 1.10 15s 2023-02-03 13:07.39

最后对已有 Deployment 执行滚动重启以加载新 sidecar：

kubectl rollout restart deploy/<deployment-name>

十、破坏性变更与弃用通知汇总

10.1 Breaking Changes

10.2 Deprecation Notices

• Java SDK：HTTP client 已弃用，gRPC client 将成为唯一实现；使用默认 client 的应用无需改动；
• gRPC 服务调用 API：已弃用，请改用 gRPC proxy API；
• Twitter Binding：已弃用；
• Hazelcast PubSub：自 1.9 起弃用，将在 1.11 移除；
• Dapr Dashboard：下一个版本将不再随 Dapr Helm chart 一起安装，改为独立 chart 发布。

十一、SDK 版本要求与变更摘要

结语：如何规划你的 1.10 升级

综合来看，Dapr 1.10 是一次"稳中求进"的版本：resiliency 转正、批量 pub/sub 与 Workflows 两条性能/编排新路径为高吞吐与长流程场景提供了官方解法，可插拔组件 SDK 打开了组件生态的自定义空间，而大量 CLI 与可观测性细节则切实改善了日常开发与排障体验。对于计划升级的团队，建议按以下顺序推进：

1. 阅读 v1.10.0.md 确认与自身使用场景相关的 Breaking Changes 与弃用项；
2. 在测试环境完成自托管与 Kubernetes 两套升级演练，重点验证 sidecar 滚动重启后的服务调用与 pub/sub 行为；
3. 将--components-path迁移到--resources-path，避免未来版本移除旧标志时受影响；
4. 结合新指标与obfuscateURLs日志配置，完善生产集群的可观测性与日志合规；
5. 对 Cron binding 输入化、Event Grid 配置变化等破坏性项提前改造存量组件配置。

【免费下载链接】daprDapr is a portable runtime for building distributed applications across cloud and edge, combining event-driven architecture with workflow orchestration.项目地址: https://gitcode.com/GitHub_Trending/da/dapr