Dapr全称

Distributed Application Runtime，分布式应用运行时

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、机甲运行时（网关、Dapr + Knative）、业务逻辑。

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

multi-runtime_microservices_boundary.png

多运行时的好处

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

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

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

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

architecture_benefits.png

Dapr的优势：Any language, anywhere

与语言无关，与平台无关

image

分布式应用运行时

官方解释

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

可以看到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的，如果有的话欢迎纠错。

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

sidecar_components.png

对于.Net的意义

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

我们正在行动，新的框架、新的生态

我们的目标是自由的、易用的、可塑性强的、功能丰富的、健壮的。

所以我们借鉴Building blocks的设计理念，正在做一个新的框架MASA Framework，它有哪些特点呢？

• 原生支持Dapr，且允许将Dapr替换成传统通信方式
• 架构不限，单体应用、SOA、微服务都支持
• 支持.Net原生框架，降低学习负担，除特定领域必须引入的概念，坚持不造新轮子
• 丰富的生态支持，除了框架以外还有组件库、权限中心、配置中心、故障排查中心、报警中心等一系列产品
• 核心代码库的单元测试覆盖率90%+
• 开源、免费、社区驱动
• 还有什么？我们在等你，一起来讨论

经过几个月的生产项目实践，已完成POC，目前正在把之前的积累重构到新的开源项目中

目前源码已开始同步到Github（文档站点在规划中，会慢慢完善起来）：

MASA.BuildingBlocks

MASA.Contrib

MASA.Utils

MASA.EShop

BlazorComponent

MASA.Blazor

关于本文章的任何观点和问题，都可以留言或者发简信给我！