使用Jakarta EE构建云原生微服务：轻量级依赖注入与配置管理

Jakarta EE 构建云原生微服务：轻量级依赖注入与配置管理

大家好，今天我们来探讨如何使用 Jakarta EE 构建云原生微服务，并重点关注轻量级依赖注入（DI）与配置管理这两个关键方面。在云原生架构中，微服务需要具备高度的可配置性、可扩展性和弹性。有效的 DI 和配置管理能够显著提升微服务的开发效率、运维便捷性和整体质量。

一、云原生微服务架构概述

首先，我们简单回顾一下云原生微服务的核心特征：

• 容器化部署： 微服务通常运行在容器（如 Docker）中，实现快速部署和隔离。
• 自动化管理： 利用 Kubernetes 等编排工具实现自动化部署、扩展、监控和修复。
• 弹性伸缩： 能够根据负载自动调整服务实例数量，保证服务质量。
• 去中心化治理： 服务之间通过 API 进行通信，强调服务的自治性和独立性。
• 持续交付： 采用 DevOps 实践，实现快速迭代和持续交付。

二、Jakarta EE 在云原生微服务中的角色

Jakarta EE (原 Java EE) 提供了一套标准的 API 和规范，可以用于构建企业级应用。虽然在过去，Java EE 给人以笨重的印象，但随着 Jakarta EE 的发展，其模块化特性和对轻量级框架的支持，使其非常适合构建云原生微服务。

Jakarta EE 提供了以下关键能力：

• Servlet API： 用于构建 RESTful API 和 Web 服务。
• CDI (Contexts and Dependency Injection)： 提供依赖注入和面向切面编程能力。
• JAX-RS (Java API for RESTful Web Services)： 用于创建 RESTful 服务。
• JSON-P/JSON-B： 用于处理 JSON 数据。
• JPA (Java Persistence API)： 用于数据持久化（在微服务中通常需要谨慎使用，因为微服务倾向于更小的数据域）。
• Config API： 用于配置管理。
• Health Checks:用于微服务监控，通过特定的endpoint来检查微服务的健康状态。

三、轻量级依赖注入 (CDI) 的实践

依赖注入是一种设计模式，用于解耦组件之间的依赖关系。CDI 是 Jakarta EE 标准的依赖注入框架，它允许我们在运行时动态地注入依赖项，从而提高代码的可测试性、可维护性和可重用性。

3.1 CDI 的基本概念

• Beans： 由 CDI 管理的对象。
• Dependency Injection (DI)： 将 Bean 的依赖项注入到 Bean 中。
• Scopes： 定义 Bean 的生命周期（如 @ApplicationScoped，@RequestScoped 等）。
• Qualifiers： 用于指定要注入的 Bean 的类型。
• Producers： 用于创建 Bean 的工厂方法。
• Interceptors： 用于实现面向切面编程。

3.2 CDI 的使用示例

假设我们有一个 GreetingService 接口和一个 DefaultGreetingService 实现：

public interface GreetingService {
    String greet(String name);
}

import jakarta.enterprise.context.ApplicationScoped;

@ApplicationScoped
public class DefaultGreetingService implements GreetingService {
    @Override
    public String greet(String name) {
        return "Hello, " + name + "!";
    }
}

现在，我们创建一个 GreetingController 类，并将 GreetingService 注入到其中：

import jakarta.enterprise.context.RequestScoped;
import jakarta.inject.Inject;
import jakarta.ws.rs.GET;
import jakarta.ws.rs.Path;
import jakarta.ws.rs.QueryParam;
import jakarta.ws.rs.Produces;
import jakarta.ws.rs.core.MediaType;

@RequestScoped
@Path("/greeting")
public class GreetingController {

    @Inject
    private GreetingService greetingService;

    @GET
    @Produces(MediaType.TEXT_PLAIN)
    public String greet(@QueryParam("name") String name) {
        return greetingService.greet(name);
    }
}

在这个例子中，@Inject 注解告诉 CDI 容器将 GreetingService 的实例注入到 GreetingController 中。@ApplicationScoped 注解表示 DefaultGreetingService 的实例在整个应用程序的生命周期内只创建一个。@RequestScoped 注解表示 GreetingController 的实例在每个 HTTP 请求的生命周期内创建一个。

3.3 使用 Qualifiers 指定注入的 Bean

如果存在多个 GreetingService 的实现，我们可以使用 @Qualifier 注解来指定要注入的 Bean。

首先，定义一个 Qualifier：

