Dapr全称

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

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、机甲运行时（网关、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技术栈的更新迭代
• 共享开源生态

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

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

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

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

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

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

MASA.BuildingBlocks

MASA.Contrib

MASA.Utils

MASA.EShop

BlazorComponent

MASA.Blazor

QQ群：7424099

微信群：加技术运营微信（MasaStackTechOps），备注来意，邀请进群