常见问题与解答

• 1: Dapr 常见问题解答
• 2: Dapr 与服务网格

1 - Dapr 常见问题解答

Dapr 与服务网格（如 Istio、Linkerd 或 OSM）相比如何？

Dapr 不是服务网格。虽然服务网格专注于细粒度的网络控制，但 Dapar 专注于帮助开发者构建分布式应用程序。Dapr 和服务网格都使用边车模式，并与应用程序一起运行。它们确实有一些重叠的功能，但也提供各自独特的优势。有关更多信息，请阅读 Dapr & 服务网格 概念页面。

性能基准测试

由于 Dapr 作为应用程序的边车，其项目特别关注性能。请参阅 性能结果 获取最新的性能数据。

Actors

Dapr、Orleans 和 Service Fabric Reliable Actors 之间是什么关系？

Dapr 中的 actors 基于 Orleans 开创的虚拟 actor 概念，意味着它们在调用时激活，并在一段时间后停用。如果你熟悉 Orleans，Dapr C# actors 会让你感到熟悉。Dapr C# actors 基于 Service Fabric Reliable Actors（同样源自 Orleans），使你能够将 Service Fabric 中的 Reliable Actors 迁移到其他托管平台，例如 Kubernetes 或其他本地环境。

此外，Dapr 不仅仅是关于 actors。它为你提供了一套构建任何微服务应用程序的最佳实践构建块。请参阅 Dapr 概述。

Dapr 与 actor 框架的区别

虚拟 actor 功能是 Dapr 在其运行时中提供的构建块之一。使用 Dapr，由于它具有编程语言无关的 http/gRPC API，可以从任何语言调用 actors。这允许用一种语言编写的 actors 调用用另一种语言编写的 actors。

创建新 actor 遵循本地调用，如 http://localhost:3500/v1.0/actors/<actorType>/<actorId>/…。例如，http://localhost:3500/v1.0/actors/myactor/50/method/getData 调用新创建的 id 为 50 的 myactor 上的 getData 方法。

Dapr 运行时 SDK 具有特定语言的 actor 框架。例如，.NET SDK 拥有 C# actors。目标是让所有 Dapr 语言 SDK 都拥有 actor 框架。目前 .NET、Java、Go 和 Python SDK 都拥有 actor 框架。

如果我想使用特定的编程语言或框架，Dapr 是否有我可以使用的 SDK？

为了让 Dapr 在不同语言中的使用更加自然，它包括 Go、Java、JavaScript、.NET、Python、PHP、Rust 和 C++ 的特定语言 SDK。这些 SDK 通过类型化语言 API 而非调用 http/gRPC API 来暴露 Dapr 构建块中的功能，例如保存状态、发布事件或创建 actor。这使你能够用你选择的语言编写无状态和有状态函数及 actor 的组合。而且由于这些 SDK 共享 Dapr 运行时，你将获得跨语言的 actor 和函数支持。

Dapr 与哪些框架集成？

Dapr 可以与任何开发者框架集成。例如，在 Dapr .NET SDK 中，你可以找到 ASP.NET Core 集成，它提供了响应来自其他服务的发布订阅事件的有状态路由控制器。

Dapr 与以下框架集成：

• Functions 与 Dapr Azure Functions 扩展
• Java SDK 中的 Spring Boot Web 应用
• .NET SDK 中的 ASP.NET Core
• Azure API Management

2 - Dapr 与服务网格

Dapr 采用边车架构，作为独立进程与应用程序并肩运行，并包含服务调用、网络安全和分布式追踪等功能。这经常会引发一个问题：Dapr 与 Linkerd、Istio 和 Open Service Mesh 等服务网格解决方案相比如何？

Dapr 与服务网格的对比

虽然 Dapr 与服务网格确实提供了一些重叠的能力，但Dapr 不是服务网格，这里的服务网格被定义为一种网络服务网格。与服务网格专注于网络关注点不同，Dapr 专注于提供使开发者更易于以微服务方式构建应用程序的构建块。Dapr 以开发者为中心，而服务网格以基础设施为中心。

在大多数情况下，开发者不需要知道他们正在构建的应用程序将被部署在包含服务网格的环境中，因为服务网格会拦截网络流量。服务网格主要由系统运维人员管理和部署，而 Dapr 构建块 API 旨在供开发者在代码中显式使用。

Dapr 与服务网格共享的一些常见能力包括：

• 使用 mTLS 加密的安全服务间通信
• 服务间指标收集
• 服务间分布式追踪
• 通过重试实现的弹性

重要的是，Dapr 通过名称提供服务发现和调用，这是一个以开发者为中心的关注点。这意味着通过 Dapr 的服务调用 API，开发者调用服务名称上的方法，而服务网格处理 IP 地址和 DNS 地址等网络概念。然而，Dapr 不提供流量行为方面的能力，如路由或流量分割。流量分割通常通过应用程序的入口代理来解决，不必使用服务网格。此外，Dapr 还提供其他应用程序级构建块，用于状态管理、发布订阅消息传递、actors 等。

Dapr 与服务网格之间的另一个区别是可观测性（追踪和指标）。服务网格在网络级别运行，并追踪服务之间的网络调用。Dapr 通过服务调用来实现这一点。此外，Dapr 还通过写入 Cloud Events 信封中的追踪 ID，为发布订阅调用提供可观测性（追踪和指标）。这意味着对于同时使用服务间调用和发布订阅进行通信的应用程序，Dapr 的指标和追踪比服务网格更全面。

下图展示了 Dapr 和服务网格提供的重叠功能和独特能力：

将 Dapr 与服务网格一起使用

Dapr 确实可以与服务网格一起工作。在两者一起部署的情况下，Dapr 和服务网格边车都在应用程序环境中运行。在这种情况下，建议只配置 Dapr 或只配置服务网格来执行 mTLS 加密和分布式追踪。

观看以下 Dapr 社区会议的录像，这些录像展示了将 Dapr 与不同服务网格一起运行的演示：

• Dapr 和 Linkerd的概述和演示
• 运行 Dapr 和 Istio的演示

何时使用 Dapr 或服务网格或两者兼用

您应该使用 Dapr、服务网格，还是两者兼用？答案取决于您的需求。例如，如果您希望将 Dapr 用于一个或多个构建块（如状态管理或发布订阅），并且您正在考虑使用服务网格只是为了网络安全或可观测性，您可能会发现 Dapr 是一个很好的选择，而无需使用服务网格。

通常，在企业策略要求所有应用程序的网络流量必须加密的情况下，您会将服务网格与 Dapr 一起使用。例如，您可能只在应用程序的一部分中使用 Dapr，而应用程序中未使用 Dapr 的其他服务和进程也需要对其流量进行加密。在这种情况下，服务网格是更好的选择，最有可能的是，您应该在服务网格上使用 mTLS 和分布式追踪，并在 Dapr 上禁用这些功能。

如果您需要为 A/B 测试场景进行流量分割，您将从使用服务网格中受益，因为 Dapr 不提供这些能力。

在某些情况下，当您需要两者独有的能力时，您会发现同时利用 Dapr 和服务网格很有用；如上所述，同时使用它们没有任何限制。