import jakarta.inject.Qualifier;
import java.lang.annotation.Retention;
import java.lang.annotation.Target;
import static java.lang.annotation.ElementType.*;
import static java.lang.annotation.RetentionPolicy.RUNTIME;

@Qualifier
@Retention(RUNTIME)
@Target({METHOD, FIELD, PARAMETER, TYPE})
public @interface Formal {
}

然后，创建一个 FormalGreetingService 实现，并使用 @Formal 注解标记：

import jakarta.enterprise.context.ApplicationScoped;
import jakarta.inject.Inject;

@ApplicationScoped
@Formal
public class FormalGreetingService implements GreetingService {
    @Override
    public String greet(String name) {
        return "Good day, " + name + ".";
    }
}

最后，在 GreetingController 中使用 @Formal 注解来指定要注入的 Bean：

import jakarta.enterprise.context.RequestScoped;
import jakarta.inject.Inject;
import jakarta.ws.rs.GET;
import jakarta.ws.rs.Path;
import jakarta.ws.rs.QueryParam;
import jakarta.ws.rs.Produces;
import jakarta.ws.rs.core.MediaType;

@RequestScoped
@Path("/greeting")
public class GreetingController {

    @Inject
    @Formal
    private GreetingService greetingService;

    @GET
    @Produces(MediaType.TEXT_PLAIN)
    public String greet(@QueryParam("name") String name) {
        return greetingService.greet(name);
    }
}

现在，CDI 容器将注入 FormalGreetingService 的实例到 GreetingController 中。

3.4 使用 Producers 创建 Bean

有时，我们需要使用复杂的逻辑来创建 Bean 的实例。这时，我们可以使用 Producers。

例如，我们需要根据环境变量来选择不同的 GreetingService 实现：

import jakarta.enterprise.context.ApplicationScoped;
import jakarta.enterprise.inject.Produces;
import jakarta.inject.Inject;

public class GreetingServiceProducer {

    @Produces
    @ApplicationScoped
    public GreetingService createGreetingService() {
        String greetingType = System.getenv("GREETING_TYPE");
        if ("formal".equals(greetingType)) {
            return new FormalGreetingService(); // 假设 FormalGreetingService 存在
        } else {
            return new DefaultGreetingService();
        }
    }
}

在这个例子中，@Produces 注解标记的方法返回一个 GreetingService 的实例。CDI 容器将自动调用这个方法来创建 Bean 的实例。

四、配置管理的重要性与挑战

配置管理是微服务架构中的一个重要环节。一个良好的配置管理方案能够帮助我们：

• 动态调整服务行为： 在不重新部署服务的情况下，修改配置参数。
• 简化运维： 集中管理配置信息，避免配置分散在代码中。
• 提高安全性： 将敏感信息（如数据库密码）存储在安全的地方。
• 支持环境隔离： 为不同的环境（如开发、测试、生产）使用不同的配置。

在云原生环境中，配置管理面临以下挑战：

• 配置源的多样性： 配置信息可能存储在环境变量、配置文件、数据库、配置中心等多个地方。
• 配置的动态性： 配置信息可能随时发生变化。
• 配置的安全： 敏感信息需要加密存储和访问控制。
• 配置的版本控制： 需要跟踪配置的变更历史。

五、Jakarta EE Config API 的使用

Jakarta EE Config API 提供了一个标准的 API，用于访问配置信息。它允许我们从多个配置源读取配置，并提供了一致的访问方式。

5.1 Config API 的基本概念

• ConfigSource： 配置源，用于从特定的地方读取配置信息（如环境变量、配置文件）。
• Config： 配置接口，用于访问配置信息。
• ConfigProvider： 用于获取 Config 实例。
• ConfigSourceProvider: 用于自定义ConfigSource。

5.2 Config API 的使用示例

首先，在 pom.xml 文件中添加 Config API 的依赖：

<dependency>
    <groupId>jakarta.config</groupId>
    <artifactId>jakarta.config-api</artifactId>
    <version>3.0.0</version> <!-- 使用最新的版本 -->
</dependency>

然后，我们可以使用 ConfigProvider 来获取 Config 实例，并读取配置信息：

import jakarta.config.Config;
import jakarta.config.ConfigProvider;

public class ConfigExample {
    public static void main(String[] args) {
        Config config = ConfigProvider.getConfig();
        String databaseUrl = config.getValue("database.url", String.class);
        int databasePort = config.getValue("database.port", Integer.class);

        System.out.println("Database URL: " + databaseUrl);
        System.out.println("Database Port: " + databasePort);
    }
}

