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的设计思路

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

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

微服务为什么很难

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

分布式应用的需求

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

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

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

传统中间件和云原生对比

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

多运行时微服务边界

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

  主要分为3个部分，K8s、Mecha运行时（网关、Dapr + Knative）、业务逻辑。

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

多运行时的好处

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

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

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

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

Dapr的优势：Any language, anywhere

与语言无关，与平台无关

分布式应用运行时

官方解释

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

可以看到Dapr更具象化了

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

Dapr与服务网格

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

Sidecar的世界

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

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

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

对于.Net的意义

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