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 实现了反向代理、负载均衡。
Dapr(Distributed Application Runtime)是微软于2019年10月16日 首次发布 的分布式程序运行时，到现在已经过去2年多，从最初的v0.1.0到现在的v1.0.0-rc2，加入了好多新的功能。支持的中间件越来越多，基本上主流的中间件(本地版和各云提供商的托管版)都可以被支持。Dapr运行时也从原来的只支持单Instance变成了v1.0.0-rc1以后的支持多Instance（HA mode）。让我们一起进入精彩的Dapr的世界。
参考 Dapr官方网站 ，"An event-driven, portable runtime for building microservices on cloud and edge"，或者复杂点说，"Dapr is a portable, event-driven runtime that makes it easy for any developer to build resilient, stateless and stateful applications that run on the cloud and edge and embraces the diversity of languages and developer frameworks"。翻译过来就是，"Dapr是一个在云和边缘构建微服务用的事件驱动的，可移植的运行时"。更复杂的来说，"Dapr是一个可移植的，事件驱动的运行时，使开发人员可以轻松创建在云和边缘上运行的有弹性，无状态和有状态的应用程序，支持语言和开发人员框架的多样性"。听起来让人一头雾水，让我解释一下它到底是什么意思。
Dapr提供如下的Building blocks:
欢迎分享，转载请注明来源：夏雨云
微信扫一扫
支付宝扫一扫
评论列表（0条）