该部分主要是给出学习dapr的入门，描述dapr全貌告诉你dapr是啥以及介绍dapr的主要功能与组件
该部分分为两章：
第一章：介绍dapr
第二章：调试dapr的解决方案项目
一. 介绍dapr
该章节将会为你介绍分布式应用运行时Distributed Application Runtime (Dapr)项目，可以让你学到dapr架构的核心概念，也为你开发dapr提供准备。
dapr能够助力搭建云原生应用的开发，以及简化使用微服务架构的难度。
在该章节，我们将会阐述一下几个主题：
1）dapr的概述
2）dapr的架构
3）dapr的入门
4）搭建一个dapr样例
在这个阶段，学习这些主题是非常重要的，它可以为我们学习dapr打下坚实的基础，也为去理解微服务架构提供便捷，通过本书剩下的章节，可以指导我们学习dapr。
首先，开启探索dapr的第一步就是理解它是如何工作的。
1. 专业准备
在github上找到源码：https://github.com/
PacktPublishing/Practical-Microservices-with-Dapr-and-.NET/
tree/main/chapter01
在这个章节，找到需要运行的脚本与代码路径<repositorypath>\chapter01
2.dapr的整体概述
Dapr是有微软公司研发并开源的基于事件驱动、易扩展的运行时。目前正在开发阶段，已经发布1.0版本，现在可以商用了
在dapr的定义中着重强调了事件驱动这个概念，这说明事件驱动在以微服务架构的应用中起到重要作用，从外部系统或者本系统的其他部分，都是以事件的形式将通知其他服务以便执行后续的业务逻辑。
dapr的扩展性主要表现在它可以在你的开发机上以self-hosted方式启动，也可以部署在系统边缘（边缘计算？）或者部署在kubernets上
如下图可以展示出dapr架构中的多种构建模块：
可移植性是超出了现有的托管环境，这是微软在dapr上的一项创举，dapr可以在本地或者云上，比如 Microsoft
Azure, Amazon AWS, Google GCP 或者其他云服务商。
Dapr是部署在由微软研发具有超大规模开发建设经验的云原生应用，它的灵感来自Orleans和Service Fabric的设计，这使许多Microsoft Azure云服务可以在以下位置弹性运行规模大。
Dapr为开发者提供了基于微服务架构风格的一种设计方法，一种构建工具，一个应用的运行时。
微服务可以为复杂度增长的团队与产品管理提供很多有效的帮助，但是通常在开始阶段，也会给团队带来比较大的负担。
如果您可以利用诸如Dapr之类的运行时来帮助您解决常见问题，该怎么办？
您可能需要采用和简化操作的模式？
如下图，展示的是两种dapr的启动方式：
图1.2 Dapr的边车设计
如图1.2所示，Dapr运行时在Sidecar进程中运行，将应用程序与环境的复杂度解耦，极大程度的简化了开发和运维成本。 这些Sidecar进程可以在本地开发环境运行或者部署在Kubernetes的Pod的容器中。
从应用程序的角度，Dapr就是一种可以通过Http/gRPC调用，或者是使用更为简单的SDKs调用的API。目前客户端支持语言包含：.NET Core, Java, Go, Python, C++, JavaScript, Rust。
正如我们所希望的是，在将来，我们不仅采用SDK的方式在应用中使用Dapr，而是希望使用比较简单的Http调用方式调用Dapr服务，比如这样的服务endpoint：
http://localhost:3500/v1.0/invoke/<app-id>/method/<method name>.
尽管如此，如果使用Dapr这种模式去写一个服务，使用SDK还是会给你带来比较多的好处。
3. Dapr不能做到
尽管我们希望Dapr可以引起你的注意且你会化大量的时间学习这本书，但是当聊起Dapr的时候我都会澄清Dapr不能做到哪些方面，这样会让你对Dapr减少不必要的误解而更清楚Dapr到底是啥：
1）Dapr的目标不是强迫开发人员采用具有严格规则和约束的编程模型。相反，Dapr是助力于开发者从很多复杂的微服务实现中解脱出来。举个例子，在Dapr中存储的数据库连接池的管理的状态（下章节会介绍）将会转换成微服务应用代码。
2）Dapr不是Service Mesh。尽管有很多相似点存在于Dapr与service mesh之间，Dapr在应用程序层级提供服务而service mesh却是在infrastructure层进行操作。例如Dapr在与存储组件和服务交互时需要重试逻辑，但是这个职责是开发者根据Dapr返回的错误信息决定如何处理错误
是把错误返回给客户端还是采取重试机制（netcore下Polly可以支持），这对开发者来说是可以选择一个明确的选择。Dapr只是集成service mesh，比如Istio，在本书中不做赘述。
3）Dapr不是微软的云服务：它能帮助开发者在云端搭建微服务应用，现在它不光能支持集成在Azure云，而且还支持其他云商，比如AWS，GCP，其他等。Dapr运行在K8s上的效果都一致。
4. Dapr的架构
Dapr一开始就被设计为一组可插拔的构建模块（building blocks）：
开发者可以通过底层支持服务搭建新应用，而运维者可以采用简单的更改配置项来运维应用程序。
如下是一个Dapr的工具和组件的详细列表：
1）Dapr CLI：一个跨平台的命令行工具，可以配置管理监控Dapr环境。也可以在本机debug Dapr应用程序。
2）Dapr API：定义应用与Dapr之间的交互，以便于利用其公用的构建模块
3）Dapr runtime：这是Dapr的核心逻辑，它实现了API的接口。如果你是一个有好奇感的人，你可以去github仓库去看一下这块源码是怎么设计的：https://github.com/dapr/dapr
4）Dapr host：在你本机的开发环境，host主机作为一个独立的进程运行，在K8s上，在你应用程序Pod里这块作为一个边车容器运行。
5）Dapr operator：特定于K8s模式，运维人员管理绑定关系与配置相关。
6）Dapr边车注入器：在K8s模式下一旦被构建启动，这个注入器就会以边车的形式运行在你的应用程序Pod内。
7）Dapr搭建服务：此服务的目的是分发Dapr容器里面的Actor实例。
8）Dapr安全：Dapr使用内置证书机制来管理服务之间的mTLS协议。
Dapr提供了很多构建模块，微服务开发者可以有选择的按需选取：
1）服务调用：服务之间的调用可以让你的代码可以去访问在相同host环境下的其他服务，同时注意重试策略。（第三章介绍服务调用）
2）状态管理：为了可以支持后端使用有状态或无状态服务，状态管理提供了一套简单有效的管理状态的k-v键值对。Dapr可以提供多种存储介质，包含redis、Azure CosmosDB, Azure SQL Server, PostgreSQL，这些都是可以通过配置文件插拔式使用（第四章介绍状态管理）
3）发布订阅消息：发布订阅模式是通过依赖servicebus中消息在微服务之间发布消费的方式实现的。（第五章介绍发布订阅）
4）资源绑定：这就是消息驱动的亮点：通过Twilio（貌似是消息发送者）发送一个SMS消息就能触发你的应用程序，做到资源绑定中的弱关联。（第六章介绍资源绑定）
5）Actors：actor模型的目的是通过使用大量的计算单元拆分高并发，大吞吐量的请求。小的计算单元是比较小但是独立运行独立空间的进程。（第七章介绍使用Actors）
6）监控：Dapr可以让开发者与运维人员很好的监控系统应用的行为而不用深入侵入进去（第九章介绍追踪Dapr应用）
7）安全：这是一个通用的需求，一个健康的微服务就要必须将自己的代码放置在一个安全的环境中，包括在开发环境使用了线上的连接串等，这些Dapr都可以使用安全组件实现。
