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/daprDapr 1.10 是 Dapr 运行时在可观测性、开发体验与组件生态上的一个重要版本首次引入 Dapr Workflowsalpha API、批量发布订阅bulk pub/sub、可插拔组件 SDK 与 Multi-App Run 等全新能力同时将 resiliency 策略正式转正为稳定特性。本文以官方发布说明 v1.10.0.md 为主体结合当前仓库源码与配置示例逐项拆解新特性背后的实现细节、组件变动、CLI 变更以及从自托管到 Kubernetes 的完整升级路径帮助你在实际项目中安全地规划与落地 Dapr 1.10。一、版本亮点总览Dapr 1.10 的核心亮点可以归纳为四大方向新能力预览Dapr Workflowsalpha 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.protoTerminateWorkflow/PauseWorkflow/ResumeWorkflow终止、暂停与恢复RaiseEvent向运行中的实例发送事件。在 SDK 侧官方文档说明中特别提到了 .NET SDK 对 Workflow 的全面支持Workflow Management、Workflow Authoring 与 API 覆盖在 v1.10 中同步落地。使用上通常需要在工作流应用中引用对应 SDK 并编写编排器orchestrator与活动activity函数通过StartWorkflowAPI 启动实例通过实例 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 SDKBulk Publish / Bulk Subscribe / Bulk State、Java SDKBulk 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 可插拔组件的典型使用流程使用 .NET / Java / Go 的组件 SDK 编写组件程序实现对应组件接口将程序作为独立进程或容器运行自托管在 Dapr 组件配置中声明type: category.name-pluggable并指定接入信息应用像使用内置组件一样通过 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 配置文件运行多个应用1143dapr stop现在可以正确停止由dapr run -f拉起的应用1165dapr list --output json增加相关 run 配置文件元数据1153并修复 JSON 输出不一致问题1171dapr run会跟踪并显示运行命令的 PID1191。这些配套改动让模板定义 → 一键启动 → 统一停止 → 状态查看形成了完整闭环这也是 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 个State storeSQLite 3 —— 轻量级嵌入式数据库适合本地/边缘场景State storeCloudflare Workers KVBindingCloudflare QueuesBindingKubeMQPubSubAzure Service Bus QueuesPubSubKubeMQPubSubSolace PubSubAMQP 协议HTTP MiddlewaresRouter Alias。7.2 晋升为 Stable 的组件7 个类别组件State storeAWS DynamoDBState storeMySQLState storeCockroachDBSecret storeHashicorp VaultBindingCronPubSubApache PulsarPubSubAWS SQS/SNS7.3 弃用组件2 个BindingTwitter—— 正式标记为 deprecatedPubSubHazelcast—— 自 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 headersRedis 全系组件新增对 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 2MQTT 组件重命名为 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-addressesdapr run补充了该缺失的 CLI 标志。--image-variantmtls renew-certificate用于指定镜像变体。fish shell 补全CLI 新增 fish 补全支持。dapr list --output json输出包含 Dapr Compose 配置元数据与 PID 信息。8.2 运行时重要变更安全与加固sidecar 容器默认启用runAsNonRoot与readOnlyRootFilesystemHelm chart 侧支持automountServiceAccountToken: false的 Pod——使用绑定令牌bound tokens承载 Dapr 身份Helm chart 为每个控制平面服务分配独立的 service account。API 与行为服务调用service invocation在 HTTP 头中新增调用方与接收方的 app-id支持在单个 YAML 文件中声明多条声明式订阅declarative subscriptionsgRPC 拉取订阅列表metadata 端点响应中新增 PubSub 订阅列表支持通过 metadata 覆盖 CloudEvent 属性组件 metadata 值允许使用{appID}占位符自托管模式下禁止 app-id 包含点dot从 HTTP 响应中移除 Server 头/healthz/outbound与/healthz一样受 API 访问规则约束不再绕过Dapr 的关闭流程改为在宽限期grace period到期后触发修复 placement membership 心跳循环 panicgRPC 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 日志启用时生效。配置 CRDDapr Config CRD 在.metrics之外同时支持.metric字段。九、升级到 Dapr 1.10升级前请确认本版本包含破坏性变更与若干弃用项详见下文建议先在测试环境验证再升级生产。9.1 自托管 / 本地机器先卸载现有 Dapr注意这会删除默认$HOME/.dapr目录、二进制文件以及dapr_redis、dapr_placement、dapr_zipkin三个容器Linux 下若 docker 需要 sudo请加 sudodapr uninstall --all安装最新的 dapr CLI 并初始化指定版本dapr init --runtime-version1.10等待初始化完成后验证版本$ dapr --version CLI version: 1.10 Runtime version: 1.109.2 Kubernetes从旧版本升级支持使用 Helm 3 或 Dapr CLI 进行零停机升级。方式一CLI 升级# 普通升级 dapr upgrade --runtime-version 1.10 -k # 高可用模式升级 dapr upgrade --runtime-version 1.10 --enable-hatrue -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 --namespacedapr-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 --namespacedapr-system --waitCLI 方式dapr init --runtime-version1.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 执行滚动重启以加载新 sidecarkubectl rollout restart deploy/deployment-name十、破坏性变更与弃用通知汇总10.1 Breaking Changes变更影响Cron binding 变为 input-only不能再作为输出绑定使用Azure Event Grid binding 需额外配置接收消息前必须按新文档补充配置10.2 Deprecation NoticesJava SDKHTTP client 已弃用gRPC client 将成为唯一实现使用默认 client 的应用无需改动gRPC 服务调用 API已弃用请改用 gRPC proxy APITwitter Binding已弃用Hazelcast PubSub自 1.9 起弃用将在 1.11 移除Dapr Dashboard下一个版本将不再随 Dapr Helm chart 一起安装改为独立 chart 发布。十一、SDK 版本要求与变更摘要SDK关键变更.NETBulk Publish / Bulk Subscribe / Bulk State、Workflow Management 与 Workflow Authoring、ISO 8601 间隔、原生消息非 CloudEvent发布Go要求 Go 1.18新增wait()方法阻塞至 sidecar 就绪修复 DROP 状态应答、actor 状态key 不存在 vs 意外错误的区分user-agent 上报 SDK 版本JavaBulk publish/subscribeHTTP client 弃用修复 Kotlin 下ActorType注解springboot 升级Python支持 Python 3.11、放宽 grpcio/protobuf 约束PubSub CloudEvent 扩展属性gRPCensure_asciiFalse默认序列化deadLetterTopic 支持结语如何规划你的 1.10 升级综合来看Dapr 1.10 是一次稳中求进的版本resiliency 转正、批量 pub/sub 与 Workflows 两条性能/编排新路径为高吞吐与长流程场景提供了官方解法可插拔组件 SDK 打开了组件生态的自定义空间而大量 CLI 与可观测性细节则切实改善了日常开发与排障体验。对于计划升级的团队建议按以下顺序推进阅读 v1.10.0.md 确认与自身使用场景相关的 Breaking Changes 与弃用项在测试环境完成自托管与 Kubernetes 两套升级演练重点验证 sidecar 滚动重启后的服务调用与 pub/sub 行为将--components-path迁移到--resources-path避免未来版本移除旧标志时受影响结合新指标与obfuscateURLs日志配置完善生产集群的可观测性与日志合规对 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Dapr 1.10 版本全解析：Workflow 预览、批量发布订阅、可插拔组件与稳定性里程碑
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/daprDapr 1.10 是 Dapr 运行时在可观测性、开发体验与组件生态上的一个重要版本首次引入 Dapr Workflowsalpha API、批量发布订阅bulk pub/sub、可插拔组件 SDK 与 Multi-App Run 等全新能力同时将 resiliency 策略正式转正为稳定特性。本文以官方发布说明 v1.10.0.md 为主体结合当前仓库源码与配置示例逐项拆解新特性背后的实现细节、组件变动、CLI 变更以及从自托管到 Kubernetes 的完整升级路径帮助你在实际项目中安全地规划与落地 Dapr 1.10。一、版本亮点总览Dapr 1.10 的核心亮点可以归纳为四大方向新能力预览Dapr Workflowsalpha 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.protoTerminateWorkflow/PauseWorkflow/ResumeWorkflow终止、暂停与恢复RaiseEvent向运行中的实例发送事件。在 SDK 侧官方文档说明中特别提到了 .NET SDK 对 Workflow 的全面支持Workflow Management、Workflow Authoring 与 API 覆盖在 v1.10 中同步落地。使用上通常需要在工作流应用中引用对应 SDK 并编写编排器orchestrator与活动activity函数通过StartWorkflowAPI 启动实例通过实例 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 SDKBulk Publish / Bulk Subscribe / Bulk State、Java SDKBulk 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 可插拔组件的典型使用流程使用 .NET / Java / Go 的组件 SDK 编写组件程序实现对应组件接口将程序作为独立进程或容器运行自托管在 Dapr 组件配置中声明type: category.name-pluggable并指定接入信息应用像使用内置组件一样通过 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 配置文件运行多个应用1143dapr stop现在可以正确停止由dapr run -f拉起的应用1165dapr list --output json增加相关 run 配置文件元数据1153并修复 JSON 输出不一致问题1171dapr run会跟踪并显示运行命令的 PID1191。这些配套改动让模板定义 → 一键启动 → 统一停止 → 状态查看形成了完整闭环这也是 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 个State storeSQLite 3 —— 轻量级嵌入式数据库适合本地/边缘场景State storeCloudflare Workers KVBindingCloudflare QueuesBindingKubeMQPubSubAzure Service Bus QueuesPubSubKubeMQPubSubSolace PubSubAMQP 协议HTTP MiddlewaresRouter Alias。7.2 晋升为 Stable 的组件7 个类别组件State storeAWS DynamoDBState storeMySQLState storeCockroachDBSecret storeHashicorp VaultBindingCronPubSubApache PulsarPubSubAWS SQS/SNS7.3 弃用组件2 个BindingTwitter—— 正式标记为 deprecatedPubSubHazelcast—— 自 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 headersRedis 全系组件新增对 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 2MQTT 组件重命名为 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-addressesdapr run补充了该缺失的 CLI 标志。--image-variantmtls renew-certificate用于指定镜像变体。fish shell 补全CLI 新增 fish 补全支持。dapr list --output json输出包含 Dapr Compose 配置元数据与 PID 信息。8.2 运行时重要变更安全与加固sidecar 容器默认启用runAsNonRoot与readOnlyRootFilesystemHelm chart 侧支持automountServiceAccountToken: false的 Pod——使用绑定令牌bound tokens承载 Dapr 身份Helm chart 为每个控制平面服务分配独立的 service account。API 与行为服务调用service invocation在 HTTP 头中新增调用方与接收方的 app-id支持在单个 YAML 文件中声明多条声明式订阅declarative subscriptionsgRPC 拉取订阅列表metadata 端点响应中新增 PubSub 订阅列表支持通过 metadata 覆盖 CloudEvent 属性组件 metadata 值允许使用{appID}占位符自托管模式下禁止 app-id 包含点dot从 HTTP 响应中移除 Server 头/healthz/outbound与/healthz一样受 API 访问规则约束不再绕过Dapr 的关闭流程改为在宽限期grace period到期后触发修复 placement membership 心跳循环 panicgRPC 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 日志启用时生效。配置 CRDDapr Config CRD 在.metrics之外同时支持.metric字段。九、升级到 Dapr 1.10升级前请确认本版本包含破坏性变更与若干弃用项详见下文建议先在测试环境验证再升级生产。9.1 自托管 / 本地机器先卸载现有 Dapr注意这会删除默认$HOME/.dapr目录、二进制文件以及dapr_redis、dapr_placement、dapr_zipkin三个容器Linux 下若 docker 需要 sudo请加 sudodapr uninstall --all安装最新的 dapr CLI 并初始化指定版本dapr init --runtime-version1.10等待初始化完成后验证版本$ dapr --version CLI version: 1.10 Runtime version: 1.109.2 Kubernetes从旧版本升级支持使用 Helm 3 或 Dapr CLI 进行零停机升级。方式一CLI 升级# 普通升级 dapr upgrade --runtime-version 1.10 -k # 高可用模式升级 dapr upgrade --runtime-version 1.10 --enable-hatrue -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 --namespacedapr-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 --namespacedapr-system --waitCLI 方式dapr init --runtime-version1.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 执行滚动重启以加载新 sidecarkubectl rollout restart deploy/deployment-name十、破坏性变更与弃用通知汇总10.1 Breaking Changes变更影响Cron binding 变为 input-only不能再作为输出绑定使用Azure Event Grid binding 需额外配置接收消息前必须按新文档补充配置10.2 Deprecation NoticesJava SDKHTTP client 已弃用gRPC client 将成为唯一实现使用默认 client 的应用无需改动gRPC 服务调用 API已弃用请改用 gRPC proxy APITwitter Binding已弃用Hazelcast PubSub自 1.9 起弃用将在 1.11 移除Dapr Dashboard下一个版本将不再随 Dapr Helm chart 一起安装改为独立 chart 发布。十一、SDK 版本要求与变更摘要SDK关键变更.NETBulk Publish / Bulk Subscribe / Bulk State、Workflow Management 与 Workflow Authoring、ISO 8601 间隔、原生消息非 CloudEvent发布Go要求 Go 1.18新增wait()方法阻塞至 sidecar 就绪修复 DROP 状态应答、actor 状态key 不存在 vs 意外错误的区分user-agent 上报 SDK 版本JavaBulk publish/subscribeHTTP client 弃用修复 Kotlin 下ActorType注解springboot 升级Python支持 Python 3.11、放宽 grpcio/protobuf 约束PubSub CloudEvent 扩展属性gRPCensure_asciiFalse默认序列化deadLetterTopic 支持结语如何规划你的 1.10 升级综合来看Dapr 1.10 是一次稳中求进的版本resiliency 转正、批量 pub/sub 与 Workflows 两条性能/编排新路径为高吞吐与长流程场景提供了官方解法可插拔组件 SDK 打开了组件生态的自定义空间而大量 CLI 与可观测性细节则切实改善了日常开发与排障体验。对于计划升级的团队建议按以下顺序推进阅读 v1.10.0.md 确认与自身使用场景相关的 Breaking Changes 与弃用项在测试环境完成自托管与 Kubernetes 两套升级演练重点验证 sidecar 滚动重启后的服务调用与 pub/sub 行为将--components-path迁移到--resources-path避免未来版本移除旧标志时受影响结合新指标与obfuscateURLs日志配置完善生产集群的可观测性与日志合规对 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考