Java开发人员的Dapr

在本文中，您将了解到Dapr项目如何减轻Java开发人员的认知负荷并减少应用程序的依赖关系。

为云端编写Java应用程序不仅需要对分布式系统、云最佳实践和常用模式有深入理解，还需要理解Java生态系统，以了解如何结合许多库使其正常工作。

Spring Boot等工具和框架通过筛选常用的Java库（例如，日志记录（Log4j）、解析不同格式（Jackson）、处理HTTP请求（Tomcat、Netty、响应式堆栈）等）显著提高了开发人员的体验。虽然Spring Boot提供了一套抽象、最佳实践和常见模式，但开发人员仍然需要了解两件事才能编写分布式应用。

首先，他们必须清楚地了解根据可用基础设施，他们必须向其应用程序添加哪些依赖项（客户端/驱动程序）。例如，他们需要了解他们需要哪种数据库或消息代理，以及他们需要向类路径中添加什么驱动程序或客户端以连接到它。其次，他们必须知道如何配置该连接、凭据、连接池、重试和应用程序按预期工作所需的其他关键参数。理解这些配置参数促使开发人员了解这些组件（数据库、消息代理、配置存储、身份管理工具）的工作方式，这超出了他们编写应用程序业务逻辑的责任范围。

学习最佳实践、常见模式以及大量应用程序基础架构组件的工作方式并不错，但会大大减少您构建应用程序重要功能所需的开发时间。

在这篇简短的文章中，我们将探讨Dapr项目如何帮助Java开发人员不仅能够实现最佳实践和分布式模式，还能减少应用程序的依赖关系以及开发人员编写应用程序所需的知识量。

我们将看一个简单的示例，您可以在这里找到。

这个Pizza店应用程序展示了大多数商业应用程序可以关联的一些基本行为。该应用程序由三个服务组成，允许顾客在系统中下订单。该应用程序将在数据库（在本例中是PostgreSQL）中存储订单，并使用Kafka在各个服务之间交换事件，以实现异步通知。

所有服务之间的异步通信都用红色虚线箭头标记。让我们先看如何使用Spring Boot实现这一点，然后再添加Dapr。

Spring Boot方案

使用Spring Boot，开发人员可以创建这三个服务，并开始编写处理顾客下订单的业务逻辑。Spring Boot开发人员可以使用http://start.spring.io来选择其应用程序将拥有的依赖项。例如，对于Pizza店服务，他们将需要Spring Web（用于托管和提供前端和一些REST端点），而且如果我们打算在Kubernetes上运行这些服务，还需要Spring Actuators扩展。

但与任何应用程序一样，如果我们想要存储数据，就需要一个数据库/持久性存储，并且我们有许多选项可供选择。如果您查看Spring Data，您会发现Spring Data JPA提供了一个对SQL（关系型）数据库的抽象。

正如您在之前的截图中所看到的，这里还有NoSQL选项和不同的抽象层，这取决于您的应用程序在做什么。如果您决定使用Spring Data JPA，您仍然需要负责将正确的数据库驱动程序添加到应用程序的类路径中。在PostgreSQL的情况下，您也可以从列表中选择它。

如果我们考虑在应用程序服务之间交换异步消息，我们将面临类似的困境，选择太多。

因为我们是开发人员，希望事情能够向前发展，所以我们必须在这里做出一些选择。让我们使用PostgreSQL作为我们的数据库，Kafka作为我们的消息系统/代理。

我是Spring Boot编程模型的坚定信仰者，包括抽象层和自动配置。然而，作为开发人员，你仍然需要确保在服务类路径中包含了正确的PostgreSQL JDBC驱动程序和Kafka客户端。虽然这在Java领域非常常见，但在处理可能由数十甚至数百个服务组成的大型应用程序时，会出现一些问题。

应用程序和基础设施依赖的缺点

从我们的简单应用程序来看，我们可以发现在将该应用程序投入生产时，应用程序和操作团队必须面对一些挑战。

