ساخت microservice یعنی بارها نوشتن همین چیزها:

service discovery + retries + circuit breaker
pub/sub به Kafka یا RabbitMQ
state در Redis یا Postgres
secrets از vault
tracing و mTLS
و حالا: LLM calls + agent workflows

هر تیم SDK و boilerplate خودش را می‌نویسد — و تعویض broker یا cloud = تغییر کد.

Dapr همان runtime است:

APIs for Building Secure and Reliable Microservices and Agentic AI Systems

یعنی HTTP/gRPC APIs استاندارد کنار اپ (sidecar) — منطق business در کد شما می‌ماند؛ زیرساخت pluggable می‌شود.

CNCF Graduated — ۳۰ اکتبر ۲۰۲۴ (ورود Incubating نوامبر ۲۰۲۱، بدون Sandbox). Adopt شده در Microsoft، Alibaba، IBM، Grafana، HDFC Bank، NASA و ده‌ها سازمان دیگر.

مشکل boilerplate در سیستم‌های توزیع‌شده

بدون Dapr:
  App ──SDK──► Kafka
  App ──SDK──► Redis
  App ──SDK──► Vault
  App ──manual──► retries / tracing / mTLS

با Dapr:
  App ──HTTP/gRPC──► daprd sidecar
                      ├── pub/sub component (Kafka|RabbitMQ|…)
                      ├── state component (Redis|Postgres|…)
                      └── resiliency + mTLS + OTEL

Dapr جایگزین کامل Istio/Cilium نیست — مکمل است: mesh شبکه را مدیریت می‌کند؛ Dapr الگوهای application را.

Dapr چیست؟

Dapr (Distributed Application Runtime) یک runtime قابل‌حمل است که:

• بهترین practices میکروسرویس را به building block APIs تبدیل می‌کند
• به‌صورت sidecar (daprd) کنار اپ اجرا می‌شود — بدون embed کردن runtime در کد
• روی Kubernetes، self-hosted، VM و edge کار می‌کند
• با components زیرساخت را عوض می‌کند بدون تغییر application code
• resiliency، security، observability را cross-cutting می‌آورد
• برای workflowهای durable و AI agents موتور اجرای پایدار دارد

Docs: docs.dapr.io

Repo: github.com/dapr/dapr

License: Apache 2.0

Enterprise support: Diagrid (اعلام‌شده روی dapr.io)

تاریخچه و CNCF

شعار عملیاتی سایت: افزایش بهره‌وری developer با حذف boilerplate — security و reliability «on by default».

معماری: Sidecar

┌─────────────────────────────┐
│  Pod / Host                 │
│  ┌─────────┐  ┌──────────┐  │
│  │   App   │──│  daprd   │──┼──► Redis / Kafka / Vault / LLM
│  │ :8080   │  │ :3500    │  │
│  └─────────┘  └──────────┘  │
└─────────────────────────────┘
         HTTP or gRPC

• اپ runtime Dapr را import نمی‌کند — فقط به localhost API صدا می‌زند
• Separation of concerns: upgrade sidecar بدون rebuild اپ
• Polyglot: Go، Java، .NET، Python، JS، PHP — یا حتی بدون SDK با raw HTTP

Kubernetes injection

با annotation، dapr-sidecar-injector کانتینر daprd را به Pod تزریق می‌کند:

annotations:
  dapr.io/enabled: "true"
  dapr.io/app-id: "order-service"
  dapr.io/app-port: "8080"
  dapr.io/enable-api-logging: "true"

از Kubernetes ۱.۲۸+ می‌توان native sidecars (init container با restartPolicy: Always) استفاده کرد.

Control plane روی K8s

Building Blocks

هر API مستقل است — هر تعداد که لازم دارید استفاده کنید.

۱. Service invocation

فراخوانی سرویس به سرویس با discovery، retries، tracing:

# HTTP از داخل اپ به sidecar
curl http://localhost:3500/v1.0/invoke/checkout/method/submit \
  -X POST -H "Content-Type: application/json" \
  -d '{"id":"42"}'

Dapr مثل reverse proxy + service discovery عمل می‌کند — app-id مقصد را می‌شناسد.

۲. Publish / Subscribe

# publish
curl -X POST http://localhost:3500/v1.0/publish/pubsub/orders \
  -H "Content-Type: application/json" \
  -d '{"orderId":"42"}'

Subscriber یک endpoint اعلام می‌کند؛ Dapr پیام را delivery می‌کند.

• at-least-once delivery
• TTL، consumer groups، و ویژگی‌های پیشرفته per component
• تعویض Kafka ↔ RabbitMQ ↔ Azure Service Bus با تعویض YAML — بدون تغییر کد

۳. State management