在这个例子中，ConfigProvider.getConfig() 方法返回一个 Config 实例。config.getValue("database.url", String.class) 方法从配置源中读取名为 "database.url" 的配置项，并将其转换为 String 类型。

5.3 配置源的优先级

Config API 允许我们配置多个配置源。当存在多个配置源时，Config API 会按照优先级顺序查找配置项。优先级高的配置源会覆盖优先级低的配置源。

默认情况下，Config API 会查找以下配置源（按优先级从高到低）：

1. 系统属性 (System properties)
2. 环境变量 (Environment variables)
3. META-INF/microprofile-config.properties 文件（位于 classpath 下）

我们可以通过自定义 ConfigSource 来添加自己的配置源，并设置其优先级。

5.4 自定义 ConfigSource

要自定义 ConfigSource，我们需要实现 ConfigSource 接口。

import jakarta.config.ConfigSource;
import java.util.HashMap;
import java.util.Map;
import java.util.Set;

public class MyConfigSource implements ConfigSource {

    private final Map<String, String> properties = new HashMap<>();

    public MyConfigSource() {
        properties.put("my.custom.property", "my custom value");
    }

    @Override
    public Map<String, String> getProperties() {
        return properties;
    }

    @Override
    public Set<String> getPropertyNames() {
        return properties.keySet();
    }

    @Override
    public String getValue(String propertyName) {
        return properties.get(propertyName);
    }

    @Override
    public String getName() {
        return "MyConfigSource";
    }

    @Override
    public int getOrdinal() {
        return 200; // 设置优先级，数值越大，优先级越高
    }
}

在这个例子中，MyConfigSource 从一个 HashMap 中读取配置信息。getOrdinal() 方法用于设置配置源的优先级。

要使 Config API 能够找到 MyConfigSource，我们需要创建一个 ConfigSourceProvider。

import jakarta.config.spi.ConfigSource;
import jakarta.config.spi.ConfigSourceProvider;
import java.util.Collections;
import java.util.Set;

public class MyConfigSourceProvider implements ConfigSourceProvider {
    @Override
    public Iterable<ConfigSource> getConfigSources(ClassLoader forClassLoader) {
        return Collections.singletonList(new MyConfigSource());
    }
}

最后，我们需要在 META-INF/services 目录下创建一个名为 jakarta.config.spi.ConfigSourceProvider 的文件，并在其中写入 MyConfigSourceProvider 的完整类名。

六、与 Kubernetes 集成

在 Kubernetes 环境中，我们可以使用 ConfigMap 和 Secret 来管理配置信息。

• ConfigMap： 用于存储非敏感的配置信息。
• Secret： 用于存储敏感信息（如数据库密码）。

我们可以将 ConfigMap 和 Secret 挂载到容器中，作为环境变量或文件。

6.1 使用环境变量

我们可以将 ConfigMap 和 Secret 中的配置项注入到容器的环境变量中。

例如，我们可以创建一个名为 database-config 的 ConfigMap：

apiVersion: v1
kind: ConfigMap
metadata:
  name: database-config
data:
  database.url: jdbc:mysql://localhost:3306/mydb
  database.port: "3306"

然后，在 Deployment 中将 ConfigMap 中的配置项注入到环境变量中：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  template:
    spec:
      containers:
        - name: my-app
          image: my-app:latest
          env:
            - name: DATABASE_URL
              valueFrom:
                configMapKeyRef:
                  name: database-config
                  key: database.url
            - name: DATABASE_PORT
              valueFrom:
                configMapKeyRef:
                  name: database-config
                  key: database.port

在代码中，我们可以通过 System.getenv() 方法来读取环境变量：

import jakarta.config.Config;
import jakarta.config.ConfigProvider;

public class ConfigExample {
    public static void main(String[] args) {
        //Config config = ConfigProvider.getConfig(); //不再使用Config API直接获取，而是读取环境变量
        String databaseUrl = System.getenv("DATABASE_URL");
        String databasePort = System.getenv("DATABASE_PORT");

        System.out.println("Database URL: " + databaseUrl);
        System.out.println("Database Port: " + databasePort);
    }
}

6.2 使用文件

我们也可以将 ConfigMap 和 Secret 挂载到容器中的文件中。

例如，我们可以创建一个名为 database-config 的 ConfigMap：

apiVersion: v1
kind: ConfigMap
metadata:
  name: database-config