让我们从应用程序依赖和它们与我们决定使用的基础设施组件的关系开始。

你可以在你的Spring Boot应用程序中添加以下依赖，将Dapr与Testcontainers集成在一起

<dependency>


  <groupId>io.diagrid.dapr</groupId>


  <artifactId>dapr-spring-boot-starter</artifactId>


  <version>0.10.7</version>


</dependency>

在这里查看存储库。

Testcontainers(现在是Docker的一部分)是Java中一个流行的工具，主要用于容器，主要用于测试，特别是使用容器设置复杂基础架构的集成测试。

我们的三个Pizza Spring Boot服务具有相同的依赖性。这允许开发人员启用其Spring Boot应用程序来在本地开发中消耗Dapr构建块API，而无需任何Kubernetes、YAML或配置。

一旦有了这个依赖关系，您就可以开始使用Dapr SDK与Dapr构建块API进行交互，例如，如果您希望使用Statestore API存储传入的订单：

其中` STATESTORE_NAME `是已配置的Statestore组件名称，` KEY `只是一个我们要用来存储此订单的键，` order `是我们从Pizza商店前端收到的订单。

类似地，如果您希望向其他服务发布事件，您可以使用PubSub Dapr API；例如，要发布包含订单作为有效负载的事件，您可以使用以下API：

publishEvent API发布一个包含`订单`作为有效负载的事件进入由PUBSUB_TOPIC指示的特定主题的Dapr PubSub组件(PUBSUB_NAME)。

现在，这将如何运作？当我们调用saveState() API时，Dapr是如何存储状态的，或者当我们调用publishEvent() 时，事件是如何发布的？

默认情况下，Dapr SDK将尝试调用Dapr API端点到本地主机，因为Dapr是设计为在应用程序旁边运行的。出于开发目的，为了使Spring Boot应用程序启用Dapr，您可以使用其中一个内置配置文件：DaprBasicProfile 或 DaprFullProfile。

基本配置文件提供对Statestore和PubSub API的访问，但诸如Actors和Workflows之类的更高级功能将无法工作。如果您想访问所有Dapr构建块，可以使用完整配置文件。这两个配置文件都使用Dapr组件的内存实现，使您的应用程序更快地启动。

dapr-spring-boot-starter旨在最大程度地减少开发人员开始在其应用程序中使用Dapr所需的Dapr知识量。因此，除了上述依赖项外，还需要在测试配置中选择要使用的Dapr配置。自Spring Boot 3.1.x以来，您可以定义一个将用于测试目的的Spring Boot应用程序。其思想是允许测试设置您的应用程序，使其具备测试所需的一切。在测试包(`src/test/<package>`)中，您可以定义一个新的@SpringBootApplication类，本例中配置为使用Dapr配置。

您可以看到，这只是我们PizzaStore应用程序的包装器，其中包含DaprBasicProfile的配置。启用DaprBasicProfile后，每当我们为测试目的启动应用程序时，我们需要的Dapr API的所有组件都将为我们的应用程序启动。如果您需要更高级的Dapr设置，您始终可以创建自己的领域特定的Dapr配置。

使用这些测试配置的另一个优势是，我们还可以使用用于本地开发目的的测试配置启动应用程序，方法是运行`mvn spring-boot:test-run`

您可以看到Testcontainers是如何透明地启动`daprio/daprd`容器的。作为开发者，无需关心该容器的配置，只要我们能够使用Dapr的API。 

我强烈建议您在此处查看完整示例，在这里您可以在安装了Dapr的Kubernetes上运行应用程序，或者使用Maven在本地启动每个服务并进行测试。 

如果这个示例对您来说太复杂了，我建议您查看这些博客文章，我在其中从头开始创建了一个非常简单的应用程序： 

• 使用Spring Boot与Dapr StateStore API
• 在Kubernetes中部署和配置我们的简单应用程序