共计 2256 个字符，预计需要花费 6 分钟才能阅读完成。
Dapr 全称
Distributed Application Runtime，分布式应用运行时
Dapr 的口号
简化云原生利用开发，聚焦在利用的外围逻辑，让代码简略、可移植
Dapr 的指标
- 最佳实际的构建块
- 任何语言或框架
- 一致性，可移植，凋谢的 API
- 驳回规范
- 可扩大和可插拔的组件
- 与平台无关(本地，云计算，边缘计算等)
- 社区驱动，供应商 (厂商) 中立
Dapr 的设计思路
这里首先要先了解几个问题，而后再看 Dapr 如何解决这些问题的
以下材料都有英文原图，中文翻译为集体了解，英文好的小伙伴能够间接看原图。
微服务为什么很难
- 开发者要构建本人的运行时解决分布式应用问题
- 运行时反对的开发语言无限, 且有严格控制的个性（性能）汇合
- 运行时的可移植性无限，个别只反对特定的基础架构平台
分布式应用的需要
内容引自 Multi-Runtime Microservices Architecture https://www.infoq.com/article…
留神：二级内容不与图片对应，把性能组合成场景
-
生命周期
- 更快的公布周期
- 自动化部署
- 从谬误中复原
- 自动化伸缩
-
网络
- 服务发现
- 跟踪与遥测（可观测性）
- 信息替换：点对点、公布 / 订阅，智能路由
-
状态
- 服务编排、工作流
- 分布式单例（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 更具象化了
- 与应用程序通过 HTTP 和 gRPC 通信
- 外部有一些构建块
- 运行在云上
Dapr 与服务网格
- 开发者更聚焦在代码层面，通过 SDK(图中没有标注)与 dapr 的构建块通信，面向 localhost 编程
- 运维更关注安全性、可观测性、健壮性等问题上。而流量管控的局部，dapr(可能是临时的)没有。
Sidecar 的世界
- 利用于 Sidecar 通信是通过 Dapr API(曾经被封装成不同开发语言的 SDK)，这个过程中通过 OpenTelemetry 反对了可观测性（即跟踪、日志、指标）
- 利用之间通过 Sidecar 通信，反对 mTLS，这个指服务调用（即 Service Invocation）
- Sidecar 之间通过 gRPC(图片中没有显示)，Bindings，Pub/Sub 都能够通信
- 可观测性无处不在，通过 Prometheus、Zipkin、Fluentd 等，可视化 OpenTelemetry 中的局部数据
但目前据我所知没有一个能够对立接管残缺 OpenTelemetry 的，如果有的话欢送纠错。
- 状态治理也是由 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），备注来意，邀请进群
(文章转载自：鬼谷子）