Dapr教程

Dapr(Distributed Application Runtime),即分布式应用运行时系统。Dapr 是微软Azure内部创新孵化团队的一个开源项目,皆在解决微服务应用开发过程的一些共性问题。以官方文档的说法,Dapr 是一个可移植、事件驱动的运行时,让企业开发者更容易利用各种语言和框架构建柔性、无状态和有状态的微服务应用,并运行在云端和边缘。

Dapr 的核心由 Go 语言写成,开发团队一开始有计划使用 .NET Core/C# 来写,但是考虑到社区的接受程度,遂最终选定 Go 作为开发语言。当然,还是可以使用任何语言和框架来编写 Dapr 的扩展功能。由于 Dapr 要解决的问题确实是大家面临的一些痛点,并且 Dapr 的设计也独树一帜,所以一经开源,就成为 GitHub 上 Star 增长最快的开源项目之一。

Dapr的口号

简化云原生应用开发,聚焦在应用的核心逻辑,让代码简单、可移植。

Dapr的目标

  1. 最佳实践的构建块
  2. 任何语言或框架
  3. 一致性,可移植,开放的API
  4. 采纳标准
  5. 可扩展和可插拔的组件
  6. 与平台无关(本地,云计算,边缘计算等)
  7. 社区驱动,供应商(厂商)中立 dapr_goals.png

Dapr的设计思路

这里首先要先理解几个问题,然后再看Dapr如何解决这些问题的

以下资料都有英文原图,中文翻译为个人理解,英文好的小伙伴可以直接看原图。

微服务为什么很难

  1. 开发者要构建自己的运行时处理分布式应用问题
  2. 运行时支持的开发语言有限,且有严格控制的特性(功能)集合
  3. 运行时的可移植性有限,一般只支持特定的基础架构平台

what_is_holding_back_microservice_development.png

分布式应用的需求

内容引自 Multi-Runtime Microservices Architecture https://www.infoq.com/articles/multi-runtime-microservice-architecture/

注意:二级内容不与图片对应,把功能组合成场景

  • 生命周期
    • 更快的发布周期
    • 自动化部署
    • 从错误中恢复
    • 自动化伸缩
  • 网络
    • 服务发现
    • 跟踪与遥测(可观测性)
    • 信息交换:点对点、发布/订阅,智能路由
  • 状态
    • 服务编排、工作流
    • 分布式单例(Actor)
    • 临时调度(Cron)
    • 幂等性
    • 有状态错误恢复
    • 缓存
  • 绑定
    • 转换协议
    • 支持不同的消息交换模式:轮询、事件驱动、请求/应答等
    • 转换消息格式
    • 执行自定义错误恢复过程
    • 安全机制

distributed_app.png

传统中间件和云原生对比

传统中间件以各种SDK的方式提供能力,而云原生平台则通过各种外围的Runtime,目前来看比较有趣的是,大家不约而同的选择了Sidecar。

future_architecture_trends.png

多运行时微服务边界

  • K8s和容器在多语言应用程序的生命周期管理方面取得了巨大的飞跃,并为未来的创新奠定了基础
  • Service Mesh在K8s上得到了改进,具有先进的网络功能,并开始深入应用程序
  • Knative通过快速伸缩来关注无服务器的工作负载,解决了服务编排和事件驱动的绑定需求
  • Dapr以K8s、Knative和Service Mesh的思想为基础,深入研究应用程序运行时,处理有状态的工作负载、绑定和集成需求,充当现代分布式中间件

    主要分为3个部分,K8s、Mecha运行时(网关、Dapr + Knative)、业务逻辑。

    Dapr的出现可以让开发者更专注于业务逻辑,而业务逻辑则作为服务运行时。

multi-runtime_microservices_boundary.png

多运行时的好处

业务逻辑和不断增加的分布式系统关注点之间的松耦合。

业务逻辑经常变化,取决于业务优先级。

而分布式原语则由软件供应商提供,作为库、容器、服务来使用。这些代码会根据供应商优先级、发布周期、安全补丁、开源治理规则等而变化。

他们互相看不到对方,也无法控制对方。

architecture_benefits.png

Dapr的优势:Any language, anywhere

与语言无关,与平台无关

分布式应用运行时

官方解释

帮助开发人员构建事件驱动的、弹性的分布式应用程序。 无论是在本地、云中还是在边缘设备上,都可以帮助你解决构建微服务所带来的挑战,并保持代码与平台无关。

可以看到Dapr更具象化了

  1. 与应用程序通过HTTP和gRPC通信
  2. 内部有一些构建块
  3. 运行在云上

dapr.png

Dapr与服务网格

  • 开发者更聚焦在代码层面,通过SDK(图中没有标注)与dapr的构建块通信,面向localhost编程
  • 运维更关注安全性、可观测性、健壮性等问题上。而流量管控的部分,dapr(可能是暂时的)没有。

dapr_and_servicemesh.png

Sidecar的世界

  1. 应用于Sidecar通信是通过Dapr API(已经被封装成不同开发语言的SDK),这个过程中通过OpenTelemetry支持了可观测性(即跟踪、日志、指标)
  2. 应用之间通过Sidecar通信,支持mTLS,这个指服务调用(即Service Invocation)
  3. Sidecar 之间通过gRPC(图片中没有显示),Bindings,Pub/Sub都可以通信
  4. 可观测性无处不在,通过Prometheus、Zipkin、Fluentd等,可视化OpenTelemetry中的部分数据

但目前据我所知没有一个可以统一接管完整OpenTelemetry的,如果有的话欢迎纠错。

  1. 状态管理也是由Sidecar代理的

sidecar_components.png

对于.Net的意义

  • .Net SDK是微软亲儿子,让.Net和Java一起在新起点站在了同一起跑线
  • 分布式应用运行时给.Net的新架构带来了新的思路和机遇
  • 加速.Net技术栈的更新迭代
  • 共享开源生态

Dapr 基本概念:SidecarDapr API 提供 Http 和 gRPC两种通讯方式。运行方式则可以是容器也可以是进程,Windows开发推荐使用Self Hosted)。这样的好处是与运行环境无关,且独立运行不需要应用包含Dapr ...