data:
  database.url: jdbc:mysql://localhost:3306/mydb
  database.port: "3306"

然后，在 Deployment 中将 ConfigMap 挂载到文件中：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  template:
    spec:
      containers:
        - name: my-app
          image: my-app:latest
          volumeMounts:
            - name: config-volume
              mountPath: /app/config
      volumes:
        - name: config-volume
          configMap:
            name: database-config

在代码中，我们可以读取文件中的配置信息：

import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Paths;
import java.util.Properties;

public class ConfigExample {
    public static void main(String[] args) throws IOException {
        Properties properties = new Properties();
        properties.load(Files.newInputStream(Paths.get("/app/config/database.url")));  //读取database.url文件的内容
        String databaseUrl = properties.getProperty("database.url");

        properties = new Properties();
        properties.load(Files.newInputStream(Paths.get("/app/config/database.port"))); //读取database.port文件的内容
        String databasePort = properties.getProperty("database.port");

        System.out.println("Database URL: " + databaseUrl);
        System.out.println("Database Port: " + databasePort);
    }
}

七、健康检查（Health Checks）

在云原生环境中，健康检查对于服务的可用性至关重要。Kubernetes 使用健康检查来确定服务是否可用，并根据需要重新启动或替换服务实例。Jakarta EE 提供了一套标准的方式来实现健康检查。

7.1 Jakarta EE Health Checks API

Jakarta EE Health Checks API 定义了一套接口，允许我们暴露服务的健康状态。Kubernetes 可以通过 HTTP 请求访问这些端点，以确定服务的健康状况。

7.2 实现 Health Checks

首先，在pom.xml 中添加依赖:

        <dependency>
            <groupId>org.eclipse.microprofile.health</groupId>
            <artifactId>microprofile-health-api</artifactId>
            <version>4.0</version>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>org.eclipse.microprofile.health</groupId>
            <artifactId>microprofile-health-checks</artifactId>
            <version>4.0</version>
            <scope>runtime</scope>
        </dependency>

然后，创建一个类来实现HealthCheck接口。

import jakarta.enterprise.context.ApplicationScoped;
import org.eclipse.microprofile.health.HealthCheck;
import org.eclipse.microprofile.health.HealthCheckResponse;
import org.eclipse.microprofile.health.Liveness;

@Liveness
@ApplicationScoped
public class LivenessCheck implements HealthCheck {

    @Override
    public HealthCheckResponse call() {
        // 在这里实现你的健康检查逻辑
        // 例如，检查数据库连接是否可用，或者检查缓存是否正常工作
        boolean isHealthy = true; // 假设服务是健康的

        if (isHealthy) {
            return HealthCheckResponse.up("Service is healthy");
        } else {
            return HealthCheckResponse.down("Service is unhealthy");
        }
    }
}

在这个例子中，LivenessCheck 类实现了 HealthCheck 接口。call() 方法用于执行健康检查逻辑。@Liveness 注解表示这是一个活性检查（liveness probe），用于判断服务是否正在运行。

Jakarta EE Health Checks API 定义了两种类型的健康检查：

• Liveness Probe： 用于判断服务是否正在运行。如果 Liveness Probe 失败，Kubernetes 会重新启动服务。
• Readiness Probe： 用于判断服务是否准备好接受请求。如果 Readiness Probe 失败，Kubernetes 会将服务从负载均衡器中移除。

我们可以使用 @Readiness 注解来标记一个 Readiness Probe。

7.3 访问 Health Checks 端点

Jakarta EE Health Checks API 默认暴露以下端点：

• /health/live：用于访问 Liveness Probe。
• /health/ready：用于访问 Readiness Probe。
• /health：用于访问所有健康检查。

Kubernetes 可以通过 HTTP 请求访问这些端点，以确定服务的健康状况。

八、总结：构建云原生微服务的关键要素

我们讨论了使用 Jakarta EE 构建云原生微服务，并重点关注了轻量级依赖注入和配置管理。 CDI 提供了强大的依赖注入能力，帮助我们解耦组件，提高代码的可测试性和可维护性。Config API 提供了一个标准的 API，用于访问配置信息，简化了配置管理。结合 Kubernetes 的 ConfigMap 和 Secret，我们可以实现动态的配置管理和环境隔离。健康检查对于服务的可用性至关重要，Jakarta EE Health Checks API 提供了一套标准的方式来实现健康检查。

希望本次讲座能够帮助大家更好地理解如何使用 Jakarta EE 构建云原生微服务。