前言

上一篇我们讲了使用HttpClient的方式调用，那么如果我们现在需要更换为通过dapr实现服务调用，我们需要做哪些事情呢？

介绍

Dapr简化了云原生开发，让开发可以把焦点放在应用的业务逻辑上，从而让代码简单、可移植，那作为一个.Net开发者，我们也希望项目可以快速用上dapr，那究竟应该如何做呢？

Dapr提出了Sidecar(边车)的概念，在启动项目时再额外启动一个Sidecar, 通过Sidecar可以解决进程间通信，为此官方提供了两种部署方式：

1. 自托管方式下运行Dapr
2. 在 Kubernetes 模式中部署和运行 Dapr

其中Kubernetes模式部署是通过Kubernetes来完成的，在开发中我们更多的是通过自托管模式使用Dapr，那自托管模式是怎么做的呢？

使用命令行工具，在项目根目录输入：

1

dapr run --app-id assignment-server --app-port 5038 dotnet run

详细文档参考：手把手教你学Dapr - 3. 使用Dapr运行第一个.Net程序

参考以上详细文档操作后，我们就可以在命令行工具中执行dapr invoke --app-id assignment-server --method hello或者Http请求来调用对应的应用的方法

看似好像也不是很复杂，但如果你需要调试dotnet项目呢？再复杂一点的需要启动多个项目进行调试呢？端口一多起来的确会显得很麻烦。

有没有什么办法可以解决呢？有，docker-compose。

但我还不想用这么重的东西，我想像平时开发项目一样直接在windows上运行可不可以？

目录

手把手教你学Dapr - 1. .Net开发者的大时代

手把手教你学Dapr - 2. 必须知道的概念

手把手教你学Dapr - 3. 使用Dapr运行第一个.Net程序

手把手教你学Dapr - 4. 服务调用

手把手教你学Dapr - 5. 状态管理

手把手教你学Dapr - 6. 发布订阅

手把手教你学Dapr - 7. Actors

手把手教你学Dapr - 8. 绑定

手把手教你学Dapr - 9. 可观测性

介绍

通过Tracing(跟踪)、Metrics(指标)、Logs(日志)和Health(运行状况)监控应用程序。

分布式跟踪

Dapr 使用 Zipkin 协议进行分布式跟踪 和 Metrics 收集。由于 Zipkin 协议的普遍性，许多后端都是开箱即用的，例如 Stackdriver、Zipkin、New Relic 等。结合 OpenTelemetry Collector，Dapr 可以将跟踪导出到许多其他后端，包括但不限于 Azure Monitor、Datadog、Instana、Jaeger 和 SignalFX。

Tracing设计

Dapr 在 Dapr Sidecar 中添加了一个 HTTP/gRPC 中间件。中间件拦截所有 Dapr 和应用程序流量，并自动注入关联 ID 以跟踪分布式事务。这种设计有几个好处：

• 无需代码检测。使用可配置的跟踪级别自动跟踪所有流量。
• 跨微服务的一致性跟踪行为。跟踪是在 Dapr Sidecar 上配置和管理的，因此它在由不同团队制作并可能用不同编程语言编写的服务之间保持一致。
• 可配置和可扩展。利用 Zipkin API 和 OpenTelemetry Collector，Dapr 跟踪可以配置为与流行的跟踪后端一起使用，包括客户可能拥有的自定义后端。
• 您可以同时定义和启用多个导出器。

介绍

使用绑定，您可以使用来自外部系统的事件触发您的应用程序，或与外部系统交互。这个构建块为您和您的代码提供了几个好处：

• 消除连接和轮询消息系统（如队列和消息总线）的复杂性
• 关注业务逻辑，而不是如何与系统交互的实现细节
• 让您的代码不受 SDK 或库的影响
• 处理重试和故障恢复
• 运行时在绑定之间切换
• 构建可移植的应用程序，其中设置了特定于环境的绑定，不需要更改代码

介绍

Actor模式将Actor描述为最低级别的“计算单元”。换句话说，您在一个独立的单元（称为actor）中编写代码，该单元接收消息并一次处理一个消息，没有任何并发或线程。

再换句话说，根据ActorId划分独立计算单元后，相同的ActorId重入要排队，可以理解为lock(ActorId)

注：这里有个反例，就是重入性的引入，这个概念目前还是Preview，它允许同一个链内可以重复进入，判断的标准不止是ActorId这么简单，即自己调自己是被允许的。这个默认是关闭的，需要手动开启，即默认不允许自己调自己。