Key/value pluggable: Redis، PostgreSQL، DynamoDB، Cosmos DB، …

curl -X POST http://localhost:3500/v1.0/state/statestore \
  -H "Content-Type: application/json" \
  -d '[{"key":"cart-1","value":{"items":3}}]'

curl http://localhost:3500/v1.0/state/statestore/cart-1

برای سرویس‌های stateful در کنار سرویس‌های stateless.

۴. Bindings

اتصال دوطرفه به سیستم خارجی (queues، blobs، databases، Twilio، …):

• Input binding — event خارجی اپ را trigger می‌کند
• Output binding — اپ از API Dapr سیستم خارجی را صدا می‌زند

۵. Actors (Virtual Actors)

واحد compute+state با اجرای single-threaded:

• activation / deactivation خودکار (GC وقتی idle)
• timers و reminders
• مناسب IoT devices، sessionها، game entities، per-user state

۶. Workflow (Durable execution)

فرآیندهای طولانی، stateful، durable:

• patterns: task chaining، fan-out/fan-in، monitor، timers، external interaction
• ترکیب با سایر APIs (pub/sub، invoke، state)
• state workflow در هر database پشتیبانی‌شده
• در نسخه‌های جدید: verifiable / cryptographically signed execution history

اهمیت برای AI agents: agent وسط tool-call کرش کند → از همان نقطه resume.

۷. Jobs

زمان‌بندی کار در آینده — زمان مشخص یا interval — orchestrator داخلی Dapr.

۸. Secrets

خواندن secret از Kubernetes secrets، cloud vaults، local stores — بدون hardcode در کد.

۹. Configuration

خواندن و subscribe به تغییرات config از stores پشتیبانی‌شده.

۱۰. Distributed lock

قفل روی resource برای consistency بین instanceهای اپ — با lease timeout.

۱۱. Cryptography

encrypt/decrypt بدون expose کردن key به application — عملیات در key vault یا sidecar.

۱۲. Conversation (LLM)

API برای تعامل امن و مقیاس‌پذیر با LLMها:

• prompt caching
• PII obfuscation قبل از ارسال به مدل
• pluggable conversation components برای مدل‌های مختلف

Dapr Agents

فریمورک Python برای agentهای intelligent و durable روی LLM — tool calling، memory، MCP، orchestration — با اتکا به Dapr برای durability و observability.

Components: جداسازی API از infra

مثال pub/sub Redis:

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: pubsub
spec:
  type: pubsub.redis
  version: v1
  metadata:
  - name: redisHost
    value: redis-master:6379
  - name: redisPassword
    secretKeyRef:
      name: redis
      key: password
scopes:
- order-service
- checkout

تعویض به Kafka = تغییر type و metadata — اپ همان /v1.0/publish/... را صدا می‌زند.

scopes دسترسی component را به app-idهای مشخص محدود می‌کند — بخشی از security مدل Dapr.

Cross-cutting: Security، Resiliency، Observability

Security

• mTLS بین sidecars به‌صورت پیش‌فرض (Sentry CA)
• identity با SPIFFE
• API access policies و pub/sub topic scoping
• امکان آوردن certificate خودتان

Resiliency

Spec جدا برای timeouts، retries/back-offs، circuit breakers — اعمال روی فراخوانی‌های Dapr API و components:

apiVersion: dapr.io/v1alpha1
kind: Resiliency
metadata:
  name: myresiliency
spec:
  policies:
    timeouts:
      general: 5s
    retries:
      retryBackoff:
        policy: constant
        duration: 5s
        maxRetries: 3
    circuitBreakers:
      simpleCB:
        maxRequests: 1
        timeout: 5s
        trip: consecutiveFailures > 5

Observability

• tracing با W3C Trace Context و OpenTelemetry / Zipkin
• metrics و logs برای sidecar و control plane
• یکپارچه با stackهای رایج monitoring

نصب و شروع سریع

CLI + self-hosted (local)

# نصب CLI (macOS مثال)
brew install dapr/tap/dapr-cli

dapr init
dapr --version

# اجرای اپ با sidecar
dapr run --app-id myapp --app-port 8080 --dapr-http-port 3500 -- \
  python app.py

dapr init محیط local (معمولاً Redis و placement containers) را آماده می‌کند.

Kubernetes

helm repo add dapr https://dapr.github.io/helm-charts/
helm repo update
helm upgrade --install dapr dapr/dapr \
  --namespace dapr-system \
  --create-namespace \
  --wait

kubectl get pods -n dapr-system

سپس Deployment با annotations Dapr + Component YAMLها.

SDKها

می‌توانید بدون SDK فقط HTTP/gRPC صدا بزنید.

مثال end-to-end ذهنی

