从服务之间的调用来看 我们为什么需要Dapr
Dapr 相关的文章我已经写了20多篇了[1] 。 当向其他人推荐Dapr 的时候，需要回答的一个问题就是：
Dapr 似乎并不是特别令人印象深刻。它提供了一组"构建块"，解决了与构建微服务相关的几个挑战。这些构建基块包括服务到服务调用、发布订阅消息传递、状态管理、可观察性、机密管理和Actor 编程模型。 但是，我们不是已经有了所有这些的解决方案吗？
是的 任何构建微服务应用程序的人都已经不得不处理所有这些问题，我们看到这些人 提到的工具和框架对于减轻痛苦有很长的路要走。 我认为Dapr提供了一些独特的东西。为了说明这一点，我下面将选择一个最常见的构建块 - 服务到服务调用，以强调Dapr如何在您已经在使用的内容之上提供附加值。
当一个微服务需要调用另一个微服务时，需要发生几件事。
首先，我们需要服务发现 - 找到我们正在与之通信的服务地址。当然，Kubernetes通过内置的DNS使这变得非常轻松。但是，开发人员在其开发计算机上本地运行微服务的情况也很常见。在这种情况下，每个微服务都位于特定端口号上的 localhost，这要求您具有一些替代机制，以便在本地运行时指向正确的服务。使用Dapr，无论您是在"自托管"[2]模式下运行（直接在您的计算机上）还是在Kubernetes上运行，您都可以按名称对目标服务进行寻址，服务发现这项富有挑战性的工作交给Dapr 的可插拔的服务发现组件来完成。
其次，在微服务之间进行通信时，如果存在暂时性网络问题请务必重试[3]。当然，这可以通过像Polly[4]这样的库来自己实现，但这需要每个人都记得使用它，很有可能你在微服务中发现了一个错误，该错误是由于忘记实现重试而引起的。那么我们使用Dapr，这只是一个内置功能。
第三，微服务采用零信任的安全原则，保护微服务之间的通信非常重要。通常应使用 mTLS 对通信进行加密，并且应使用身份验证来验证调用方是否已获得授权。一个被广泛认可的最佳实践是使用相互 TLS，但正确配置可能会很痛苦，并且在开发时本地运行时通常会妨碍您。使用 Dapr，所有服务到服务的通信都会使用 mTLS 自动加密[5]，并且证书会自动循环，这为你带走了一个巨大的心智负担。
第四，安全性的另一个方面是管理允许哪些微服务相互调用。例如，微服务 A 可能被允许与微服务 B 通信，但反之亦然。推出自己的框架来配置这样的东西可能会很痛苦，如果你不是安全专家，很容易出错。服务网格可以为 Kubernetes 集群提供这种行为。Dapr还可以通过访问控制列表[6]提供相同的访问限制，这些列表易于配置，甚至可以在"自托管"模式而不是Kubernetes中运行时工作。
第五，如果您具有分布式跟踪和指标收集功能，以便您了解微服务之间的通信，这也是非常有价值。在Azure 通过 Application Insights 提供了此功能，但同样，如果你在本地运行，你就用不了这项服务，而且据我的经验在所有服务上正确配置它时都遇到各种问题。使用 Dapr，可观察性[7]是运行时的另一个内置功能。它使用开放的标准，如OpenTelemetry和W3C跟踪，使它非常容易与现有工具集成，本地开发可以选择zipkin等兼容的解决方案。
最后，我们看到gRPC[8]作为基于HTTP的微服务API的替代品的兴起，因为它的性能更高。在微服务环境中从 HTTP 迁移到 gRPC 可能很棘手，因为您需要同时升级客户端和服务器，或者提供一个同时公开两种协议的接口进行迁移的兼容。Dapr再次可以帮助我们 - 允许gRPC或HTTP用于服务到服务调用[9]，甚至允许HTTP调用方使用gRPC服务，Dapr的Sidecar和Sidecar 之间的所有通信都是通过gRPC。
因此，正如您所看到的，服务调用的"简单"任务有很多，Dapr为您提供了开箱即用的非常全面的解决方案。 Dapr 还提供了很多开箱即用的解决方案，看到这里你相信我了--我们非常需要Dapr 这样的解决方案。