Dapr
概述
简介
官方解释Dapr（Distributed Application Runtime）是一个可移植的、事件驱动的运行时
- 可移植性：指与软件从某以缓解转移到另一个环境的难易程度。
- 事件驱动每个：调用方与被调用方解耦
任何语言，任何框架，任何地方
如今，我们正经历着上云浪潮。 开发人员对 Web + 数据库应用架构（例如经典 3 层设计）非常熟悉，并且使用得手，但对本身能支持分布式的微服务应用构建却感觉陌生。 成为分布式系统专家很难，并且你也不需要这么做。 开发人员希望专注于业务逻辑，同时希望平台为其提供可伸缩的、弹性的、可维护的和云原生架构的其他功能。
这就是Dapr所要解决的。 Dapr 将 最佳实践 编纂成开放、独立的 API（称为构建基块），使您能够使用所选的语言和框架构建可移植应用程序。 每个构建块都是完全独立的，您可以采用其中一个、多个或全部来构建你的应用。
使用 Dapr，您可以将现有应用程序增量迁移到微服务架构，从而采用云原生模式，例如横向扩展/收缩（scale out/in）、弹性和独立部署。
此外，Dapr 与平台无关，这意味着您可以在本地、任何 Kubernetes 集群、虚拟机或物理机以及 Dapr 集成的其他托管环境中运行应用程序。 这使得您能够在云平台和边缘计算中运行微服务应用。
云平台和边缘计算的微服务构建块
在设计微服务应用时，需要考虑很多因素。 Dapr 在构建微服务应用时为常见功能提供了最佳实践，开发人员可以使用标准方式然后部署到任何环境。 Dapr 通过提供分布式构建块来实现此目的。
每个构建块 API 都是独立的，这意味着您可以采用其中一个、多个或全部来构建应用。 目前，可用的构建块如下：
| 构建块 | 说明 |
|---|---|
| 服务调用 | 跨服务调用允许进行远程方法调用(包括重试)，不管处于任何位置，只需该服务托管于受支持的环境即可。 |
| 状态管理 | 独立的状态管理，使用键/值对作为存储和查询机制，可以轻松的使长时运行、高可用的有状态服务和无状态服务共同运行在您的应用程序中。 状态存储是可插拔的，示例包括 AWS DynamoDB、Azure CosmosDB、Azure SQL Server、GCP Firebase、PostgreSQL 或 Redis 等。 |
| 发布订阅 | 在服务之间发布事件和订阅主题，使事件驱动的架构能够简化水平可伸缩性，并使其能够灵活应对故障。 Dapr 提供至少一次(at-least-once)消息传递保证，消息TTL，消费者组和其他高级功能。 |
| 资源绑定 | Dapr 的 Bindings 是建立在事件驱动架构的基础之上的。通过建立触发器与资源的绑定，可以从任何外部源（例如数据库，队列，文件系统等）接收和发送事件，而无需借助消息队列，即可实现灵活的业务场景。 |
| Actors | 状态和无状态对象的模式，使并发简单，方法和状态封装。 Dapr 在 Actor 模式中提供了很多功能，包括并发，状态管理，用于 actor 激活/停用的生命周期管理，以及唤醒 actor 的计时器和提醒器。 |
| 可观测性 | Dapr记录指标，日志，链路以调试和监视 Dapr 和用户应用的运行状况。 Dapr 支持分布式跟踪，其使用 W3C 跟踪上下文标准和开放式遥测技术，可以轻松地诊断在生产环境中服务间的网络调用，并发送到不同的监视工具。 |
| 秘密 | Dapr 提供了密钥管理，支持与公有云和本地的 Secret 存储集成，以供应用检索使用。 |
| Configuration (配置) |
Sidecar架构
Dapr以 sidecar 架构的方式公开其API，可以是容器，也可以是进程，不需要应用代码包含任何 Dapr 运行时代码。 这使得 Dapr 与其他运行时的集成变得容易，在应用逻辑层面做了隔离处理，提高了可扩展性。
托管环境
Dapr可以在多种环境中托管，包括在 Windows/Linux/MacOS 机器上的自托管以进行本地开发；在 Kubernetes 或生产环境中的物理机或虚拟机器集群上托管。
自托管模式本地开发
自托管模式下，Dapr运行一个单独的sidecar程序，再服务代码中可以通过HTTP或gRPC调用它。每个运行的服务都有一个Dapr运行时进程（或Sidecar），配置为使用状态存储，pub/sub,绑定组件和其他构件块。
您可以使用 Dapr CLI 在本地机器上运行启用了 Dapr 的应用程序。 下图显示了使用 CLI init 命令配置 Dapr 的本地开发环境。 请使用 入门示例。
Kubernetes
Kubernetes 既可用于本地开发（例如使用 minikube, k3S），也可用于 生产。 在托管在容器环境中（如 Kubernetes），Dapr 作为 sidecar 容器运行，和应用程序容器在同一个 pod 中。
Dapr有控制平面服务。 在 Kubernetes 中， dapr-sidecar-injector 和 dapr-operator 服务提供一流的集成，以将 Dapr 作为 sidecar 容器启动在与服务容器相同的 pod 中 ，并为在集群中部署的 Dapr 组件提供更新通知。
dapr-sentry 服务是一个证书颁发机构，它支持 Dapr sidecar 实例之间的相互 TLS 以实现安全的数据加密，并通过 Spiffe 提供身份。 关于 Sentry 服务的更多信息请阅读 安全概述
在 Kubernetes 集群中部署和运行启用 Dapr 的应用程序非常简单，只需向 deployment 方案添加一些注解。 访问 Kubernetes 文档上的 Dapr
物理机或虚拟机集群
例如，Dapr 控制平面服务可以在高可用性 （HA） 模式下部署到生产环境中的物理机或虚拟机集群，如下图所示。 在这里，Actor Placement 和 Sentry 服务在三个不同的 VM 上启动，以提供 HA 控制平面。 为了给在集群中运行的应用程序提供使用 DNS 名称解析，Dapr使用 Hashicorp Consul 服务，也在HA模式下运行。
构建块
可通过标准的HTTP或gRPC API访问模块化的最佳实战
构建块是HTTP或gRPC API，并使用一个或多个Dapr组件。
构建块解决了构建弹性微服务应用程序中的常见挑战，并编纂了最佳实践和模式。 Dapr由一组构建块组成，并且具有可扩展性以添加新的构建块。
下图显示了构建块如何公开了可被代码调用的公共 API ，并使用组件来实现构建块的能力。
以下是 Dapr 提供的构建块类型:
Dapr和服务网格
Dapr 使用 sidecar 架构，与应用程序一起作为单独的流程运行，包括服务调用、网络安全和分布式跟踪等功能。 这往往会引起一个问题：Dapr与服务网格解决方案如 Linkerd, Istio 和 Open Service Mesh 等相比如何？
Dapr 和服务网格的比较
虽然 Dapr 和服务网格确实存在一些重叠功能，但 Dapr 不是服务网格 ，尤其服务网格被定义为 “网络” 服务网格。 与专注于网络问题的服务网格不同，Dapr 专注于提供构建块，使开发人员更容易将应用程序构建为微服务。 Dapr 以开发人员为中心，而服务网格以基础设施为中心。
在大多数情况喜爱，开发人员不需要意识他们正在构建的应用程序将部署在包括服务网格在内的环境中，因为服务网格会拦截网络流量。服务网格大多由系统意义上管理和部署，而Dapr构建块API则打算由开发人员在其代码中明确使用。
Dapr与服务网格都有的一些常见功能包括：
- 基于 mTLS 加密的服务到服务安全通信
- 服务到服务的度量指标收集
- 服务到服务分布式跟踪
- 故障重试恢复能力
重要的是Dapr一开发人员为中心，提供了通过名称进行服务发现和调用的方式。也就是说，通过Dapr的服务调用API，开发人员使用服务名称进行调用，而服务网格则需要处理网络概念，例如IP和DNS地址。但是，Dapr不提供路由或流量分配等关于流量控制的功能。流量路由通常在应用程序入口中代理，不必使用服务网格。此外，Dapr还提供了其他与级别的构建块，如状态管理、发布订阅、参与者等。
Dapr和服务网格之间的另一个区别是可观察性（追踪和度量）。服务网格在网格级别运行，并追踪服务之间的网格调用。Dapr是通过服务调用的方式来实现的。此外，Dapr还写入CloudEvent信封的trace ID，在发布、订阅中提供可观察性（跟踪诶嘿metrics）。这意味着在应用程序中，使用Dapr进行度量和跟踪必使用“服务到服务调用”即“发布、订阅进进行通讯”的服务网格更热扩展。
下图展示了 Dapr 和服务网格提供的重叠功能和独特功能：
将Dapr与服务网格一起使用
Dapr 也适用于服务网格。 如果两者部署在一起，Dapr 和服务网格的 sidecar 都在应用环境中运行。 在这种情况下，建议mTLS 加密和分布式跟踪功能仅在 Dapr 或 服务网格中的一方进行配置。
如需了解更多关于同时运行 Dapr 及服务网格的信息，可参阅以下来自 Dapr 社区的相关资料：
如何选择
您应该使用 Dapr、服务网格还是两者兼而有之？ 答案取决于您的需求。 例如，如果您希望将 Dapr 用于一个或多个构建块，例如状态管理或 发布/订阅，同时考虑仅针对网络安全或可观察性使用服务网格，那您可能会发现 Dapr 已经非常合适，并不需要使用服务网格。
一个需要同时使用 Dapr 和服务网格的典型场景是：所有应用程序的通信作为一个整体策略，都需要进行加密处理的时候。 例如，您可能仅在应用程序的一部分中使用 Dapr，而应用程序中未使用 Dapr 的其他服务和处理也需要加密通信。 在这种场景下，使用服务网格是更好的选择。且最好您在服务网格中启用 mTLS 及分布式跟踪功能，并在 Dapr 中禁用掉它们。
如果您为了A/B 测试，需要进行流量拆分，使用服务网格将使您受益，因为 Dapr 并没有提供这些功能。
在某些情况下，如果您需要两者都独有的功能，您会发现同时使用 Dapr 和服务网格是很有用的 - 如上所述，同时使用它们是没有任何限制的。