Dapr
Dapr 全称 Distributed Application Runtime。它把分布式系统中的通用模式封装成独立的 Building Block API，应用通过 HTTP 或 gRPC 调用，不必直接绑定某个消息队列、State Store 或 Secret Store SDK。
所在层次
Dapr 是 Runtime 层能力，但其常见部署形态是独立 Sidecar Process：
- Self-hosted：应用进程旁运行一个
daprd进程。 - Kubernetes：通常为每个启用 Dapr 的 Pod 注入一个 Sidecar Container，并由 Control Plane 管理证书、Placement 等平台能力。
因此“Runtime 层”和“Process/Sidecar 层”描述的是两个维度：前者说明它提供什么抽象，后者说明它如何部署。
Building Blocks
| Building Block | 解决的问题 |
|---|---|
| Service Invocation | 通过 App ID 调用服务，并集成发现、Tracing 与 Resiliency |
| Pub/Sub | 用统一 API 发布和订阅事件，底层 Broker 由 Component 决定 |
| State Management | 用统一 Key/Value API 访问可插拔 State Store |
| Workflow | 编排可持久化、可恢复的长时间业务流程 |
| Bindings | 连接外部系统或由外部事件触发应用 |
| Actors | 提供 Virtual Actor 的身份、状态、并发与生命周期能力 |
| Secrets | 从 Secret Store 获取 Secret，而不是硬编码具体供应商 SDK |
| Configuration | 获取配置并监听变化 |
| Distributed Lock | 对共享资源提供互斥访问 API，保证边界取决于底层 Store |
Building Block 是 API 抽象，Component 是具体实现适配。例如应用调用相同的 Pub/Sub API，部署时可以选择 Kafka、RabbitMQ 或其他受支持 Broker；更换 Component 仍需验证投递语义、顺序、事务和运维差异，不能认为底层完全等价。
Dapr 与 JVM Agent
| 维度 | Dapr | SkyWalking Java Agent |
|---|---|---|
| 定位 | Distributed Application Runtime | Observability Instrumentation Agent |
| 调用方式 | 应用主动调用 HTTP/gRPC API 或 SDK | JVM 启动时挂载，自动插桩受支持调用 |
| 主要能力 | 调用、消息、状态、工作流、Binding、Secret | Trace、Metric、Profile、Topology |
| 部署 | 常见为 Sidecar Process/Container | 与应用运行在同一个 JVM Process |
| 是否替代业务代码 | 否 | 否 |
Dapr 可以产生或传播 Telemetry，SkyWalking 可以采集和分析 Telemetry；两者职责不同，可以组合使用。
Dapr 与 Service Mesh
Dapr 面向开发者提供分布式应用 API；Service Mesh 主要在网络路径上提供流量、安全和观测能力。二者都可能使用 Sidecar，但不能因为部署形态相同就认为功能等价。
| 问题 | Dapr | Service Mesh |
|---|---|---|
| 应用是否调用平台 API | 是 | 通常否，代理透明接管流量 |
| State、Pub/Sub、Workflow | 提供 | 通常不提供 |
| 通用 L7 流量治理 | 部分能力 | 核心能力 |
| 与语言关系 | HTTP/gRPC API，多语言 | 网络代理，语言无关 |
边界
- Dapr 不负责划分 Service Boundary。
- State API 不自动解决跨服务事务和业务一致性。
- Pub/Sub 的最终语义受 Dapr 配置、Component 和 Broker 共同影响。
- 自动 Retry 必须结合操作的 Idempotency 设计。
- 引入 Sidecar 会增加资源、端口、调用跳数和排障维度。