Dapr 实际是被定义为Distributed Application Runtime（分布式的程序运行时），为开发人员提供一个分布式的程序的开发环境，提供分布式的程序所依赖的功能模块库，提供了分布式程序的运行环境，或者说为分布式的程序提供了一套完整运行方案。
Dapr是一个自上而下的框架，也就是说从从顶层开发者运行接口（远程服务方法调用 pubsub ），到传输协议（http grpc），到消息组件， 到基础设施环境（k8s 本地主机 docker）。这种设计的好处是将开发者作为第一位，先满足需求而不是创造需求。从解决问题出发到最终实现。本人比较喜欢这种自上而下的理念，在现实中这种理念也相较成功率更高。
Dapr是站在开发者角度设计的，给开发者提供了服务调用，消息队列，事件驱动的服务模型，并提供需要的状态存储，加密数据存储的基础服务，使得开发者不用去关心底层基础设施细节。
Dapr同时支持standalone和基于Kubernetes的模式，想要了解可以从standalone模式开始，standalone相对概念较少，排除Kubernetes复杂概念的干扰。
Dapr实现远程方法直接调用，实现了事件总线异步处理功能，将两者集中到一个平台，这就满足了绝大部分分布式程序的核心需求。
Dapr从使用角度出发，优先实现了程序员所关心的最核心的功能，并没追究serverless概念的完整实现，如没有提供从零扩容等类似非核心功能和概念，当然Dapr也是在一个快速开发与扩展阶段，一些新的概念和功能会不断引入，但是肯定是以最核心功能为基点来拓展。
Dapr提供了完备的可观察性，提供了完备的tracing metrics logs, 方便追踪问题，支持opentelemetry（opencensus）， 所有支持opentelemetry的tracing工具都可以被接入，opentelemetry目前还在发展阶段。
Dapr 采用mutual authentication TLS加密安全方式，提供了生产级别的安全性。
Dapr是基于sidecar模式模式， 实际等于给程序提供一个直接的代理，类似于每个web app 前面绑定一个nigix。
Dapr K8S模式利用AdmissionReview AdmissionRequest通过PatchOperation注入Dapr的sidecar。
Dapr没用采用标准的net/http库，而是采用fasthttp一个高性能http库，在性能上有显著提升。
web session之间是无状态的，State store components提供了状态的存储，类似于web开发中将web session存储于服务器端的功能。
Dapr不是service mesh，service mesh是关注于网络服务，Dapr则是为用户构建microservices提供基础架构支持，使用户更方便的构建microservices，是以开发者为中心而不是网络为中心。
Service invocation 实现远程服务方法的调用，实现类似faas功能，实际提供了服务发现，反向代理的功能。
DaprService invocation 实现了反向代理、负载均衡。