1. order-service  →  publish "orders" (Dapr pub/sub)
2. checkout       →  subscribe + invoke inventory
3. inventory      →  save state (Redis via state API)
4. workflow       →  saga: reserve → pay → ship
5. on failure     →  resiliency retry + workflow resume
6. secrets        →  payment API key از secret store
7. traces         →  OTEL به Jaeger/Grafana

تعویض Redis state به PostgreSQL = یک Component YAML — صفر تغییر در order-service.

پذیرش تدریجی (Incremental adopt)

طبق dapr.io:

• اپ Dapr می‌تواند endpointهای غیر-Dapr را صدا بزند
• همچنان resiliency، observability، scoping می‌گیرد
• لازم نیست همه سیستم یک‌شبه migrate شود

الگوی رایج: ابتدا service invocation + pub/sub؛ بعد state؛ بعد workflow/agents.

Dapr در برابر گزینه‌های مشابه

Dapr با CloudEvents در اکوسیستم event-driven هم‌خوان است؛ بسیاری از مسیرهای pub/sub با envelopes استاندارد کار می‌کنند.

با Argo CD Components و Resiliency را GitOps کنید؛ با cert-manager TLS برای Ingress داشبورد/APIهای کمکی.

Operations و best practices

1. app-id یکتا و پایدار — پایه identity و scoping
2. scopes روی Components — اصل least privilege
3. Resiliency spec برای همه وابستگی‌های خارجی
4. HA control plane در production (global.ha.enabled)
5. Resource limits روی daprd sidecar
6. API logging در staging؛ محدود در production پر ترافیک
7. Separate components per env (dev Redis ≠ prod Kafka)
8. Monitor sidecar reinject، sentry certs، placement health
9. نسخه CLI و runtime را هم‌تراز کنید
10. برای agents: workflow durable را از «chat script» جدا طراحی کنید

Troubleshooting

dapr status -k                    # control plane
kubectl logs -l app=dapr-sidecar-injector -n dapr-system
kubectl describe pod <app-pod>    # injected container?

# metadata sidecar
curl http://localhost:3500/v1.0/metadata

ارتباط با stack شما

Apps (any language)
  └── daprd sidecar
        ├── Components → Redis / Kafka / Postgres / Vault / LLM
        ├── mTLS (Sentry)
        └── OTEL traces

Kubernetes
  ├── [etcd](/blog/etcd-distributed-key-value-store-guide/) — cluster state
  ├── [CoreDNS](/blog/coredns-kubernetes-dns-guide/) — name resolution
  ├── CNI ([Cilium](/blog/cilium-ebpf-kubernetes-networking/)) — network + optional mesh
  ├── CRI ([containerd](/blog/containerd-container-runtime-guide/))
  └── GitOps ([Argo](/blog/argo-project-kubernetes-gitops-cicd/)) — Dapr + Components

Events
  └── [CloudEvents](/blog/cloudevents-event-driven-architecture-guide/) patterns alongside Dapr pub/sub

Dapr لایه application runtime است — نه storage (Longhorn، CubeFS) و نه control plane infra (Crossplane).

چه زمانی Dapr؟

✅ استفاده کنید

• microservices polyglot با نیاز pub/sub + state + invoke
• تیم‌هایی که می‌خواهند infra را بدون rewrite عوض کنند
• workflowهای طولانی و durable (سفارش، onboarding، AI agent)
• امنیت و resiliency یکسان بدون boilerplate
• edge + cloud با یک مدل برنامه‌نویسی

⚠️ شاید نه

• مونولیت ساده بدون توزیع
• فقط نیاز traffic management → service mesh کافی است
• latency بسیار سخت روی مسیر hot بدون benchmark sidecar
• تیم بدون آمادگی ops برای control plane اضافه

جمع‌بندی

Dapr به developer اجازه می‌دهد روی business logic تمرکز کند و الگوهای توزیع‌شده — از messaging تا durable AI agents — را با API ثابت و infra قابل تعویض پیاده کند.

قدم بعدی

1. dapr init و یک quickstart رسمی
2. service invocation بین دو app-id
3. Component pub/sub (Redis) سپس تعویض ذهنی به Kafka
4. Helm نصب روی cluster dev + annotation روی Deployment
5. یک workflow کوتاه یا Conversation API با LLM آزمایشی
6. Resiliency + tracing را قبل از production روشن کنید

منابع یادگیری: Dapr University (رایگان، self-paced) و State of Dapr Report 2026.

منابع

• Dapr — dapr.io
• Overview — docs.dapr.io
• Sidecar (daprd)
• CNCF Dapr
• GitHub — dapr/dapr
• Building microservices with Dapr (CNCF Blog)

منتشر شده در P30Light — بخش زیرساخت و سرور.