当您的代码处理一条消息时，它可以向其他参与者发送一条或多条消息，或者创建新的参与者。底层运行时管理每个参与者运行的方式、时间和地点，并在参与者之间路由消息。

大量的Actor可以同时执行，Actor彼此独立执行。

Dapr 包含一个运行时，它专门实现了 Virtual Actor 模式。 通过 Dapr 的实现，您可以根据 Actor 模型编写 Dapr Actor，而 Dapr 利用底层平台提供的可扩展性和可靠性保证。

什么时候用Actors

Actor 设计模式非常适合许多分布式系统问题和场景，但您首先应该考虑的是该模式的约束。一般来说，如果出现以下情况，请考虑使用Actors模式来为您的问题或场景建模：

• 您的问题空间涉及大量（数千个或更多）小的、独立且孤立的状态和逻辑单元。
• 您希望使用不需要与外部组件进行大量交互的单线程对象，包括跨一组Actors查询状态。
• 您的 Actor 实例不会通过发出 I/O 操作来阻塞具有不可预测延迟的调用者。

介绍

发布/订阅模式允许微服务使用消息相互通信。生产者或发布者在不知道哪个应用程序将接收它们的情况下向主题发送消息。这涉及将它们写入输入通道。同样，消费者或订阅者订阅该主题并接收其消息，而不知道是什么服务产生了这些消息。这涉及从输出通道接收消息。中间消息代理负责将每条消息从输入通道复制到所有对该消息感兴趣的订阅者的输出通道。当您需要将微服务彼此分离时，这种模式特别有用。

Dapr 中的发布/订阅 API 提供至少一次（at-least-once）的保证，并与各种消息代理和队列系统集成。 您的服务所使用的特定实现是可插入的，并被配置为运行时的 Dapr Pub/Sub 组件。 这种方法消除了您服务的依赖性，从而使您的服务可以更便携，更灵活地适应更改。

Dapr 发布/订阅构建块提供了一个与平台无关的 API 来发送和接收消息。您的服务将消息发布到命名主题，并订阅主题以使用这些消息。

下图显示了一个“shipping”服务和一个“email”服务的例子，它们都订阅了“cart”服务发布的主题。每个服务都会加载指向同一发布/订阅消息总线组件的发布/订阅组件配置文件，例如 Redis Streams、NATS Streaming、Azure Service Bus 或 GCP Pub/Sub。

下图具有相同的服务，但是这次显示的是 Dapr 发布 API，它发送“订单”主题和订阅服务上的订单端点，这些主题消息由 Dapr 发布到。

介绍

使用状态管理，您的应用程序可以将数据作为键/值对存储在支持的状态存储中。

您的应用程序可以使用 Dapr 的状态管理 API 使用状态存储组件来保存和读取键/值对，如下图所示。例如，通过使用 HTTP POST，您可以保存键/值对，通过使用 HTTP GET，您可以读取键并返回其值。

介绍

通过使用服务调用，您的应用程序可以使用标准的gRPC或HTTP协议与其他应用程序可靠、安全地通信。

注意：

文章中提到的命令行工具即是Windows Terminal/PowerShell/cmd其中的一个，推荐使用Windows Terminal

运行命令行工具的时候建议以管理员身份，避免踩坑

为了保证操作顺畅，建议使用PowerShell先执行一下set-ExecutionPolicy RemoteSigned

Sidecar 边车

Dapr API提供Http和gRPC两种通讯方式。

运行方式则可以是容器也可以是进程（Windows开发推荐使用Self Hosted，后续会解释）。

这样的好处是与运行环境无关，且独立运行不需要应用包含Dapr运行时的代码。只需要通过SDK集成即可，这使得Dapr与应用的逻辑分离。

Building blocks 构建块

官方解释：可通过标准HTTP或gRPC api访问的模块化最佳实践

通俗一点来说，就是API

目前支持的构建块如下，但1.5很快会出一个新的Configuration API（从这个新的API又印证了构建块的本质），由阿里-敖小剑牵头整理的

Github Issue: https://github.com/dapr/dapr/issues/2988

这个提案很长，很曲折。仔细看会发现中外开发大环境下的一些思想碰撞。微软相对保守，阿里相对激进但也更务实。最终长达几个月的激烈讨论下定版。

期间本人也有幸与阿里-敖小剑和阿里-仪式（Layotto的研发同学，Layotto兼容Dapr协议，是蚂蚁在做）开过语音会议一起聊过对于Configuration API的一些设计问题。